dsPIC33A: new 32bit DSP! - Page 1
Forum section: electronics / general

author: JPortici
author_rank: Super Contributor
timestamp: May 07, 2024, 02:07:42 pm
content: Already hinted in 2021 when some advanced info "leaked" in MPLABX IPE, but now it's official.XC-DSC v3.10 added a lot of information in the compiler manual about dsPIC33A, including- 32bit architecture, as the size of register becomes 32bit- FPU (mentioning of F0-F31 registers in context swap)- Unified Memory space (32bit address space, meaning no more PSV and EDS)- While still remaining a DSP with a rich set of addressing mode- First 64k are near data space, meaning that many instructions can operate directly on memory instead of doing Load/StoreAnd while skimming the US MASTERS program.. wowQuote from: 24004 PNP4 : Introduction to dsPIC33A ArchitectureQuote from: 24005 PNP5 : Signal Acquisition and Processing using the new dsPIC33A Floating Point Digital Signal Controllerso 40MSPS ADC (and the ADC in the dsPIC series isgood)and 72bit DSP(and MPLABX migrating to VS Code / Eclipse. Godspeed Netbeans, hope this won't be a worse disaster)https://techtrain.microchip.com/usmasters/classes.aspxAh, i wish they will do EU Masters..

author: tszaboo
author_rank: Super Contributor
timestamp: May 07, 2024, 05:53:55 pm
content: Read the errata. Microchip introduced already the PIC32MZ with a fast ADC, where the errata was: "ADC doesn't work at all"

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 07, 2024, 06:36:13 pm
content: Quote from: JPortici on May 07, 2024, 02:07:42 pmInteresting.Any part numbers exposed yet ?Adding the ‘A’ at 6th letter is a strangely subtle way to signal a large architecture jump.Digikey have some part codes, mention 200MHz 512 k but no package or other fields filled yet.

author: jnk0le
author_rank: Regular Contributor
timestamp: May 07, 2024, 07:20:09 pm
content: Quote from: PCB.Wiz on May 07, 2024, 06:36:13 pmThey should have named it "dsPIC65" to follow the tradition of confusing naming.

author: JPortici
author_rank: Super Contributor
timestamp: May 07, 2024, 07:38:03 pm
content: Quote from: tszaboo on May 07, 2024, 05:53:55 pmTraditionally speaking the analog part in 16bit hardware has always beenvery goodBut this will sure be a different design so fingers crossedQuote from: PCB.Wiz on May 07, 2024, 06:36:13 pmI wish! i saw those and they appear to be completely uninteresting, i'm still waiting for a beast with 100+ pins and MANY independent input capture/output compare, usb and stuff that can retire the dsPIC33EP MU series. PIC32MK wasn't that beast because of the MIPS core.

author: dmendesf
author_rank: Frequent Contributor
timestamp: June 09, 2024, 05:46:32 pm
content: Anyone got news about this part? 40MSPS could well be used here...

author: glenenglish
author_rank: Frequent Contributor
timestamp: June 13, 2024, 09:18:57 am
content: dsPic were good in their time (2003-2013) , they were quite handy with true circular buffer addressing, but these days they are run out of town by cortex M4, M7.OK, so they M4, M7 dont do circular addressing,But they make up for it with multiple issue ALU/FPU and fast clocks...

author: JPortici
author_rank: Super Contributor
timestamp: June 13, 2024, 09:38:06 am
content: Quote from: glenenglish on June 13, 2024, 09:18:57 amthough this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exitand peripheral set! don't forget about thata dsPIC is still running circles around PIC32 and cortex M3

author: bhave
author_rank: Contributor
timestamp: June 13, 2024, 01:09:05 pm
content: I bet there are some nice changes to the core. Your Microchip rep might be able to provide a preliminary data sheet under NDA.

author: glenenglish
author_rank: Frequent Contributor
timestamp: June 13, 2024, 09:26:45 pm
content: "though this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exitand peripheral set! don't forget about that.. a dsPIC is still running circles around PIC32 and cortex M3"Running circles around? just how ?I think Microchip is dead in this sphere. Microchip has great parts with original dspic, they were awesome parts , a true DSP with zero overhead looping......I used alot of them..... but then in the 2010s they went to sleep and let Cortex M3, M4, M7 take their market.A slow M7 with multiple issue ALU will eat it for breakfast .and let's not forget the M4, M7 parts the core runs at 1.8V or below. Dspic33 is a 3.3V core. runs hot.But there are some plusses :* I guess if you like the parts, familiarity does count for alot, I agree with that.* And they are simple to use- so that's another advantage* easy to use packages* 3.3 / 5V options suit some IO requirements better* clock speed, capabilities are more than required for many applications like motor control, low speed complex DSP.

author: iMo
author_rank: Super Contributor
timestamp: June 13, 2024, 09:38:19 pm
content: Quote from: glenenglish on June 13, 2024, 09:26:45 pmYep, the pic24 and dspic33 are the best 16b mcus I ever played with.. And they did not go asleep in 2010 - in opposite they came with pic32MX at that time the first MCU with 128kB sram (we ran 2.11bsd unix on it), and later on pic32MZ (200MHz, 512kB sram) and pic32MZEF (added 64bit FPU).I made a lot of benchmarks and those chips were on par with M3, M4 at that time (and only mcus with 512kB sram)..

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 13, 2024, 10:18:32 pm
content: Quote from: iMo on June 13, 2024, 09:38:19 pmThe PIC32MZ was a buggy piece of crap when it first came out. Microchip fixed a lot of the issues with the EF revision, but there's still a bunch of stuff not working right and MC shows no inclination to fix any of it.I think it only runs at 252 MHz, which is slow these days (STM32 parts run up to 600 MHz and NXP i.MX runs at up to 1 GHz).

author: iMo
author_rank: Super Contributor
timestamp: June 13, 2024, 10:54:07 pm
content: The MZ came late (they delayed the launch significantly, afaik), but still we talk 2012-2013 perhaps. At that time the MX/MZ outperformed any M3/M4/M4F..

author: tszaboo
author_rank: Super Contributor
timestamp: June 14, 2024, 10:46:45 am
content: Quote from: iMo on June 13, 2024, 10:54:07 pmI did write software back in 2010-2011 for the MX series. It was a better microcontroller than the ARM7TDMI IHMO. Had better peripherals when they worked and had drivers, it was easy to program, the IDE was easy to setup and use, none of these third party compilers and "set up your own makefile" rubbish.The MZ came after this, and it was delayed because of silicon bugs and then launched with silicon bugs.

author: JPortici
author_rank: Super Contributor
timestamp: June 14, 2024, 03:53:46 pm
content: Quote from: glenenglish on June 13, 2024, 09:26:45 pmI'm not sure if you've followed what happened in later years (dsPIC33E, dsPIC33C), the core actually runs at 1V8, math is fast (single cycle multiplication, 18 (dsPIC33E) or 6 (dsPIC33C) cycle division), low interrupt latency, dedicated register sets you can switch to in a couple of cycles (or automatically in case of interrupts), that is how they run around M3 and PIC32. Or at least, they were always outperformed whenever i tested them in real applications (suppose i want to replace MCU X with Y, i can't exceed the power budget so i can't run full speed, i can't exceed money budget so i can't pick the biggest of the bunch though i need A,B,C,D,... peripherals)I designed a single chip tester for our products using a single dsPIC33EP256MU814, i used almost every peripheral, i have software protocol emulation, bit banging and many other things and still lots of margin. Tried to do the same with a PIC32MK but it couldn't keep up with half the load (because of the interrupt latency, that is) then i couldn't find at the time a cortex M4 with nearly as many input capture or independent PWM channels (to generate variable length pulses). I could have done it with a MPC56 series, but you can imagine the pain in the ass of dealing with them.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 14, 2024, 08:16:23 pm
content: Quote from: tszaboo on June 14, 2024, 10:46:45 amYes it was ahead of the competition at the time. I also used the PICX32MX series and I don't remember of any problematic peripheral.I know the MZ had more issues but the 32MX was the last Microchip MCU I used (with also the 24F, but that's a different series altogether.)People take ARM for "granted" these days, but before the Cortex-M became widely popular (which is not *that* long ago actually, about a decade, less than 15 years I'd say), it was not that great an option as far as MCU went IMO. It was more of a necessary path when you needed more processing power and then you had those ARM "application processors", which were in a different category (category that the 32MZ series tried to fit in, and kind of failed).

author: NorthGuy
author_rank: Super Contributor
timestamp: June 15, 2024, 01:26:56 am
content: Quote from: glenenglish on June 13, 2024, 09:26:45 pmSpeaking of markets. These are all public companies so you can get real figures. Compare for example NASDAQ:MCHP and NYSE:STMdsPIC is a DSP. It can fetch two numbers from memory, multiply and add the result of the multiplication to accumulator, decrement cycle count and jump back to the beginning of the loop - all in one cycle. For dsPIC33C running at 100 MHz one cycle is 10 ns. And all that without any caches or any other sources of instability. I don't think your fast M7 core can run circles around this. Load-store CPUs are very bad at this. Typically ARM microcontrollers designed for DSP cannot rely on the core at all and will have special DSP periphery to get performance similar to dsPIC.Now, if the new part runs at 200 MHz, it'll double the performance. They have been speaking about these parts since around 2019. So, it is really long time in the making.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 15, 2024, 01:57:50 am
content: Quote from: NorthGuy on June 15, 2024, 01:26:56 amYes, that's a long time.Either that have a really big customer vacuuming all they can make, or they (still?) have too many bugs and issues to release working parts ?

author: uer166
author_rank: Super Contributor
timestamp: June 15, 2024, 06:47:09 am
content: Very interested mainly for DSMPS work, where:TMS320 is a too big of a pain in the assCortex-M7 has too high latency/too much cache bullshitI can't find any preliminary datasheets of any kind however

author: iMo
author_rank: Super Contributor
timestamp: June 15, 2024, 08:36:00 am
content: Quote from: SiliconWizard on June 14, 2024, 08:16:23 pmWe played with the MX/MZ extensively during the "RetroBSD" project era (2010-2016 perhaps) and never had any issues afaik. There were some issues with ADC in MZ, but otherwise the chips were rock solid. And only mcus with continuous 128kB/512kB of sram, none of the arms had it..A pity the arduino project never incorporated the pic24/dspic33 at that time (around 2005/6 where both started), compared to the atmega88 it was like porsche against trabi..

author: mtwieg
author_rank: Frequent Contributor
timestamp: June 15, 2024, 02:37:14 pm
content: The scant info teased in that link looks very interesting. Wondering if it's means to compete with the more powerful TMS320/C2000 devices from TI.Quote from: uer166 on June 15, 2024, 06:47:09 amI'm curious what you're referring to here. The IDE? Documentation? Feature set? I've never worked with a dsPIC before, but I understand they are in way more products than TMS320. I always assumed that was because dsPICs are much cheaper and are sufficient for basic digital power (spinning a BLDC, controlling a buck converter, etc).

author: uer166
author_rank: Super Contributor
timestamp: June 15, 2024, 09:35:38 pm
content: Quote from: mtwieg on June 15, 2024, 02:37:14 pmDifferent market segments: lots of bigger TMS320 variants are used in drive inverters and large DSMPSs (think double or triple digit kW). dsPIC simply was too small for those applications until this variant which could take part of the market share of TI. TI DSPs are just too weird for me to use architecturally (imagine an MCU that doesn't know what a byte is!). Which is why after the old dsPIC I switched to Cortex-M4 based ARM MCUs. Also was never a fan of Code Composer and actually preferred MPLABX IDE.I've had success with 16-bit dsPIC, and if the 32 bit variant is just as easy to use, it would be a no-brainer for lots of high performance PSU projects where I've been using mainly STM32G4. They would allow tighter or more complicated control loops in software at higher ADC sample rates, which is good for high frequency GaN and SiC converters.Of course the core doesn't matter as much as peripherals, but I ASSUME Microchip did a good job with ADC/timer/core integration which is the actual value-add. Like, I don't even care about high resolution delay-line timers that are all the rage, rather just give me true 200MHz flexible timers that can have many set/reset sources and that operate tightly with ADCs and the core to process the samples.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 16, 2024, 07:41:09 pm
content: Quote from: iMo on June 15, 2024, 08:36:00 amI have also extensively used the PIC32MX/MZ. The MX was very stable and I had no major issues with either the core or the peripherals. Many of the peripherals didn't have as many features/options as some of the peripherals on NXP and ST Cortex-M parts, but they were easy to understand, solid, and got the job done. The MZ was a disappointment at first with its large list of errata, but they did fix a lot of them in the EF iteration. Did they ever fix the ADC issues? I gave up on the part not long after the EF came out.Debugging on the PIC32 wasn't as nice because the hardware debuggers I used (RealICE and ICD3 & ICD4) were slow compared to JLINK and STLink2 & 3 on the ARM parts. Debugging felt slow and sluggish by comparison. (I had no issues with MPLABX, however, as I've never been a big fan of Eclipse, which most ARM vendors use as their IDE/debugger).Some of the things I liked better about PIC32 than ARM: large contiguous RAM spaces, more logical way of setting configuration parameters, simpler and easier to understand and implement peripherals, really good documentation (with actual examples).Some of the things I didn't like: Slower hardware debuggers, MC charging for money higher compiler optimization levels even though the compiler was based on GCC, documentation split up into multiple files, most parts don't have an FPU, relatively slow core clock (252 MHz).

author: NorthGuy
author_rank: Super Contributor
timestamp: June 16, 2024, 08:25:47 pm
content: Quote from: Sal Ammoniac on June 16, 2024, 07:41:09 pmThis is because of the debugger (part of MPLAB X), not silicon.PIC32 CPU has nothing in common with dsPIC33. PIC32 uses MIPS, which is one of the first load-store architectures, similar to ARM, but even more RISC-y. It's practically extinct now. RISC-V is, sort of, a newer improved version of MIPS. dsPIC33 is not RISC. It has cycle accurate and very reach command set which lets you create very fast and fully predictable command sequences, for example very fast ISRs. As I understand, dsPIC33A's CPU are going to be more like dsPIC33.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 16, 2024, 08:38:21 pm
content: Quote from: NorthGuy on June 16, 2024, 08:25:47 pmIt wasn’t due to MPLABX. I had one PIC32MX board that had a built-in debugger (it had a USB connector) where debugging was just as fast as an ARM with a JLINK, but plug an ICD or RealICE into a board and debugging was slow and sluggish.

author: hans
author_rank: Super Contributor
timestamp: June 16, 2024, 08:54:11 pm
content: Quote from: NorthGuy on June 16, 2024, 08:25:47 pmYep, on the dsPIC and PIC24 I used, the peripherals reside in 0000h .. 0800h.Many ALU instructions can do reg<=>reg, or wreg<=>memory file (0000h..1FFFh). The latter looks a bit more like 8-bit PICs, but it can be very powerful. This is one of the advantages from a very flat bus hierarchy, where the CPU, RAM and peripherals are on a single data bus. Contrast this to modern ARM parts with AHB/APB bridges/switches, which does allow CPUs to run real fast, also introduces a lot of delay.Perhaps one point where it starts to break down is when you use object orientated code. The register file address is hard-coded, so a load-store still has to be used if anything is behind a pointer. For example, if you want to write a generic SpiTxRx() function with a pointer to the SPI hardware address. Would this be perhaps why they don't want C++ on 16-bit PICs? Because it's very easy to have everything in a program behind some indirect address...It would be kind of awesome if they would allow indirect addressing mode on ALU operations, as it looks like the bus implementation can already support it for fixed registerfile addresses. But I suppose there weren't enough bits to squueze this in the current 24-bit instruction format.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 16, 2024, 09:58:51 pm
content: Quote from: hans on June 16, 2024, 08:54:11 pmActually, indirect addressing gives you even more flexibity. Say:Code:mov #SPIBUF,w2 // address of SPI register in w2...// write 8 bytes from a buffer at w1 to SPIrepeat #7mov.b [w1++],...// read 8 bytes from the SPI to the buffer at w1repeat #7mov.b ,[w1++]

author: mtwieg
author_rank: Frequent Contributor
timestamp: June 17, 2024, 01:46:29 pm
content: Quote from: uer166 on June 15, 2024, 09:35:38 pmAgreed on this.QuoteI get that a lot of people choke on this, but I find that baffling. In my experience the vast majority of my variables are 32b (floats, pointers, etc) with some 16b (ints). Having addressable bytes would maybe save a few percent in terms of RAM usage, but it would come at the cost of data page size being cut in half, or a reduction in max clock frequency. Honestly I'd probably be better off if it only addressed 32b words. If your application is spending most of its time printing and parsing strings then yeah byte addessing helps a lot more, but then why would you use a DSP/DSC for that??QuoteYeah for general DCDC converters the utility of <5ns resolution pwm is debatable, even when operating at GaN frequencies. For my application (somewhat like a class D amplifier) it is absolutely necessary, and I wish more chips had such features.

author: uer166
author_rank: Super Contributor
timestamp: June 17, 2024, 05:50:57 pm
content: Quote from: mtwieg on June 17, 2024, 01:46:29 pmBiggest annoyance here is that the resolution doesn't result in response time: if the timers *responded* in <5ns, that would be a game changer! I can see a class D audio-esque stuff needing extra resolution though.

author: hans
author_rank: Super Contributor
timestamp: June 17, 2024, 08:12:54 pm
content: Quote from: NorthGuy on June 16, 2024, 09:58:51 pmActually I was thinking more of BSET and BTSC instructions. Those only work on register file operands, whereas it seems the underlying architecture has no problem with performing a read-modify-write monotonically in 2 clock cycles (16MIPS=32MHz).If you want to use a pointer to SPICON, you'll still revert to a load-store kind of structure. Checking for a bit high and then clearing it takes 2 instructions on this architecture, whereas on load-store architectures it can easily take 5-6. But, as I said, it cannot support indirect addressing, so better no use OOP code structures.But probably for high reliability code, people are not really interested in using that anyway. They don't want a null pointer dereference to screw up a 1kW BLDC motoredit: @NorthGuy: not going to break up the thread any further, but you're right. Doh! I don't know where my mind was when thinking about this.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 17, 2024, 11:33:47 pm
content: Quote from: hans on June 17, 2024, 08:12:54 pmThese can be done indirectly too, a laCode:bset [w3++],#6 // sets the 6-th bit in the word pointed to by w3 and then increments w3btst ,#3 // tests the 3-rd bit in the word pointed to by w4Can even address single bits indirectly:Code:btst ,w5 // tests the bit in the word pointed to by w4, the number of the bit is in w5You can also test and set bits in memory with a single instruction (but not indirectly):Code:btsts SOMETHIG,#4 // test bit #4 in memory and then set it to 1

author: glenenglish
author_rank: Frequent Contributor
timestamp: June 18, 2024, 12:35:38 am
content: -----Northguy, yes I agree dispic33 16b - they were genuine real DSPs. They were an excellent option to large pin count SHARC- really they were the ONLY option. Fantastic instruction set. Most of my world up to 2005 was SHARC. and often a 21065 was way way too much of a overkill. Not to mention the dspic was loaded with useful peripherals (sharc not)I had some early experience with early PI32MX etc and vowed never to touch them again.M7 and cache. yes beware. direct calculation or say approximation can be faster than a LUT (in case of cache miss....)I agree, they're not DSPs, but if you need general purpose grunt and a bit of DSP, I think they are excellent.What are people using now when they need a true DSP?TI came out with a range of DSCs but they were not true DSP (zeor overhead looping, circular buffer, simultaneous dual operand fetch).The dual operand fetch per cycle is a problem for most microprocessor architectures.M4 can't do this, but M7 can do this, and, relies on unrolling loops and the pipeline pickign it up early

author: glenenglish
author_rank: Frequent Contributor
timestamp: June 18, 2024, 08:09:53 pm
content: I was thinking a bit more and read the datasheet again on the old dspic33.What I remember now- these DSPs like their ancestors (TMS320, 56k, 21xx) , were easy to write good hand coded optimized assembler.-WYSIWIG. What you wrote in ASM was how to executed.With the M7 etc, the multiple execution units and pipelines - this requires in depth knowledge of the how many instruction you can have in the air, and data hazards and pipeline stalls.I spend alot more time optimizing M7 code for DSP because I need to have the machine in my head. But clock for clock it does as well as a true DSP for most ops (but more code- since loops need unrolling in some cases)M4 cannot do dual load store, but M7 can do dual load/store + ALU ops per clock.so M7 is much more like a DSP. Of course the dsPIC doesnt have cache side effects,

author: jnk0le
author_rank: Regular Contributor
timestamp: June 28, 2024, 12:56:22 am
content: QuoteThose repeat single instructions are quite usefull and nice (like 1 cycle per FIR tap without need for 2nd data bus on c2000), but they often make uninterruptible sequences, so end up not being used at all because it adds irq jitter/latency.Quote from: glenenglish on June 18, 2024, 08:09:53 pmFrom my testing, it cannot dual issue load/store double with anything, though The FPU is bad enough to benefit from such scheduling.https://github.com/jnk0le/random/tree/master/pipeline%20cycle%20test#cortex-m7

author: NorthGuy
author_rank: Super Contributor
timestamp: June 28, 2024, 02:01:35 am
content: Quote from: jnk0le on June 28, 2024, 12:56:22 amThis is not true. They're all intrruptible. Nothing can change the interrupt latency (aside of disabling interrupts on purpose). Moreover, there are several IRQ levels, and lower priority interrupts, no matter at what stage of processing they are, do not affect the latency of higher priority interrupts.These chips were created for emdedded work and therefore they're completely deterministic.

author: jnk0le
author_rank: Regular Contributor
timestamp: June 28, 2024, 08:19:29 pm
content: Quote from: NorthGuy on June 28, 2024, 02:01:35 amdsPIC (16bit one) indeed has a sane design and can be used to full potential without sacrificing irq handling.Meanwhile other DSP architectures (e.g. 56k or c2000) were not that lucky. (C2000 RPT is not interruptible even by DMA transfers)

author: mtwieg
author_rank: Frequent Contributor
timestamp: June 29, 2024, 12:46:48 pm
content: Quote from: jnk0le on June 28, 2024, 08:19:29 pmCan confirm the C2000 RPT instruction can't be interrupted by ISRs. Not sure about DMA. One of my biggest gripes with C2000 is that its DMA is crippled (can't access most peripherals, can't access shared memories between processors, etc) so I actually don't utilize it much.I always found the RPT instruction strange. Obviously it's faster than looping with a branch, but does it work differently from simply repeating the same opcode n times? If not then it just saves a bit of code size?

author: coppice
author_rank: Super Contributor
timestamp: June 29, 2024, 12:50:43 pm
content: Quote from: jnk0le on June 28, 2024, 08:19:29 pmThe dsPIC design had a lot of merit, but couldn't overcome its great enemy - MicroChip's management.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 29, 2024, 02:53:14 pm
content: Quote from: jnk0le on June 28, 2024, 08:19:29 pmdsPIC has problems with DMA too.Earlier models had dedicated dual-access DMA memory, so DMA and CPU worked independently of each other. Thus, not only CPU was deterministic, but DMA was deterministic as well. However, DMA was not universal and was restricted to specific periphery.In newer models, DMA is working through the common bus with CPU (where CPU has higher priority), which is common for load-store architectures (such as ARM). But unlike load-store architectures, dsPIC33 CPU can put very high pressure on memory. For example, if you're doing 64-tap FIR filter, you can do it in 64 cycles, but there will be not a single bus cycle left for DMA, so DMA may starve - if you're receiving 20 MHz SPI at the same time, there may be bytes lost. In addition, DMA is built in such a way that you cannot use built-in FIFOs in peripheral modules when they're handled with DMA. You can give higher priority to DMA to fix this, but then the CPU is no longer deterministic. Therefore, if you want CPU to be deterministic, you can only do slow things through DMA. Hopefully, they will fix that in dsPIC33A.

author: jnk0le
author_rank: Regular Contributor
timestamp: June 29, 2024, 04:58:46 pm
content: Quote from: mtwieg on June 29, 2024, 12:46:48 pmIt frees up the program bus so those dual memory operand instructions can recycle that for loading data and execute 1 per cycle without the need for 2nd data bus.

author: LM2023
author_rank: Newbie
timestamp: July 11, 2024, 02:39:28 pm
content: There is new documentation about dsPIC33A on microchip's website:https://www.microchip.com/en-us/search?searchQuery=dsPIC33A&category=ALL&fq=start%3D0%26rows%3D10There is the "dsPIC33A Programmer's Reference Manual" and also the brief on the dsPIC33AK128MC106 family.The new core has 16 32-bit working registers and 32 32-bit single precision registers (that can be "paired" as 16 64-bit double precision registers), with also two 72-bit accumulators for fixed point arithmetic dsp instructions.It is compatible with dsPIC33 "16-bit" instruction set, so if you just need a faster dsPIC33 and keep most of the already developed code it can be done.About the dsPIC33AK128MC106 family, available in packages with 28/36/48/64 pin, 8/16 KB of ram, 32/64/128 KB of flash memoryClock frequency up to 200MHz and AEC-Q100 Rev. G Grade 1 certification (temperature range -40..+125 °C), with Grade 0 (-40 .. +150 °C) and ASIL B/C planned.

author: uer166
author_rank: Super Contributor
timestamp: July 11, 2024, 07:54:29 pm
content: Peripheral set isokay, but a bit disappointing: it's still quite a small device. The 40MSPS 2x ADCs are nice, but only for quite niche applications. I'd still prefer say 6x slower ADCs. Overall a STM32G4 still has way more analog integration, timers, and interconnects.

author: JPortici
author_rank: Super Contributor
timestamp: July 11, 2024, 08:01:34 pm
content: PTG compensates that, as it is quite flexible, but also really complex.I'm disappointed by the lack of big packagesI really hoped for a really big do-it-all like the dsPIC33EP MU series

author: uer166
author_rank: Super Contributor
timestamp: July 11, 2024, 08:20:35 pm
content: Quote from: JPortici on July 11, 2024, 08:01:34 pmHow so? I can run 6 half-bridges with an HRTIM on a G4 with another half dozen PWMs on other timers available, but it's not clear to me how same cane be achieved here.

author: JPortici
author_rank: Super Contributor
timestamp: July 11, 2024, 08:36:18 pm
content: Quote from: uer166 on July 11, 2024, 08:20:35 pmMy remark on PTG was about the interconnects! If there are not enough PWM there are not enough PWM, period.see my remark about a BIG do-it-all. dsPIC33MU has 3 HSPWM, 16 output compare/pwm, 16 input capture. plus many timers, uart, etc... and freaking USB. I don't understand why microchip doesn't put usb on dsPIC anymore. I have to use 24MHz PIC24 (which is usually plenty, but not when i have 6-8 SENT to interface to, plus all the rest for analog IO)This first part is plainly disappointing for me.. but for its intended application is probably the cake: microchip's peripherals, a fast low latency core... i guess four wheeled robot or industrial computer or something like that? They went all in to put specialized encored interface..

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 11, 2024, 10:10:32 pm
content: I like it ! great size mul and saturating accumulator.and it also has some FP capability for when you really need to do a little FP and dont want it costing 200 cycles each op.The dual 40 MHz ADCs looks good, I can see some ham radio opportunities there.Cant find any AC specifications, like full power BW and ENOB ?(vaguely excited)

author: jnk0le
author_rank: Regular Contributor
timestamp: July 11, 2024, 11:33:53 pm
content: No dual MAC, for q15, seems to be a bit weird decision in 32bit DSP.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 12, 2024, 04:39:06 am
content: There are part codes for larger parts DSPIC33AK512MP, that may have more features ?It's not bad - 1.25ns PWM granularity and 1.6GHz PLLs and good FIFOs on the comms channels.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 15, 2024, 02:52:21 pm
content: The periphery seems roughly the same as with dsPIC33C, except for 40 Msps ADCs (the fasterst they had in dsPIC33C was 3.5 Msps, but it had multiple independent sampling cores). They don't have any specifics yet, so it's hard to tell.Aside of FP stuff, the ISA seems to be a carbon copy of dsPIC33C with instructions extended to 32-bit which removes lots of limitations. There are also many 16-bit instructions which I think can be freely intermixed with 32-bit ones as in Thumb2 or microMIPS.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2024, 03:36:02 am
content: Or may be 16-bit instructions must be paired to maintain 32-bit alignment. The docs are not clear about this.

author: marcov
author_rank: Newbie
timestamp: July 16, 2024, 09:23:08 am
content: Quote from: NorthGuy on July 15, 2024, 02:52:21 pmAnd 2 cycle branch, like the dspic33c MP slave processor. So they must have sped up flash tremendously beyond the older (dspic,pic32mk) parts at 40MHz (2x 20MHz?) to obtain a single cycle 200MHz processor.There are also bad things, only 64k mem in the initial parts, and dspicC style timers are a bit a of a let down. I would have preferred E style timers + OCs. If you use OCs a lot, you run out of timers quickly on the C (or at least I did in my first experiments). Even if you can use two 16-bit timers per peripheral running of the REFCLK to increase range.Quote from: NorthGuyDsPIC 16-bit instructions are 24-bit wide.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2024, 12:43:33 pm
content: Quote from: marcov on July 16, 2024, 09:23:08 amI like CCP timers better, but there must be lots of them. Most PIC32M have 8 of them or more, but only four hereQuote from: marcov on July 16, 2024, 09:23:08 amNo. Older dsPIC33 used to have 24-bit wide instructions. dsPIC33A has 32-bit wide instructions. But they also have short 16-bit wide instructions, which I think must be paired - that is you can fit two instructions in a single 32-bit wide slot. But it doesn't look like they execute simultaneously. The docs have very little info on that.

author: marcov
author_rank: Newbie
timestamp: July 16, 2024, 01:45:21 pm
content: Quote from: NorthGuy on July 16, 2024, 12:43:33 pmEven 8 of them are only 16 16-bit timers.The dspic33e MU 8xx series has 9 16-bit timers and 16 16-bit OC for a total 25 16-bit timers.QuoteI assumed that to remain the same because I took the compatibility with 16-bit in the family sheet as binary compatibility and to imply that 24-bit width would stay. A shorter 16-bit instruction set would not be compatible, as it wouldn't be able to use 16-bit operands, requiring it to subdivide into multiple instructions.Anyway I only saw the summary family sheet, and the chinese datasheet for the smaller controller type.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2024, 01:59:36 pm
content: Quote from: marcov on July 16, 2024, 01:45:21 pmI think they meant it to be compatible at the assembler level. They have the same assembler mneumonics which, by default, operate on 16-bit operands. For 32-bit operands you need to add .L (that is ADD.L instead of ADD), so in theory, anything written in assembler should work without modifications. There's no binary compatibility though.

author: marcov
author_rank: Newbie
timestamp: July 16, 2024, 02:07:42 pm
content: Quote from: NorthGuy on July 16, 2024, 01:59:36 pmSee my previous post. You can't put a 16-bit immediate value (address, register value) into a 16-bit instruction, unless they are macros that code for multiple instructions.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2024, 02:26:59 pm
content: Quote from: marcov on July 16, 2024, 02:07:42 pmI don't understand your communication. They're 32-bit devices. Instructions are 32-bit long. But some of the instructions are half-width - 16-bit long. Apparently, the instructions using 16-bit literals will be 32-bit long. So what?

author: marcov
author_rank: Newbie
timestamp: July 16, 2024, 02:47:33 pm
content: Quote from: NorthGuy on July 16, 2024, 02:26:59 pmProbably I was still thinking too much along compatibility lines. Btw, have you read anything about SFR access penalties?

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2024, 03:14:03 pm
content: Quote from: marcov on July 16, 2024, 02:47:33 pmNo. I tried to find something about SFR, but only found readsfr instruction which is undocumented and may be has nothing to do with SFRs. May be the SFR access is fast, or may be they just omitted this.Also, I've read about jumps and path prediction. Jump times seem a little bit too good to be true.

author: marcov
author_rank: Newbie
timestamp: July 16, 2024, 03:39:22 pm
content: Quote from: NorthGuy on July 16, 2024, 03:14:03 pmYes, 2 cycles at 200Mhz. But maybe that is the limitation on (prefetch) performance of the core itself only, without the realities of the the attached flash subsystem. Then it only is the same as dspic33c when running from RAM.The 120MHz of the pic32mk sounded good at first too :-)

author: glenenglish
author_rank: Frequent Contributor
timestamp: July 16, 2024, 08:25:26 pm
content: ADI SHARC has zero cycle cost branches.....(and executed the instruction following the branch/ had delay slots) .But, agreed a very different architecture. SHARC executed from dual port RAM, and had separate I and D RAM, and dual ported so DMA and peripheral background transactions didnt hurt it.Sort of like I guess modern day I and D L1 cache that was also dual ported.... a mega byte of it

author: coppice
author_rank: Super Contributor
timestamp: July 16, 2024, 10:11:27 pm
content: Quote from: glenenglish on July 16, 2024, 08:25:26 pmMost serious DSPs have had zero cycle branches.

author: rich t
author_rank: Contributor
timestamp: July 16, 2024, 11:50:46 pm
content: > The 120MHz of the pic32mk sounded good at first too :-)If you use the GPK or MCM flavor, it's pretty good -- very few errata bugs. (The earlier versions were a bit of a minefield.)It's still MIPS, which is not really designed to be an embedded system -- interrupts are slow, but the full set of shadow registers (one per interrupt level) helps.microMIPS (16-bit instructions) helps significantly as well -- to the tune of 20% performance improvement.I have the ADCs running easily to 20 Msps (but I have to throttle back to 18.18 Msps to be able to do concurrent digital capture and waveform generation, as I run out of DMA bandwidth).I will have to learn about this new part!PIC32MK/GPK ADC code is here:https://github.com/rtestardi/StickOS2/blob/main/cpustick/scope.c

author: JPortici
author_rank: Super Contributor
timestamp: July 17, 2024, 07:50:17 am
content: Page searcheable, but currently not activehttps://www.microchip.com/en-us/product/dsPIC33AK128MC106https://www.microchip.com/wwwproducts/productds/dsPIC33AK128MC106I expect it to be up in a few hoursthe DFP has some interesting information (many new interrupt types, many new configuration word options)

author: LM2023
author_rank: Newbie
timestamp: July 17, 2024, 08:29:31 am
content: Quote from: NorthGuy on July 16, 2024, 03:36:02 amit's not explictly written in the available documentation, but it seems they are using a decoding strategy a lot like RISC-V (i.e. the first 16bit word fetched contains enough information to know long the complete instruction is).See in the dsPIC33A programmer's reference manual:At "6.1 Instruction Bit Map" they describe how instruction encoding size is deduced by looking up the top 8 bit of the first 16bit word fetchedIn section 4, the condition branch descriptions have no mention of alignment requirements when performing the "just skip next instruction" trick and it is shown how it deduces the next instruction size:QuotePutting these two piece of information together, it seems that 32bit-long instruction don't need to be aligned to 4 byte boundaries.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 17, 2024, 12:42:06 pm
content: Quote from: LM2023 on July 17, 2024, 08:29:31 amApparently, if you have a mix of 16-bit-long and 32-bit-long instructions you need to be able to detect the size of upcoming instructions. But it tells nothing about 32-bit instruction alignment.But they do have a NEOP instruction:"No Operation is performed. This instruction will also consume no execution time. It can be regarded as a means to pad a 16-bit instruction (to use a 32-bit word) when the instruction cannot be paired with another 16-bit instruction (to maintain alignment)".which hints that the 16-bit instructions might be a need to be paired.A lot of text in the Reference Manual is copied and pasted from the manual from older 16-bit dsPIC33 manual and thus is plainly wrong. So, it's very hard to draw any conclusions.

author: Howardlong
author_rank: Super Contributor
timestamp: July 17, 2024, 06:36:11 pm
content: Quote from: Sal Ammoniac on June 16, 2024, 07:41:09 pmYes, it was the PIC32MZECfamily was complete crap, and the entire family has been NRND for some time now. I wasted about 18 months hanging on for Microchip to fix/workaround the PIC32MZ EC device's USP of high speed simultaneous sampling ADCs. They released a series of hacks that never solved the problem, degrading the ADC performance at every turn. It turned out I was wasting my time, and a product ended up in the trash as a result.The PIC32MZEFintroduced a couple of years later does have decent high speed simultaneous sampling ADCs, a peripheral since also introduced into the PIC32MK family too... although unlike the PIC32MZ EF family, the PIC32MK family has no USB HS, making the MK useless for continuous high speed data acquisition purposes.The EF threw in a a single precision FPU too.If you want simultaneous sampling high speed DAQ over USB HS, ISTBC, but the only single-chip solution I'm aware of that can achieve this is the PIC32MZ EF.

author: Howardlong
author_rank: Super Contributor
timestamp: July 17, 2024, 07:09:50 pm
content: This must be close now, EV74H48A dsPIC33A Curiosity evaluation board is showing as shipping on 26 July. I've taken a punt.https://www.microchipdirect.com/dev-tools/EV74H48AI can't see any individual chip availability though.What concerns me is that we had a similar scenario during the infamous PIC32MZ EC family failure, with a preliminary announcement and leaks, followed by long delays, and then... well, it wasn't great.Perhaps they're waiting for Masters this year.By the way, I'm wondering why they're still calling it "Masters" bearing in mind they found the word is so egrgiously offensive that it was struck out of hundreds of Microchip data sheets.

author: uer166
author_rank: Super Contributor
timestamp: July 17, 2024, 07:32:11 pm
content: Quote from: Howardlong on July 17, 2024, 07:09:50 pmeasy: it is offensive as a noun, not as an adjective:"noun; a man who has people working for him, especially servants or slaves.""adjective; having or showing very great skill or proficiency."

author: JPortici
author_rank: Super Contributor
timestamp: July 17, 2024, 08:08:30 pm
content: Quote from: Howardlong on July 17, 2024, 07:09:50 pmwell there were talks about 32bit dsPIC happening "soon" in late 2019 so i think they were thoroughly evaluated. same for dsPIC with mid power mosfet driver and they actually happened in the meantimeby the way are you coming to this year's europe masters? thinking aobut going again, it was a blast that yearQuote from: Howardlong on July 17, 2024, 07:09:50 pmsilly you! that's not the plural of master! that's for masters' degree

author: Howardlong
author_rank: Super Contributor
timestamp: July 18, 2024, 12:09:31 pm
content: Quote from: JPortici on July 17, 2024, 08:08:30 pmNope, I've never been to any of the Masters conferences. Not my thing really, although I am sure you can leverage out a lot more information than I can get out my crystal ball and rudimentary telepathy skills.Meanwhile I noticed initial release DFPs today for the dsPIC33A.Before you get excited, the links in the DFP update go nowhere of interest, either a 404 or a generic page of nothing.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 18, 2024, 04:30:23 pm
content: Quote from: JPortici on July 17, 2024, 08:08:30 pmI think it mimics Master's golf tournament in Augusta National. Therefore Masters here means Professionals as opposed to Amateurs.

author: jnk0le
author_rank: Regular Contributor
timestamp: July 19, 2024, 06:34:36 pm
content: Quote from: Howardlong on July 17, 2024, 07:09:50 pmSimple. In recent years russia did undergo budget cuts on some of their ideological subversion programs. Therefore you can spot oversights like this.

author: coppice
author_rank: Super Contributor
timestamp: July 19, 2024, 08:06:06 pm
content: Quote from: jnk0le on July 19, 2024, 06:34:36 pmAlso, not everyone just rolls over and succumbs to this kind of master baiting.

author: Howardlong
author_rank: Super Contributor
timestamp: July 22, 2024, 09:00:15 pm
content: Quote from: Howardlong on July 17, 2024, 07:09:50 pmWell it arrived today... just don't make the same mistake I did: order one of the MCU DIM modulesEV18H47Aand/orEV02G02Atoo, otherwise you have a paperweight, and not a very heavy one either.Edit: additional part numbers I ordered are EV68M17A and EV67K87A. Not sure how I managed to mess up those part numbers originally.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 24, 2024, 01:34:07 pm
content: New document has appeared - a migration guide. It explains few things. Instruction times are definitely subject to instruction bus wait and SFR wait. SFRs have various access time and may run 1:1, 1:2, 1:4 to system clock. The instruction clock is the same as the oscillator (was 2:1). Does it mean that simultaneous read/write in the same instruction will require 2 cycles? 2kb (512 instructions) cache for instruction flash fetches. How fast is it without cache? Can cache be controlled? Can execute from RAM for faster execution. But is it subject to bus contention with data fetches? Overall it looks like predictability was sacrificed for faster CPU clock.Other than that lots of improvements, practically everywhere.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 24, 2024, 04:26:47 pm
content: Quote from: Howardlong on July 22, 2024, 09:00:15 pmI ordered a couple of EV68M17A. Looks like they have programming/debugging connectors. Should be enough to figure out how it all works.

author: Howardlong
author_rank: Super Contributor
timestamp: July 24, 2024, 07:25:03 pm
content: Quote from: NorthGuy on July 24, 2024, 04:26:47 pmTurns out I got the DIM part number dramatically wrong somehow.I ordered EV68M17A and EV67K87A.

author: JPortici
author_rank: Super Contributor
timestamp: July 24, 2024, 07:33:53 pm
content: Quote from: NorthGuy on July 24, 2024, 01:34:07 pmI've read that!hm... would be interesting to compare against M4F (and maybe M7? though they come with such high clock frequency it's probably pointless...)Why did they say dsPIC33C is 1 step pipeline? Isn't it 2 step pipeline (Fecth/Execute)?> Execute from RAMyes!!!Tomorrow i'll try to see if FAE are still a thing here in italy, i'd like to see a datasheet and prices because there could be many new features i'd want to have in a new series of products, mainly security, and i don't really want to wait to mid september for masters... only to find out i can't use them (that document mentions no SCCP for the first series of devices, i needmanyindependent channels, and i'm not sure i can coerce the PWM module into that... they surely can't do input capture)

author: Howardlong
author_rank: Super Contributor
timestamp: July 24, 2024, 10:38:13 pm
content: Quote from: JPortici on July 24, 2024, 07:33:53 pmMy Google foo clearly isn't up to it, do you have a reference please?

author: NorthGuy
author_rank: Super Contributor
timestamp: July 25, 2024, 12:44:05 am
content: Quote from: Howardlong on July 24, 2024, 10:38:13 pmI searched for dsPIC33A on Microchip Website (this method was suggested by one of the early posters here). Here's the direct link:https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/SupportingCollateral/dsPIC33CK-to-dsPIC33AK-Migration-and-Performance-Enhancement-Guide-DS70005574.pdf

author: uer166
author_rank: Super Contributor
timestamp: July 25, 2024, 05:20:16 am
content: Looks like upper end devices have up to to 5 ADC cores at 40MSPS. That is quite useful! (Even though CPU can't process all at 40MSPS obviously)

author: marcov
author_rank: Newbie
timestamp: July 29, 2024, 09:25:11 am
content: In case you haven't seen, some more datasheets on the microchip sitehttps://www.microchip.com/en-us/search?searchQuery=dspic33a&category=ALL&fq=start%3D0%26rows%3D19The one from the curiosity board seems to have 16kb ram

author: JPortici
author_rank: Super Contributor
timestamp: July 29, 2024, 10:19:29 am
content: Quote from: marcov on July 29, 2024, 09:25:11 amAnd Erratas... None is a dealbreaker to me, phew

author: Howardlong
author_rank: Super Contributor
timestamp: July 29, 2024, 05:12:20 pm
content: A short vid has just appeared, that, like many Microchip videos, are too short to offer anything more than the most minimal amount of information.https://youtu.be/AOySt6iHVw8?si=KtqgQqtwhDfgADhN

author: iMo
author_rank: Super Contributor
timestamp: July 29, 2024, 06:16:01 pm
content: There are 800-1500 pages long datasheets to download, afaik..PS: hopefully at least 3-4 ADCs are simultaneously sampling..

author: Howardlong
author_rank: Super Contributor
timestamp: July 30, 2024, 03:41:28 pm
content: Quote from: iMo on July 29, 2024, 06:16:01 pmThey seem to have dropped the datasheet + FRM method, where you often end up referring to multiple documents, and have to figure out anything different between datasheet and FRM.The current chips have two ADCs for simultaneous sampling.Fastest Tad is 12.5ns (80MHz derived from a 320MHz clock, using the ADC's fixed divide-by-4), parameter AD50 on Table 37-40 p1484, document DS70005539B.Sampling time Tsamp for 12 bits must be 9ns minimum (assuming typical internal Ric = 1k ohm and Chold = 1pF, and negligible source impedance, AD60 & AD62 on Table 37-40 p1484). The next available sample time is 31.25ns, from Section 15.3.6 p851.Conversion time Tconv is 1.5 Tad, or 18.75ns irrespective of the number of conversion bits you need, it always converts 12 bits. Section 15.4.3 p865.Tconv + Tsamp = 50ns, so 20MHz sample rate is maximum rate for 12 bits (also applies if you're only interested in 9, 10 and 11 bits).If you want to do an in-spec conversion at minimum Tsamp (6.25ns) and Tconv (1.5 Tad or 18.75ns), 8 bits is the maximum effective resolution (it still converts 12 bits, but only up to 8 bits are reliable).

author: JPortici
author_rank: Super Contributor
timestamp: July 30, 2024, 03:54:16 pm
content: Quote from: Howardlong on July 30, 2024, 03:41:28 pmHope not, i'd like to have an in depth description of the security module with examples (hopefully some application notes will come..) as it was the custom with the FRM chapters

author: Howardlong
author_rank: Super Contributor
timestamp: August 01, 2024, 04:46:53 pm
content: It's here!Did a blinky, got it running at 200MHz, although the fastest I've been able to toggle a pin is about 33MHz. I'd have expected to toggle at 50MHz as the standard peripheral bus is Fcy/2.I've already encountered a handful of errors in the datasheet so far, in particular regarding the PLL example code.I'll put more info up on Microchip dsPIC33 forum.

author: coppice
author_rank: Super Contributor
timestamp: August 01, 2024, 04:55:43 pm
content: Quote from: Howardlong on August 01, 2024, 04:46:53 pmMCU example code that doesn't work? I'm shocked.

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 01, 2024, 07:54:53 pm
content: Quote from: Howardlong on July 30, 2024, 03:41:28 pmAny numbers of full power bandwidth and ENOB ?

author: Howardlong
author_rank: Super Contributor
timestamp: August 01, 2024, 09:51:08 pm
content: Quote from: glenenglish on August 01, 2024, 07:54:53 pmNot specified and 10.5 bits.

author: kilohercas
author_rank: Regular Contributor
timestamp: August 04, 2024, 06:00:01 pm
content: I am having difficulty understanding the discrepancy between the specifications and the promotional material. The datasheet specifies a 2.5 ns PWM resolution, whereas the promotional video claims a 78 ps resolution. However, I was unable to find any supporting data for the higher resolution PWM. The 78 ps PWM step would be very intriguing for me, especially in the context of eGaN devices.

author: coppice
author_rank: Super Contributor
timestamp: August 04, 2024, 07:41:45 pm
content: Quote from: kilohercas on August 04, 2024, 06:00:01 pmYou need something like 78ps to be competitive in the control market these days. They are all doing it since the C2000 started the trend.

author: Howardlong
author_rank: Super Contributor
timestamp: August 04, 2024, 11:33:58 pm
content: Quote from: kilohercas on August 04, 2024, 06:00:01 pmYou need a PWM peripheral with "Fine edge placement" in Microchip terms. The currently documented dsPIC33A devicesdon'thave this feature. *In their other dsPIC33's with this feature, they go down to 250ps resolution, but it dictates a specific clock frequency as it relies on a fixed multi-tapped delay line for the last 3 bits of resolution.* Edit: For some reason I missed the "don't" out. Doh!

author: JPortici
author_rank: Super Contributor
timestamp: August 05, 2024, 01:59:37 pm
content: Quote from: kilohercas on August 04, 2024, 06:00:01 pmthe currently available device doesnothave the high speed mode (fine edge placement) so it should be only 400MHzI see mention of this 78ps resolution for an upcoming "second generation" device in the "dsPIC33C to dsPIC33A Migration guide"

author: Howardlong
author_rank: Super Contributor
timestamp: August 05, 2024, 03:26:35 pm
content: Quote from: JPortici on August 05, 2024, 01:59:37 pmCorrect, I don't know how I missed the *don't* bit out, but you're right, that is exactly what I meant.Regarding forthcoming devices, I expect to see ethernet as there's an RMII interface on the EV74H48A Curiosity dev board. USB 2.0 HS would be a choice of mine.

author: JPortici
author_rank: Super Contributor
timestamp: August 05, 2024, 08:18:32 pm
content: Quote from: Howardlong on August 05, 2024, 03:26:35 pmUnless it comes with an SPI controller/phyQuoteSame. USB full speed for bog slow PIC24, but not anymore for dsPIC, or PIC18 for that matter. I've been asking that for years..

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 05, 2024, 08:25:28 pm
content: Quote from: JPortici on August 05, 2024, 01:59:37 pmCan they capture to 400MHz/2.5ns as well, or is that 2.5ns only PWM out ?

author: NorthGuy
author_rank: Super Contributor
timestamp: August 05, 2024, 09:26:13 pm
content: Quote from: JPortici on August 05, 2024, 08:18:32 pmYes, USB HS would be great for dsPIC33, but, they don't even use USB FS. If you compare dsPIC33A with PIC32MZ. Both running at 200 MHz. Home come PIC32MZ gets its USB HS while dsPIC33A doesn't.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 05, 2024, 09:44:18 pm
content: I guess the market is just not there? It's interesting to see that USB HS is still a rarity in MCUs and usually reserved for the "performance" ones (like Cortex-M7 based) with very few exceptions, especially if you're looking for one with an integrated PHY.That's one point which makes me like the CH32V30x.

author: Howardlong
author_rank: Super Contributor
timestamp: August 05, 2024, 10:01:59 pm
content: Quote from: SiliconWizard on August 05, 2024, 09:44:18 pm... and (relatively) high pin count. Trying to find USB HS on an MCU with fewer than 64 pins isn't easy: good to see the CH32V30x suggests it can even do it in a 20 pin package. And GigE on >= 64 pins with external phy.

author: JPortici
author_rank: Super Contributor
timestamp: August 06, 2024, 06:59:55 pm
content: Quote from: Howardlong on August 05, 2024, 03:26:35 pmAnother reason for Ethernet: Automotive ethernet

author: jnk0le
author_rank: Regular Contributor
timestamp: August 23, 2025, 12:11:21 pm
content: So, the Microchip released PIC32AK which is exactly the same thing as dsPIC33AK, but without the "DSP" in the namehttps://www.microchip.com/en-us/product/PIC32AK1216GC41064#Overview

author: iMo
author_rank: Super Contributor
timestamp: August 23, 2025, 12:51:56 pm
content: Hmm, "up to 128kB flash.."

author: Howardlong
author_rank: Super Contributor
timestamp: August 23, 2025, 03:24:44 pm
content: QuoteA couple of months ago, they released a 512kB flash version of the dsPIC33AK, and some silicon fixes... while introducing some new bugs, of course ;-)It also has a buck core regulator rather than a linear regulator, so power draw is about half of the earlier family in my tests.QuoteIt's still not clear to me why they released a functionally identical processor with a different name.It iscovered over on the Microchip forumwhere a product manager explained it, kind of ;-)A marketing side effect is that the PIC32AK is currently configurable with their Harmony framework tools, whereas the dsPIC33AK isn't, it still uses MCC... and from bitter experience with this device, it's an unfinished steaming pile, which is why I very quickly switched to bare metal with it whenI developed my AM radiowith it.Regarding the rationale for a new proprietary core, I just didn't get it at first. However, having developed a few projects with it over the past year or so , I do get it. The main core isn't RISC, but most instructions still take a single cycle (as long as you deal with the pipeline properly, which you have to do on RISC too), despite offering a plethora of addressing modes across most instructions.So you can combine both read and write indirection together with autoincrement/decrement in a single instruction. Especially for typical DSP applications which typically perform operations on in-memory arrays that exceed the processor's register set, it makes a lot of sense. This is achieved with both multiple busses and, crucially, multiple address generation units.In a store-load architecture of the likes of ARM, MIPS or RISC-V, you'd be looking at several instructions to achieve the same thing, although to be fair you'd also approach the task at hand in a fundamentally different way anyway on such an architecture. You'd still be looking at at least double the number of cycles though to achieve the same thing.On the other side of the coin, the FPU coprocessor very much dictates a store-load paradigm as those addressing modes are only available during store and load operations. It's a vary good FPU though: sin() and cos() in silicon, 4 cycles a pop if you wait, and effectively a single cycle if you pipeline it. Although a small thing, transcendental functions in silicon make this a unique microcontroller, as I'm not aware of any device in this class with such functionality.And at about $1.50 for a pair of 40MSa/s ADCs** that's dirt cheap.** Note that this is a bit of marketing bollocks, as although you can capture at 40MSa/s, that's only in bursts, not continuously. It drops down to about 32MSa/s for continuous sampling, and even then you have to use interleaving to achieve that.

author: iMo
author_rank: Super Contributor
timestamp: August 23, 2025, 06:42:14 pm
content: Can it do sampling with 2 ADCs simultaneously? That is a basic requirement when talking DSP or SDR today (I/Q)..

author: Howardlong
author_rank: Super Contributor
timestamp: August 24, 2025, 07:55:13 am
content: Quote from: iMo on August 23, 2025, 06:42:14 pmYes. And the newer dsPIC33AK512 family devices have 5 of these 40MSa/s ADCs, and all can be operating concurrently, assuming there's enough bus bandwidth remaining for the results ;-)Quote... only if you're still dependent on analogue downconverters rather than direct conversion. How quaint! ;-)To explain...If you can sample at twice the the target frequency of interest, and have enough processing power to perform any necessary frequency conversion in the digital domain, then there's no reason for I/Q to ever exist in the analogue domain. This is how I did theAM receiver with these chips.Furthermore, as an alternative, if you're prepared to perform filtering in the analogue domain, and the ADC has sufficient front end bandwidth, you can use undersampling at a much lower rate than Nyquist. This is why some ADCs have much higher analogue bandwidths than seems necessary for their maximum sampling rate. I don't know how applicable this is to these PIC devices, as their ADC input bandwidth isn't specified.FWIW, I believe that undersampling is howthis broadcast FM radio works. It only samples at 10MSa/s, yet is resolving a radio station in the FM broadcast band.QuoteThe reality is that, in many cases, the effort and cost required for required to present analogue filtering for subsampling often exceeds the effort and cost to use analogue quadrature downconversion to I/Q, which is where your supposition holds entirely true. It does mean, however, that further effort needs to be executed in the digital domain to correct for errors from the analogue domain. Examples of these corrections are image rejection, DC offset and 1/f noise: none of these are problems that crop up when downconverting in the digital domain (but downconversion in the digital domain does introduce new rabbit holes!).