• AVR Freaks

Helpful ReplyPIC32 vs STM32

Author
hisoka
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2015/11/30 04:49:14
  • Location: 0
  • Status: offline
2015/12/26 12:23:04 (permalink)
0

PIC32 vs STM32

Hello,
 
How does the PIC32MX or even the PIC32MZ stand a7gainst STM32F4 or the newer STM32F7 ?
Is it worth to migrate to the STM32 family ?
I am interested in these parameters :
1. speed (MIPS) and which one is faster reading and writing to I/O pins , simple math operations(summation and subtractions for integers)
2. interrupt latency (I noticed that for pic32mx the latency for external interrupt is quite high)
3. simpler architecture ? more deterministic instruction execution time (in PIC32MX is not simple to guess how much time needed to execute a tot instruction ) ?
4. I've noticed that the STM32 have more than 40 external interrupts instead of the 5 external interrupts for PIC32
 
Thanks
#1
RISC
Super Member
  • Total Posts : 5376
  • Reward points : 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 12:56:37 (permalink)
4 (1)
Hi,
The only way to answer your questions is to do benchmarks. Anything else is marketing...
There is no way to "predict" execution time as soon as processors have cache, pipeline, and wait states.
An intimate knowledge of the compiler / architecture also makes a difference.
Regarding external interrupts, you probably did not see that some PIC32MX / PIC32MZ have so called "Change Notification". They are equivalent to external interrupts and some PIC32 have many of them.
I/O toggling depends of the C style and wheter you know the specific registers which are sometimes present and do bit toggling in a couple of cycles (at least on PIC32MX).
Regards
#2
Howard Long
Super Member
  • Total Posts : 677
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 13:12:11 (permalink)
4 (2)
When choosing a microcontroller, it's not just about marketing baseline numbers and benchmarking.

In the real world yes, it's about that, and peripheral features, but also a quite significant bias will be about the investment and experience that's already in place and available. So that's not just about compilers and development environments that might've been invested in, it's about skillsets too.

Always be careful of looking at randomly picked things from a data sheet. It's only when the pedal hits the metal and you have real experience that you can separate the wheat from the chaff. And toggling an IO port pin is a very long way from a real life scenario.

On the PIC32MX1/2 series, by the way, it is very deterministic.
#3
hisoka
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2015/11/30 04:49:14
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 13:26:39 (permalink)
0
RISC
Hi,
The only way to answer your questions is to do benchmarks. Anything else is marketing...
There is no way to "predict" execution time as soon as processors have cache, pipeline, and wait states.
An intimate knowledge of the compiler / architecture also makes a difference.
Regarding external interrupts, you probably did not see that some PIC32MX / PIC32MZ have so called "Change Notification". They are equivalent to external interrupts and some PIC32 have many of them.
I/O toggling depends of the C style and wheter you know the specific registers which are sometimes present and do bit toggling in a couple of cycles (at least on PIC32MX).
Regards




PIC24 have predict execution time for example.
The problem with "Change Notification" is at you don't know the source of the interrupt (which pin)
#4
hisoka
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2015/11/30 04:49:14
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 13:36:56 (permalink)
5 (1)
Howard Long
When choosing a microcontroller, it's not just about marketing baseline numbers and benchmarking.

In the real world yes, it's about that, and peripheral features, but also a quite significant bias will be about the investment and experience that's already in place and available. So that's not just about compilers and development environments that might've been invested in, it's about skillsets too.

Always be careful of looking at randomly picked things from a data sheet. It's only when the pedal hits the metal and you have real experience that you can separate the wheat from the chaff. And toggling an IO port pin is a very long way from a real life scenario.

On the PIC32MX1/2 series, by the way, it is very deterministic.



I've used PIC for long time but now I need faster microcontroller , for me PIC32MX at 80 MHz isn't enough for me
PIC32MZ have many problems so I thought about to use STM32F7
#5
RISC
Super Member
  • Total Posts : 5376
  • Reward points : 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 14:13:52 (permalink)
3 (1)
Hi,
There are various generations of PIC32MX : 80 / 100 & 120MHz.
Which issues do you refer to ?
PIC32MZ...EF has very few errata.
Regards
#6
hisoka
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2015/11/30 04:49:14
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 14:30:21 (permalink)
5 (1)
RISC
Hi,
There are various generations of PIC32MX : 80 / 100 & 120MHz.
Which issues do you refer to ?
PIC32MZ...EF has very few errata.
Regards


PIC32MZxxEF have problem with crystal , I2C and UART problems
#7
NorthGuy
Super Member
  • Total Posts : 5548
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: PIC32 vs STM32 2015/12/26 14:51:47 (permalink)
3 (1)
It is absolutely impossible to answer unless you tell what you need to do and how fast you need it.
#8
Larry.Standage
Super Member
  • Total Posts : 906
  • Reward points : 0
  • Joined: 2011/12/30 09:50:47
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/26 19:39:23 (permalink)
4.86 (7)
Four things to consider:
 
1) Probably 99.999% of embedded processors have errata. You might want to check ST's website, because their processors have errata. The STM32F7 series have errata on the UART and I2C.
 
Some of the STM32F7 errata even include errata on the ARM core itself, and you have to go to ARM's website for the details. Having written the errata for both MZ products (EC and EF), and updated ones on MX products, I know there aren't any that are directly connected to the MIPS core itself. I think I'd prefer a core I can depend on.
 
So it really is a matter of which errata are more impactful.
 
2) The cost of the STM32F7 parts is upwards of 80% higher than a PIC32MZ part, where memory is roughly equal. Even the 2M PIC32MZ part is around 50% less expensive than the 1M STM32F7.
 
So the ARM core may (or may not) be a little better in performance, and you're paying a premium for it.
 
3) Company stability and performance is very important. Doing some checking, ST has not had a profitable quarter of more than $0.12/share in the past four years, and only the last 6 quarters have been profitable in that time. This probably makes them a ripe target for acquisition, because some things could probably be done better from a business perspective.
 
Microchip just celebrated 100 consecutive quarters of profitability, with earnings as high as $0.69/share two quarters ago. Microchip will be around a lot longer than ST at this rate.
 
4) Do you know whether the STM32 product is going to be available over the lifetime of your product? I counted 21 STM32 products on ST's website marked "NRND", meaning you don't want it in new product development, because they may not make those much longer. And who knows what other products they're thinking about discontinuing. Even their "10 Years Longevity Commitment" means you can really only count on 10 years of production (and one of those years is already gone for a lot of them!) And if ST were to be acquired by another company, take that "commitment" and throw it in the trash.
 
There have been no PIC32 products discontinued or marked for discontinuation. In fact, there are still customers who use (and buy) the old PIC16C54 (non-Flash!) products from the mid-1990s! Granted, we try to encourage migration to the Flash-based parts, but we're still producing them anyway.
 
In summary, there are a lot of things to consider besides just "PIC32" vs. "STM32", processor speed, errata, etc.
#9
NKurzman
A Guy on the Net
  • Total Posts : 17626
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: PIC32 vs STM32 2015/12/26 20:51:17 (permalink)
4 (1)
The question is migrate from what.
Migrating from a pic32mx or a pic24 is easier than to ARM.
There is no the Best CPU. You need to look at the application and perpiherials.

The eratta for the MZ is relatively. minor.
It works with an external oscillator. Which is not the expensive any more.
The i2c is ok at 100khz. And will be fixed next spin for 400khz. (A rep will tell you if that is in you time frame)
The UART eratta is not core functionality.
the time an effort to select and move to ARM needs to be checked. And the cost of the tools.
#10
hisoka
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2015/11/30 04:49:14
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/27 00:42:49 (permalink)
3 (1)
Larry.Standage
Four things to consider:
 
1) Probably 99.999% of embedded processors have errata. You might want to check ST's website, because their processors have errata. The STM32F7 series have errata on the UART and I2C.
 
Some of the STM32F7 errata even include errata on the ARM core itself, and you have to go to ARM's website for the details. Having written the errata for both MZ products (EC and EF), and updated ones on MX products, I know there aren't any that are directly connected to the MIPS core itself. I think I'd prefer a core I can depend on.
 
So it really is a matter of which errata are more impactful.
 
2) The cost of the STM32F7 parts is upwards of 80% higher than a PIC32MZ part, where memory is roughly equal. Even the 2M PIC32MZ part is around 50% less expensive than the 1M STM32F7.
 
So the ARM core may (or may not) be a little better in performance, and you're paying a premium for it.
 
3) Company stability and performance is very important. Doing some checking, ST has not had a profitable quarter of more than $0.12/share in the past four years, and only the last 6 quarters have been profitable in that time. This probably makes them a ripe target for acquisition, because some things could probably be done better from a business perspective.
 
Microchip just celebrated 100 consecutive quarters of profitability, with earnings as high as $0.69/share two quarters ago. Microchip will be around a lot longer than ST at this rate.
 
4) Do you know whether the STM32 product is going to be available over the lifetime of your product? I counted 21 STM32 products on ST's website marked "NRND", meaning you don't want it in new product development, because they may not make those much longer. And who knows what other products they're thinking about discontinuing. Even their "10 Years Longevity Commitment" means you can really only count on 10 years of production (and one of those years is already gone for a lot of them!) And if ST were to be acquired by another company, take that "commitment" and throw it in the trash.
 
There have been no PIC32 products discontinued or marked for discontinuation. In fact, there are still customers who use (and buy) the old PIC16C54 (non-Flash!) products from the mid-1990s! Granted, we try to encourage migration to the Flash-based parts, but we're still producing them anyway.
 
In summary, there are a lot of things to consider besides just "PIC32" vs. "STM32", processor speed, errata, etc.




you've convinced me grin: grin
#11
maxruben
Super Member
  • Total Posts : 3348
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: PIC32 vs STM32 2015/12/27 02:12:24 (permalink)
3 (1)
You say that you need fast I/O access - Depending on what this is for you might look for a processor that can handle this directly in the hardware (DMA and/or peripheral) which will be faster than bit banging.
 
Or perhaps consider an FPGA solution.
 
/Ruben
 
post edited by maxruben - 2015/12/27 02:17:21
#12
Sal Ammoniac
Super Member
  • Total Posts : 216
  • Reward points : 0
  • Joined: 2011/11/27 14:04:14
  • Location: 0
  • Status: offline
Re: PIC32 vs STM32 2015/12/31 15:15:26 (permalink) ☄ Helpfulby karpouzi 2016/01/08 01:27:34
4.75 (4)
Here's my take on this question based on my having used the STM32F4, STM32F7, PIC32MX, and PIC32MZ recently.
 
Speed wise, the PIC32MZ is roughly equivalent to the STM32F7. They both run at around the same clock rates (216 MHz for the STM32F7 and 200 MHz for the PIC32MZ). The PIC32MX is outclassed by the STM32F4, however, as the fastest STM32F4 runs at 184 MHz versus only 120 MHz for the fastest PIC32MX.
 
The PIC32MZ still has unresolved errata, but so does the STM32F7, so this is a tie. The PIC32MX series and the STM32F4 series both seem to be reasonably stable at this stage in their lifecycles.
 
With interrupt latency it's no contest. The PIC32 has twice as many registers as an ARM Cortex-M and saving all of them during an interrupt is both time consuming and a manual operation (the chip doesn't automatically save any of them on an interrupt). The Cortex-M parts not only have half as many registers, but the chip automatically saves a subset of them on an interrupt. The chip and the compiler cooperate to the extent that it's not necessary to do anything special when writing interrupt handlers -- they can be simple C functions, unlike on the PIC32 series where you need to use special wrappers using non-standard C constructs such as __attribute__((interrupt(IPL3SOFT), vector(_SPI2_TX_VECTOR))) in front of each interrupt handler to generate the code to save registers and to generate the return from interrupt instruction at the end of the function.
 
The Cortex-M architecture is more modern, and I think cleaner, than the MIPS32 architecture used by the PIC32. I don't think this really matters to an embedded engineer primarily concerned with writing embedded application code, but to me, as an RTOS designer, the Cortex-M makes things a lot simpler and cleaner.
 
As far as on-chip peripherals go, it seems to me that the PIC32 peripherals are both simpler and easier to understand than their counterparts on the STM32 parts. STM seems to take a "let's throw in everything including the kitchen sink" philosophy with their peripherals, which is a common theme across the various Cortex-M vendors. Their peripherals often have functionality not needed by 99.9% of users. I'd prefer that they spend the time making the peripherals more solid instead (the I2C peripheral on the STM32F3 series was notorious for its quirkiness).
 
As far as development environments go, you have far greater choice with STM32 (or any ARM part for that matter). In additional to any development environments provided by the manufacturer of the chip, you also have a choice of many third-party tools from vendors such as Keil, IAR, Rowley, and others. I don't know of any PIC32 development tools other than MPLAB/XC32 provided by Microchip. The advantage of a tool such as Keil or IAR is that they support all manufacturer's ARM Cortex-M parts. You can use the same tools to build and debug code for STM32, NXP LPC, Infineon XMC, Freescale Kinetis, etc.
 
STM32 has a big edge in hardware debugging tools. The ST-Link/V2 is only about $21 versus $48 for the PICkit3 (Mouser prices). The ST-Link/V2 is not only much faster than the PICkit3, it's also faster than the $200 ICD-3. If you need an isolated debugger, the isolated version of the ST-Link/V2 is only $78. To get an isolated Microchip debugger, you need to go to the Real ICE, which is $500 and add the $300 isolator to it.
 
I'd give a slight edge to Microchip documentation over the STM32 documentation. There are places in the STM32 documentation where the grammar gets awkward, and I attribute this to the fact that English is probably a second language to the writers of the STM documentation. One thing I like about the STM documentation is that the reference manual is in a single PDF file versus the multiple file (one per peripheral) format used by Microchip.
 
Availability of development boards is very similar. I'm actually surprised at the number of PIC32 development boards available from 3rd parties. It's much larger and varied than I would have expected. STM themselves offer a range of very inexpensive Nucleo and Discovery development boards ranging from less than $10 to around $50 for the STM32F7 Discovery board.
 
So it's a real toss up. The STM32 and PIC32 series are both solid choices with good support. I'd give the nod to STM32 for development tools (hardware and software), availability of inexpensive development boards, CPU architecture, and ecosystem, while PIC32 gets the nod for simple, easy to understand peripherals.
 
#13
rbuck
Super Member
  • Total Posts : 345
  • Reward points : 0
  • Joined: 2005/04/28 12:48:11
  • Location: Phoenix, AZ
  • Status: offline
Re: PIC32 vs STM32 2015/12/31 22:03:10 (permalink)
4 (1)
I purchased a STM32d0discovery board from Mouser a few months back. I played with it for a few days and tried several different freeware programming tools before finally settling on EmBlocks. It took a couple of days to figure out how to read the switch on the discovery board and flash the LEDs. So the ARM learning curve will be somewhat steep. There are so many different things that have to be set. For example, you can't just activate IO pins. You have to actually assign a clock to the IO Peripheral for the IOs to work. All the peripherals seem to have similar requirements.
 
I never did find a freeware tool that would allow debugging. I ended up downloading the ST-Link utility to allow programming of the chip as EmBlocks doesn't have a programming option that I could find. The lowest cost programming/IDE/debugging tool I could find was Crossworks. I didn't download the trial version to play with as I put the discovery board aside and said I would investigate it more at a later time. Other than Crossworks, I could not find any ARM development tools that were reasonably priced. Microchip wins this one hands down with their tools. MikroElektronika does have development tools for PIC32. But Microchip has provided tools for over 20 years and I don't see the need to change.
 
I just started using the PIC32 for a project. I have been using PIC10,12,16,18, and 24 for over 20 years. It took a couple of days to adapt to the PIC32 but I now have a fairly good handle on how it works. The one mistake I made was not reading the errata sheet for the PIC32MX130F064D. It turns out I got bit on a couple of things. I read the errata when some things didn't work. This part has been out since 2012. They have made updates to the silicon but it seems like when they fix one thing they break 3 others. Or break something that they had previously fixed. For instance, they say the internal pullup resistors may not pull up strong enough to present a valid high to external devices. Their work around was to "always use external pullups". It doesn't make sense that there would be a problem with something as simple as pullups resistors. Especially since they have been in all their products for over 20 years.
 
Another thing that really doesn't make sense about the PIC32 is the RTCC. If you are going to provide one on chip, why not have one of the pins dedicated for battery backup? You have to jump through hoops and add extra hardware to power the RTCC when power is lost.
 
But, as I am totally familiar Microchip products, I will stick with them for the time being. I will eventually dabble more in-depth with the STM32 as it is always good to have extra options in your tool bag.
#14
Jump to:
© 2019 APG vNext Commercial Version 4.5