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.

[rea5245-stm]

Posted on January 28, 2013 at 18:12

You certainly lose a lot of C++'s power when you have no virtual functions, no base classes, and no new/delete. People complain about the ''bloat'' that these features cause, but let's not forget that you get benefits with that increased size. Benefits like a more functional application, faster development, and better maintainability.

The ''bloat'' is not gratuitous. It serves a purpose.

[frankmeyer9]

Posted on January 28, 2013 at 20:43

The ''bloat'' is not gratuitous. It serves a purpose.

Correct. It is the ''basic toolset'' of C++. And often, a lot of it is in your code, if you use it or not. But this really becomes a problem if you run it on something like the VL_discovery (STM32F100RBT6) with 8k of RAM. That really hurts.

[20072007]

Posted on May 13, 2014 at 11:13

St devices have this very good compiler available, free and goo

http://www.coocox.org/CooCox_CoIDE.htmAnother point is that Arm have more supplyers, means more competion, and more improvements at better prices,

[Tesla DeLorean]

Posted on May 13, 2014 at 19:11

Another point is that ARM have more suppliers, means more competition, and more improvements at better prices,

Well this totally misrepresents the market space, I'm sure Microchip understands that all the me-too ARM players are their competition, and will drive price and speed of their offerings. Both MIPS and ARM have GNU/GCC toolset. MIPS is a very interesting RISC architecture, as is SPARC, they are in more things than you think, and are actually a stronger competitive driver for ARM than it's own licensees.

[johannv99]

Posted on March 25, 2015 at 13:53

I agree, CooCox is a very good free tool,

and the compiler toolchain is included with the installation.

[dan239955_stm1_st]

Posted on April 12, 2015 at 21:58

I have started a new open source IDE project, which solves a lot of these problems. It is Windows based (mac and Linux coming soon) It is very simple to install and setup straight, configures all the compilers and toolchains, etc for you, it currently supports all STM32 and PIC32, and many more ARM Cortex devices.

It supports, JLink, STLink and many more debug adaptors via openOCD. It is still early stages, with a few bugs, but it is useable already. My main reason for starting this was some of the same feelings that the OP had. If you are familiar with Visual Studio you will instantly feel at home. I would be very interested to hear from anyone wishing to try it out, provide feedback and even contribute to the project. It is an original design, not based of eclipse, or netbeans and all the bloat they have. Supports C / C++ development out the box. I will try and make some YouTube tutorials soon to show people how to get started. Have a look, see what you think I hope I will receive constructive criticism! Be gentle I wasted about a year of my life to get this into the state it is today. :)

http://www.vitalelement.co.uk/

[Tesla DeLorean]

Posted on April 12, 2015 at 22:42

Hopefully you didn't actually use Visual Studio as the basis, like Atmel's tool, cause that thing is a veritable sloth.

[dan239955_stm1_st]

Posted on April 12, 2015 at 22:52 I did originally consider some kind of Visual Studio plugin, but who wants 8gb minimum install for an embedded IDE, plus its tied to Windows, this is a completely fresh approach. It is pretty snappy, but as I said its really early beta stage, so some things are a bit unpolished and it does sometimes lock up, however over the next month or so these issues should be resolved / ironed out. .  If you are interested in trying it out I'd be grateful for any feedback and I have a Hello World ''Blinky'' project that can be used to get started. I can send that across.

[childresss]

Posted on April 13, 2015 at 04:51

I've used these IDEs and I disagree with the the claim that Visual Studio is a 'sloth'. Atmel Studio, based on Visual Studio 2007, is OBE since VS 2013 Community came out, and the VisualMicro plugin for ARM and other embedded.

From a professional use viewpoint, with some avocational use:

• Visual Studio 2013 Community (Free) is the best FREE IDE I've used.
• VisualGDB (very good, almost free)
• IAR EWARM - My favorite for professional work -well worth the $.
• Keil/MDK (runner-up to EWARM)
• Eclipse (too non-intuitive, time-waster)
• Rowley (good but uses GCC)
• Atollic (not good and uses GCC. Not intuitive)
• Code::Blocks (incomplete)
• ImageCraft (lacks C++, one man show

Let's not have another my IDE can beat up your IDE.

[joemccarr]

Posted on December 15, 2015 at 22:21 Imagecraft has a IDE with compilier & debugger for $99 for the STM32 devices. It is their non-commercial license. They have their own API also.  I bought their tools but have no other connection with the company.