More microcontroller woes
My good experiences with STMicro's STM32 family and bad experience with the Freescale development "philosophy" got me curious; Where do the other Cortex-M vendors fall along that spectrum?
- STMicro -- Provides straightforward zip files of libraries and code examples.
- Freescale -- Provides an eclipse-oriented environment/code generator as part of a ginormous download, with no meaningful access to libraries or example code. Certian components are windows-only.
- Atmel -- Provides a ginormous development environment only, apparently built on Visual Studio so it's Windows-Only.
- Energy Micro -- Provides a windows-based tool (built using MinGW!) that lets you obtain the core libraries and examples. and the "software download" link on their site is broken.
- NXP -- Provides a straightforward zip file of libraries and code examples.
In other words, Cortex-M vendors are still more tilted towards the tradtional "our-way-or-GTFO" microcontroller vendor approach embodied by Freescale, but they're tending towards the greater openness that ARM is trying to achieve with first CMSIS and now mbed.
In other news, I have my CMSIS microcontroller development framework up and running. It currently supports ARM Cortex-M0, M0+, M3, and M4 cores and the full STM32 (ie F0/F1/L1/W1/F2/F3/F3) family. Adding additional platforms should be pretty easy as long as the vendor supplies a CMSIS port. I'll be adding Energy Micro and NXP ports later today, I hope.
You can find it on my site's git repo
All components, including the (modern GCC/Linaro) toolchain, are suplied
in source form and the environment builds and links everything for you.
All you need to do is supply a main() function and take it from there.
Why go through this effort? First, there's no meaningful code or documentation out there on how to leverage the (vastly superior IMO) Unix/GNU toolchain and workflows when workring with Microcontrollers. Tools (even compilers) and development environments tend to be highly proprietary and require inferior operating system platforms. They also tend to target rapid prototyping (And thus have a ton of handholding that gets in the way when you know what you're doing) and tightly lock you in to using that particular vendor's platform, encouraging highly non-portable and non-resuable code. They also tend to encourage horrible development practices.
Heh, I think I've just re-articulated ARM's rationale behind their mbed project. My effort isn't entirely overlapping however; ARM's leveraging C++ to target the rapid prototyping folks first, effectively abstracting all the hardware away, but I'm targetting experienced developers, who want a bare-metal C-oriented approach so you know exactly what's going on.
I don't know how far I'll take this thing; it's almost to the point where it's sufficient for my needs, but I'm releasing it to the world in the hope that others find it useful. I know I'd wished for something like this when I first started hacking on microcontrollers!