PIC32MM, a Cortex-M0/M0+ contender?

[benSTmax]

I got a newsletter today and one of the titles got my attention. So, it seems like Microchip has launched the PIC32MM series which seems to address the same market as the Cortex M0/M0+. 

Lately, I have been using MCUs from Microchip (8 and 32-bit parts) but also some CM0+ and CM4 (from the former Freescale and ST), so I'm not bashing the Microchip nor the ARM camps.
Looking at the high-level specs of the PIC32MM it seems it has some nice features (dual CLC and PPS) but in the same time some others seems outdated(e.g. the 300ksps 10-bit ADC and 5-bit DAC).
Some of the peripherals seems taken straight from some 8-bit parts (e.g. 5-bit DAC) while others from the 32-bit families.

I will definitely get a couple of these parts to try them out. I think Microchip has a nice offering right now with both MIPS and ARM core parts(from former Atmel).
Even though the low-power figures look good, I would take them with a grain of salt(especially when they came from Microchip  ) and declare myself satisfied only after I'll try out the chip and measure the low-power currents for myself.

Some links:
http://www.microchip.com/promo/pic32mm/
http://www.microchip.com/stellent/groups/pic32_sg/documents/devicedoc/en586396.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/40001851A.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/00002191a.pdf

[JPortici]

500 nA sleep current seem nice
soic,sdip package available, nice.
single cycle multiplication for 16x32 bit, two cycle for 32x32, meh
hardware divide. that's really nice
the errata is very short, nice (but it's been out for so little time so there might be a lot of nasty stuff happening)
but the peripherals on the chip are quite poor.

But i have no idea of what to use one for, instead of a dspic for example.
However, if microchip would integrate the core with a radio..

[hans]

Low power is still lacking behind the ARM competition though.

7mA at 25MHz
2.5mA at 8MHz

That's still in the order of 300uA/MHz. Most energy friendly cortex m4 ARM chips have much lower figures, but it's slightly better than other PIC32s I believe (they were in the order of 500uA/MHz).
0.44uA sleep with 0.4-1.0uA RTC and <0.1uA WDT seems very typical these days, but a major step compared to other PIC32s. So that's nice, especially when your board is in sleep for very long times. Additionally, in things like IoT, it's likely the radio will dominate the power budget anyway.

Seems like they have used the PPS peripheral from the PIC24 family. I didn't like the one used in other PIC32s with arbitrary patterns in the PPS choices. It was a bit of a hassle to figure out which PPS you need to pick for a particular SPI port to map correctly.

The peripherals seem quite typical of microchip; to the point and simple. Not excessively complex like some ARM chips are.

All in all I think it's a nice chip, but it's entering a field of some heavy competition with many cortex m0 chips.

[andersm]

The part support has been in Microchip's compilers for I think well over a year, you could get a pretty good high-level overview by datamining the headers. The current compiler has support for unreleased PIC32MK, PIC32WK and PIC32MZ DA parts (true to form, Microchip China have placed the MZ DA datasheet online).

EDIT: The PIC32 FRM chapter on the control DAC boasts 12-bit resolution, while the PIC32MM datasheet only gives 5 bits. I guess there's a reason this thing launches at silicon revision B0?

[benSTmax]

The part support has been in Microchip's compilers for I think well over a year

I remember seeing those PIC32MM files in the compiler installation directory, however this is the 1st time I see the full datasheet of this part.

[ebclr]

If you are looking for low power you must try  the gecko

http://www.silabs.com/products/mcu/32-bit/Pages/32-bit-microcontroller-technology.aspx#low-power

[JPortici]

PIC32WK

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM320102-1

[dannyf]

Sounds like a msp432, a 32 bit core plus old peripherals.

I think it is the right aoproach. From a programmers perspective, the coore is uninteresting. What matters is the peripherals.

Personally a M0 or M0+ core plus old peripherals would have been preferred as a replacement for 8 or 16 bit chips.

[nctnico]

Personally a M0 or M0+ core plus old peripherals would have been preferred as a replacement for 8 or 16 bit chips.

Why would you want to get stuck with old 8 bit peripherals? Things like a 32 bit timer make life a lot easier. Also newer peripherals -in general- tend to have stuff like DMA, deeper FIFO's and other useful stuff. Tie that together with basically being locked in by buying the compiler from Microchip I see no advantage at all versus using an ARM based microcontroller.

[asgard20032]

Sounds like a msp432, a 32 bit core plus old peripherals.

I think it is the right aoproach. From a programmers perspective, the coore is uninteresting. What matters is the peripherals.

Personally a M0 or M0+ core plus old peripherals would have been preferred as a replacement for 8 or 16 bit chips.

MSP432, a 32 bit core with old peripheral? What are you talking about? The peripheral that msp432 got is  very similar to msp430 (and most of the time, it is the same one with no modification). But the msp430 is all but old peripheral. It is a nice modern von neuman architecture with many modern peripheral that are quite capable and powerful. The peripheral that msp430 got is comparable with baseline ARM (if we just forgot the dma part). Look at msp430f5529 datasheet and msp430f5 family user guide. The ADC, the timer, everything is powerful and modern. Of course, there is old msp430 with outdated peripheral, but msp432 is not based on those first generation, but on more recent family like f5 family. The only downside to msp430 is the lack of CAN and ethernet, but if we forgot those two, a msp430 got more than enough in peripheral than most people would need.

[JPortici]

Tie that together with basically being locked in by buying the compiler from Microchip

The compiler have improven, a lot. I am finishing an age old weekend project with a dspic33e, i don't know exactly when it happened but now optimization 1 (basic optimization, works in free version) reduce the code size a lot and you can still use the debugger with all the functions

i remember years ago i couldn't step with the disassembly or use the call stack, the debugger would return "can't access to xxx. are you using optimization > 0?"

then i took a look at the disassembly and i left it there, good code.

and PIC32 should be using GCC for the compiler, i don't know if they can actively put garbage on it, or anyway you should be able to recompile it without the licencing (i read it somewhere here that it should not be difficult as in theory the licensing only checks for the serial number, then enable opt > 0, it doesn't alter the compiler)

[Kjelt]

IMHO too late, M0 is already taking over that specific market segment in price/performance wise.
Unless these chips have something unique to serve some niche marketsegment.

I do not understand their strategy, they bought Atmel who sells M0 chips and now they offer something similar but not compatible? Betting on multiple horses or are these the last painfull convulsions of the dying old microchip uC division?

[mikeselectricstuff]

I see no advantage at all versus using an ARM based microcontroller.

Choice of packages, including DIP
Same devtools for 8,16 and 32 bit parts
Manufacturer with a long track record of good availability and not obsoleting parts
Availability of low-cost programming/marking service from manufacturer

....And that's before looking at details of the actual parts

[dannyf]

"I do not understand their strategy, they bought Atmel who sells M0 chips and now they offer something similar but not compatible"

What else do you expect from microchip? The only thing consistent about microchips strategy is that they are always late to the game. Their focus sseems always to protect their 8bit business.

In the end, their success there is killing them.

[ebclr]

"Choice of packages, including DIP"

Very few when compared to all arm producers

"Same devtools for 8,16 and 32 bit parts"

You will need to pay for each one and is not the same, devtool only the IDE is the  same all, compilers is a different product

"Manufacturer with a long track record of good availability and not obsoleting parts"

Only ONE manufactures, arm space have dozen with a muck long track record


"Availability of low-cost programming/marking service from manufacturer"

For sure microchip dev tool isn't low cost, maybe low quality but not low cost, arm programming tool is cheaper  and better, in fact you can program arm with more than 10 different programmers from different vendors

....And that's before looking at details of the actual parts

[mikeselectricstuff]

"Choice of packages, including DIP"

Very few when compared to all arm producers

How many ARM makers do multiple packages for the same part ?  Or evan make any low pin-count packages at all?
Not looked recently but I only recall seeing NXP doing any DIPs

"Same devtools for 8,16 and 32 bit parts"

You will need to pay for each one and is not the same, devtool only the IDE is the  same all, compilers is a different product

My angle here was familiarity & re-learining new tools. Unless you're doing high volumes, using a familiar devtool can easily work out cheaper overall than using a cheaper part that means you need to learn a new toolchain.
The IDE, programmers and debuggers are the same. The compilers are similar enough that you can switch easily.
Purchase cost is a non-issue when doing commercial work, and the free versions of the 16 and 32 bit compilers are entirely useable for a large proportion of applications.

"Manufacturer with a long track record of good availability and not obsoleting parts"
Only ONE manufactures, arm space have dozen with a muck long track record

Which ones exactly ? NXP have been bought so uncertain, and they had a track record of up-reving chips and obsoleting the old ones, Atmel have a poor track record of obsoleting, and have been bought. Several other players haven't been around long enough to  establish a track record.

"Availability of low-cost programming/marking service from manufacturer"

For sure microchip dev tool isn't low cost, maybe low quality but not low cost, arm programming tool is cheaper  and better, in fact you can program arm with more than 10 different programmers from different vendors

What does that have to do with my point about being able to order pre-programmed parts?
As regards programmers, there are plenty of third-party PIC programmers, probably at least as many as ARM. And they fully document their ISP protocol. (Have ARM SWD docs ever been formally released by any manufacturer?)
And Microchip is one of the few makers that produce programmers, which means you're guaranteed that new parts will be supported as soon as they come out, which is rarely the case for third-party programmers.

[andersm]

I do not understand their strategy, they bought Atmel who sells M0 chips and now they offer something similar but not compatible? Betting on multiple horses or are these the last painfull convulsions of the dying old microchip uC division?

The PIC32MM would have been started long before the Atmel acquisition even came up as a possibility. Besides, Microchip will want to continue catering for their customers who have bought into the ecosystem.

[andersm]

and PIC32 should be using GCC for the compiler, i don't know if they can actively put garbage on it, or anyway you should be able to recompile it without the licencing

Both XC32 and XC16 are based on GCC, with source code available as per the GPL. The libraries and support files are not.

[andersm]

How many ARM makers do multiple packages for the same part ?  Or evan make any low pin-count packages at all?
Not looked recently but I only recall seeing NXP doing any DIPs

Several manufacturers have low pin count versions of M0/M0+ parts, I don't know anyone else bothering with DIP (Nuvoton or some other white-goods supplier may have some).

As regards programmers, there are plenty of third-party PIC programmers, probably at least as many as ARM. And they fully document their ISP protocol. (Have ARM SWD docs ever been formally released by any manufacturer?)

The debug port is defined by ARM, and the docs are available from ARM's website if you register. Microchip have (AFAIK) never publicly documented their two-wire debug interface used in the PIC32s, or their debugger protocols, so if you don't want to use their tools you have to use JTAG. Not a huge problem, but an annoyance nevertheless.

[JPortici]

"Choice of packages, including DIP"

Very few when compared to all arm producers

not really, there is only one M0 in dip package as far as i know, there are several pic32 in soid/ssop/spdip

You will need to pay for each one and is not the same, devtool only the IDE is the  same all, compilers is a different product

when is the last time you used them? you don't need to pay nothing, optimization 1 has become very good recently.

For sure microchip dev tool isn't low cost, maybe low quality but not low cost, arm programming tool is cheaper  and better, in fact you can program arm with more than 10 different programmers from different vendors

pic32 can be programmed/debugged using jtag. all new dspics (and i think a couple of the new 8 bitters) can be debugged with jtag.
oh, sure a j-link cost less than an ICD3.. we also built our own production programmer based on the available schematic anyway

[nctnico]

My angle here was familiarity & re-learining new tools. Unless you're doing high volumes, using a familiar devtool can easily work out cheaper overall than using a cheaper part that means you need to learn a new toolchain.

That is the fun part: I have been using GCC + Eclipse for 99.9% my microcontroller development(from various vendors) for the past 10 years and Eclipse for all (including PIC).

Which ones exactly ? NXP have been bought so uncertain,

No, it is the other way around: NXP bought Freescale and I strongy doubt NXP is flushing over a decade worth of business building in favour of the Kinetis parts which have been around for 2 or 3 years.

As regards programmers, there are plenty of third-party PIC programmers, probably at least as many as ARM. And they fully document their ISP protocol. (Have ARM SWD docs ever been formally released by any manufacturer?)

NXP ARM chips don't need a programmer. A USB-UART converter does the job due to their bootloader (the protocol is fully documented). As a bonus the programming port is also a UART so great for debugging and monitoring.

[mikeselectricstuff]

NXP ARM chips don't need a programmer. A USB-UART converter does the job due to their bootloader (the protocol is fully documented). As a bonus the programming port is also a UART so great for debugging and monitoring.

From what I recall when I used them a while ago  it was very slow compared to JTAG/SWD due to using low baudrates and inefficient ASCII transfer - is this stil the case ?

[mikeselectricstuff]

The debug port is defined by ARM, and the docs are available

Does that cover device programming though?
Last time I looked ( a while ago), device flash programming was typically done by manufacturer-specific undocumented protocols over JTAG/SWD.

[Kjelt]

Choice of packages, including DIP

who except some hobbieists will use this anymore? And from the hobbieists market no silicon manufacturer could ever profit.
If needed perse you can always use an adapter pcb.

How many ARM makers do multiple packages for the same part ? 

ST!

Or evan make any low pin-count packages at all?

ST!

[nctnico]

NXP ARM chips don't need a programmer. A USB-UART converter does the job due to their bootloader (the protocol is fully documented). As a bonus the programming port is also a UART so great for debugging and monitoring.

From what I recall when I used them a while ago  it was very slow compared to JTAG/SWD due to using low baudrates and inefficient ASCII transfer - is this stil the case ?

Define slow. It only takes a few seconds and IIRC the data is transferred in binary form with a CRC check (and retries if the data is corrupted). All in all it is a very safe way to program a microcontroller.