AnsweredAssumed Answered

Why I'm switching from STM32 to PIC32

Question asked by alexander.bob on Jan 26, 2013
Latest reply on Dec 15, 2015 by McC.Joe
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 Knight 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.