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. A 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.
-- Larry Standage
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 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 addition 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) formats 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.
--Sal Ammoniac
No comments:
Post a Comment