dsPIC33A: new 32bit DSP!

[JPortici]

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/Store

And while skimming the US MASTERS program.. wow

This class introduces the features and architecture of the dsPIC33A family of devices. Content includes core features and use of select peripherals including 40 MPSP ADC, floating point unit, and high resolution PWM. Differences and advantages from earlier dsPIC33 devices are presented along with application examples. Attendees will gain understanding of the dsPIC33A family of devices and their capabilities.

In this class you will see and experience the latest innovations in a new 200 MHz Digital Signal Controller including double precision floating point unit, 32-bit instruction and data paths with dual 72-bit accumulators together with a suite of fast peripherals designed to accelerate your real-time applications. This class will explore fast signal acquisition and related signal processing in a new and robust manner with Microchip's latest dsPIC family of devices. Material included will utilize this device for a rudimentary digital storage oscilloscope and then process these input into the frequency domain using FFTs using this processor core.

so 40MSPS ADC (and the ADC in the dsPIC series is good)
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.aspx

Ah, i wish they will do EU Masters..

[tszaboo]

Read the errata. Microchip introduced already the PIC32MZ with a fast ADC, where the errata was: "ADC doesn't work at all"

[PCB.Wiz]

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/Store

Interesting.
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.

[jnk0le]

Adding the ‘A’ at 6th letter is a strangely subtle way to signal a large architecture jump.

They should have named it "dsPIC65" to follow the tradition of confusing naming.

[JPortici]

Read the errata. Microchip introduced already the PIC32MZ with a fast ADC, where the errata was: "ADC doesn't work at all"

Traditionally speaking the analog part in 16bit hardware has always been very good
But this will sure be a different design so fingers crossed

Interesting.
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.

I 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.

[dmendesf]

Anyone got news about this part? 40MSPS could well be used here...

[glenenglish]

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...

[JPortici]

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...

though this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exit
and peripheral set! don't forget about that

a dsPIC is still running circles around PIC32 and cortex M3

[bhave]

I bet there are some nice changes to the core.  Your Microchip rep might be able to provide a preliminary data sheet under NDA.

[glenenglish]

"
though this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exit
and 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.

[iMo]

"
though this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exit
and 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.

Yep, 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)..

[Sal Ammoniac]

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)..

The 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).

[iMo]

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..

[tszaboo]

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..

I 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.

[JPortici]

"
though this is going to be the same fast core but 32bit ALU, cpu, fast interrupt enter/exit
and 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.

I'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.

[SiliconWizard]

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..

I 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.

Yes 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).

[NorthGuy]

but then in the 2010s they went to sleep and  let Cortex M3, M4, M7  take their  market. 

Speaking of markets. These are all public companies so you can get real figures. Compare for example NASDAQ:MCHP and NYSE:STM

dsPIC 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.

[PCB.Wiz]

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.

Yes, 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 ?

[uer166]

Very interested mainly for DSMPS work, where:

• TMS320 is a too big of a pain in the ass
• Cortex-M7 has too high latency/too much cache bullshit

I can't find any preliminary datasheets of any kind however

[iMo]

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..

I 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.

Yes 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.)..

We 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.. 

[mtwieg]

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.

• TMS320 is a too big of a pain in the ass

I'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).

[uer166]

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.

• TMS320 is a too big of a pain in the ass

I'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).

Different 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.

[Sal Ammoniac]

We 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..

I 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).

[NorthGuy]

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).

This 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.

[Sal Ammoniac]

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).

This is because of the debugger (part of MPLAB X), not silicon.

It 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.