Why I'm switching from STM32 to PIC32

[rea5245-stm]

Posted on January 26, 2013 at 19:19

An Open Letter to ST Micro

I'm switching my development projects from the STM32 to Microchip's MIPS-based PIC32. I'm a hobbyist, so my concerns may be different than the pros' here - and the impact of my decision on ST's business is negligible - but perhaps some of my reasons will reveal opportunities for ST to improve its products. I started out using Microchip's 8 bit uCs. But I'm a software engineer by trade, and I hated programming in C; I wanted to use C++. So I went to Digi-Key and searched for 32 bit uCs in a DIP package (so that I could breadboard with them). This was before NXP's ARM in a DIP, so PIC32 was the only option. But it didn't have a C++ compiler. So I chose the STM32, because I thought I'd be able to put its LQFP-48 on a DIP board. A note about the ST Discovery boards: it's great that ST makes these available so cheaply. But they're just too big. They don't fit on a single solderless breadboard, and even if they did, they have a horizontal row of pins that are incompatible with the breadboard. Finally, if you want to put them in the final project (remember, this is a hobby project) they take up too much space. It would be great if ST made a 40 pin, 0.6'' wide DIP board. And a note about 3rd party DIP boards and Arduino: they're too expensive. $30 or more. Yeah, it's a one-off hobbyist project, and yeah I can afford $30. I guess I'm just a cheapskate. (And I can guess how much companies like ST like having cheapskate customers giving them advice. :) ) So I made my own (it ended up being 0.8'' wide) and called it the

http://www.galacticstudios.org/blackknight/

http://www.galacticstudios.org/blackknight/

board, since you can cut pieces off it and it keeps working. :) I assembled a free toolchain from Eclipse, Eclipse's CDT, Code Sourcery's gcc, and TrueSTUDIO's gdb - and let me tell you, it was a royal PITA getting them all working - bought an ST-Link/V2, and got to work. I was writing a very cool C++ layer for accessing the STM32's peripherals. It used template metaprogramming so that it compiled to extremely efficient code. You could do things like wrap the UART template (or the SPI template, or any other device's template) in an Async template, instantiate the object, and painlessly have the device driven by interrupts and communicate via the RTOS' queue mechanism. There were a few snakes in paradise, though. First, my failure rate for assembling Black Knight boards was at least 50%. Second, although many people are assembling the same toolchain I did, it's still feels poorly documented, poorly supported, cobbled together, kludgy, and fragile. Third, starting a new project was tough: aside from struggling to assemble a new Black Knight that works, Eclipse, as configured, didn't provide helpful wizards for creating a new project. Keil and IAR, of course, have nice wizards but their free versions are limited to 32K. Rowley has a reasonably priced unlimited version that I considered. But all of these have limited editing tools and primitive UIs compared to Eclipse or Visual Studio (which I use at my day job for Windows development). Late last year, Microchip came out with a C++ compiler. It's free, with no code size limits, if you're willing to live without the optimization features (not a big problem for hobbyist use). Their new IDE is based on NetBeans which is competitive with Eclipse. There's no difficulty in assembling the toolchain as there is in the ARM world: you download the free IDE from Microchip, download the free compiler from Microchip, and It Just Works - including debugging. They still have their 28 pin DIP PIC32. If I ever need 40 pins, their TQFP-44 package has a 0.65mm pin pitch, which I hope will be significantly easier for me to solder than STM32's LQFP-48 0.5mm pitch. Microchip has made two major decisions that companies in the ARM world have not. First, Microchip has decided that they're in the business of selling chips and that the software helps them do that. So they give the software away for free. Second, Microchip has decided that hobbyists are their friends. So they make their chips available in DIP packages (and have one of the most generous free sample policies in the industry - but there I go being a cheapskate again). AVR has made these same decisions and scored with the Arduino culture. Arduino may not add a lot to their bottom line, but perhaps it gets professionals hooked on the AVR architecture. Microchip has certainly noticed: they're promoting an Arduino-like PIC32 platform and environment. Microsoft made a similar decision. They want to sell operating systems, so they give away versions of their compilers for free. And while they have fewer features than the commercial versions, they don't have crippling limitations like Keil's and IAR's 32K limit. On to peripheral programming: while CMSIS provides a common software architecture across ARMs, the specifics of different manufacturers' peripheral devices limits the portability and thus the value. Meanwhile, it's a clumsy API. You need to stuff values into a struct, then call a function that unstuffs them. As I was writing my template framework for device control, I kept gloating to myself that it generated so much more efficient code than CMSIS. Microchip provides a library of functions for controlling its peripherals. It's less portable to other vendors' chips than CMSIS, it's not elegant, and it's not well documented (though it's at least as good as ST's CMSIS docs). But it's higher level, easier to use, and more code-efficient. My advice to ST is this: (1) assemble a free toolchain and make it easily downloadable and installable. Add some plug-ins to it to help people get started with ST development. Feel free to make it ST-specific so it doesn't help your competitors. (2) Come out with some hobbyist-friendly form factors. Either put an STM32 in a DIP or make a ''mini Discovery'' board with 28 to 40 pins and about 0.6'' wide. I suspect either option needs to be treated as a loss leader (but I suspect the current Discovery boards are already loss leaders). If it helps, I don't think the ST-Link needs to be integrated onto it the way it is on the current Discovery boards. Similar 3rd party boards have a USB connector and a bootloader. Debugging isn't as good as with an ST-Link, but you can also provide pins for the ST-Link. See my link above for my Black Knight board to see what I mean. (3) Write a higher level API for controlling STM32 peripherals. Obviously, you need to keep CMSIS. But having something easier to use would be a selling point. I hope some of this was useful.

[flyer31]

Posted on January 27, 2013 at 12:14

I came from Microchip (dsPIC33) to STM32F4 about 1 year ago, and I did not regret it.

What helps you the ''completely integrated'' development pack, if your chips are lacking the newest features like Floating point machine or Hi-Speed USB (at this time I did not know the great debugging possibilities of ARM - this run-time debug stuff is so good, that alone due to this I would now never go back to Microchip). I hope ST concentrates their smart people in further hardware improvements like: - double precision Floating point (while probably ARM will have the most work here) - including double or quad core devices - increasing RAM and ROM size - increaseing speed - (possibly also it would be nice to include a certain amount of configurable logic into such processors - sometimes very helpful in shuffling data through DMA channels beyond processor speed - see the older Cypress Hi-Speed USB 8051 devices) Concerning Microchip, I had the impression that they somehow underestimated the effort to build their own tool chain and keep it alive with all the new operating system and so on. So then somehow they missed keeping there products at the front (the dsPIC33 had been very much at front when they came out several years ago ...). MikroElektronika btw. also tried sometimes hard to push their on Microchip tool system - but of course if you have ''in-house competition'' from the chip manufacturer Microchip himself, this is not a good motivation for any third-party developers. But interestingly enough, MikroElektronika is coming in to the ARM market with C, Basic and Pascal, and I think this might get very interesting for hobby people. One point is great from Microchip: This is their application support. Seen from my point of view, it is a bit strange that ST does not offer an advanced demo board based on STM32F4 to do advanced Motor control, Encoder control, Hi-Speed USB, power control ... . But of course this also can bind quite a bit of smart people at such a company, and it is questionable whether this is really worth the point. (Just I think sometimes such application support PCBs with software are somehow nice student's projects - ST could try to do this even by some sort of ''hobby competitions'' - this would maybe be a good way to get fruitful contact to the ''hobby community''). PS: BTW I just saw that MikroElektronika offers a DIP40 plug-in based on STM32F415 (Mini M4).

[rea5245-stm]

Posted on January 27, 2013 at 15:16

Bil, could you elaborate on ''great debugging possibilities of ARM - this run-time debug stuff''? What debugging features does STM32 offer that PIC32 doesn't have?

[flyer31]

Posted on January 27, 2013 at 15:57

Have a look at this:

http://www.keil.com/appnotes/docs/apnt_230.asp http://www.youtube.com/watch?v=Be4V9yZPo6E

[rea5245-stm]

Posted on January 27, 2013 at 16:12

Bil, that does look cool. As a hobbyist, I'm not willing to pay $1400 for it, so it's irrelevant to my decision. But I can see why it would influence the decision made by a company developing a product. (The same is true of the floating point hardware and high-speed USB: important to companies; less important to hobbyists.)

[flyer31]

Posted on January 27, 2013 at 16:46

If you think you need 1400$ for this, then you did not read it very thoroughly.

Most of all works already with the quite basic ST-LINK interface which you get with every ST4-Discovery. Mainly you can watch AND CHANGE all RAM values during runtime - this is extremely useful. Also the interrupt occurance tracing and the log buffer tracing. Only the full ETM instruction trace, which is only the very last part of the document, needs the 5 pin ETM port with the high  speed ULINK pro interface.

[frankmeyer9]

Posted on January 28, 2013 at 11:49

I'm a hobbyist, so my concerns may be different than the pros' here...

As a hobbyist, you are surely fine with your decision, so there is no reason to argue. My company uses Microchip products, and wants to get away from it. The 8-bit controllers are a retro market, mostly for longtime customers unwilling to switch. In technical terms, they are a PITA. Most of the DIL packages are for professional customers, and not primarily made for hobbyists. The newer 16 and 32-bit controllers seem not to sell as good as intended. Technically, they are behind the ARM world in performance per MHz and performance per Watt. And Microchip has a hard time to compete with the ARM world over the price. And a second reason to switch is the ''all from one hand'' approach. One can interpret it as ''all in one hand'', say, customer lock-in.... and I hated programming in C; I wanted to use C++. C++ never actually established in this low-performance / low-RAM niche, for good reasons. I remember several threads, complaining about the huge size of a C++ ''hello world'' version. We are in the mass market, and 10 ... 50 cent make a huge difference. So if it can be done in C with the smaller MCU, you are out. I don't want to bash C++, but it presupposes virtually unlimited memory, and thus doesn't fare too well with this requirements. But as said, this doesn't need to concern you as hobbyist. For my private projects, I stay with ARM (but not only ST), and my requirements are similiar to yours.

[rea5245-stm]

Posted on January 28, 2013 at 15:58

So fm, what do you use for your private projects? Do you have a DIL ARM platform you use? What toolchain do you use (and what do you use at work - and how do they compare)?

[frankmeyer9]

Posted on January 28, 2013 at 17:05

Do you have a DIL ARM platform you use?

A matter of interpretation. I don't use any ARM Cortex in a DIL package, albeit some exist (see NXP). There are some nice LPCXpresso boards, which have a DIL like pinning, as have the smaller discovery boards. That DIL issue has probably not that important for me, as it has for you.So fm, what do you use for your private projects? Adding to that HW list above, the TI - LM4F120, on a launchpad board. For toolchains, there was a longer evolution, that ended with a CrossWorks personal licence. I grew tired of crippled evaluation/free versions, which don't allow any project of serious size. I tried free toolchains, which IMHO had two particular drawbacks: First, they worked only for one MCU or small MCU family (like for STM32F4xx targets). And second, they have really limited debug adapter support. About two years ago I spent a few days investigating the VL_Discovery support under linux. Not again. Since I'm not in my twenties anymore, I don't have the time for such excursions. At work, I deal with mostly PIC18F. Currently I use the XC8 compiler, which was labeled ''HiTECH'' before. The professional version achieves pretty good results, compared to the CC18. But the price is surely out of reach for hobbyists, equivalent to Keil/IAR. I regarded the old MPLab as a PITA - the new MPLabX is more pleasant to work with. We evaluated dsPICs for a project about two years ago, but they where lacking some crucial peripheral features, and had really mediocre compiler support. That might have changed now, but that's too late. For ARM, we are going to use Keil uVision. Since I had been working with uVision3 for 8051, that is pretty familiar. A loooong time ago, I had been working with VisualStudio 5, on C/C++ projects. Definitely another level. It makes a huge difference if you have support from C/C++ libs and a full-blown OS, or not. Addendum: I might repeat myself, but this forum software is a PITA, too.

[flyer31]

Posted on January 28, 2013 at 18:03

I remember several threads, complaining about the huge size of a C++ ''hello world'' version.

Hi fm, sorry, but this I cannot keep standing. I switched to C++ (together with STM32F4 to ARM) about 8 months ago, and I checked very carefully that the code size did NOT increase (not even by 1 Byte) when switching from C to C++. Just I use a quite restricted C++: - no virtual functions - no base classes - no new/delete functionality (which would imply memory alloc...) This sounds very restricted - I thus mainly enjoy the possibility to use a clear public/private organisatoin of variables and functions, and the great possibility in C++ to use inline functions and variable access functions (to create variables which are in effect read-only for ''out of class'' functions). This sounds not very big, but I recognize it as very useful - in increases my confidence in coding quite a bit.