CrossWorks and SolderCore, the Platform API

For a long time now, I've been working on an API that will help customers, and particularly hobbyists, get up and running quickly with CrossWorks and SolderCore.  The decision process on what to put into the API, and particularly what to leave out, was interesting.

At Rowley Associates we have a whole wall stacked with magazine files which contain each and every ARM board that we have acquired.  Right now, the tally is over 600 ARM boards.  Most of these are supported in CrossWorks by board support and CPU support packages which so customers can program those boards without needing to construct header files, write and then debug flash loaders, type in boring memory maps, and so on.  Now, writing demonstration code for all these to have them do something more than flash a LED or respond to a button is a big challenge.

To reduce things to a manageable level, I looked around for something that I could develop for that would enable me to take a LEGO-style brick approach to constructing interesting, useful software.  After a while, it was evident that the Arduino footprint was very popular, had an ever-expanding range of third-party shields.  And, with that popularity, other CPU architectures were leveraging the Arduino form factor.  So, I decided to construct software that would target an Arduino footprint, but on non-AVR architectures.

So, let's take a quick tour of the available Arduino-format boards that I have acquired and am developing for:

• SolderCore, of course.  Stellaris.
• Freedom Board.  Kinetis.
• BugBlat Cortino.  STM32F1.
• Olimexino-5510.  MSP430F5510.
• Olimex STM32-E407.  STM32F4.
• Maple.  STM32F1.
• Netduino.  SAM7X.
• Netduino Plus 2.  STM32F4.
• freeSOC.  PSoC5.
• Olimexino-328P. Yes, a clone, but pretty nice anyway.
• mbed, using a TestBed board.  LPC1000.
• Arduino Due.

There are, of course, other Arduino-format boards, such as the chipKIT, but I am not directly developing the CrossWorks Platform API for these because CrossWorks doesn't support them!

These is one other board that is having the Platform API ported to it, but we'll park that on one side for the moment.

As of today, I have a whole set of software that I can compile for SolderCore, the Freedom Board, the Olimexino-5510, and the Arduino Uno.  No source changes.  The sensor libraries work on each of these different architectures because the Platform API takes care of dealing with the tedious nature of getting hardware set up for GPIO, I2C, SPI, PWM, and ADC functions.  On top of those libraries, I've written mid-level libraries for driving LCDs and getting graphics onto them, supporting mass storage with FAT file stores, and using TCP/IP over Ethernet.  And sitting on top of that is a bunch of demonstrations that will exercise sensors and do interesting things using them.

So, the question is, I guess, when to release all this?  Well, it takes a lot of testing, but then CoreBASIC and SolderCore is built upon the CrossWorks Platform API.  I think that I will release them when CrossWorks 3 debuts, as I use some of the CrossWorks 3 library features to have the software work nicely.

What I can say is that it's pretty cool writing an application that uses the Platform API and then seeing that application run on completely different hardware "just like that."  Sort of the way reusable software is meant to be.

What are the downsides?  Well, of course, writing generic software means that many device-specific features simply get washed away and are just not supported by the Platform API.  That's intentional: if you need those features, write a device-dependent module for it!

The other downside is that you're a bit further away from the hardware and performance may suffer because of the calling overhead.  Well, that's tough, what you pay to get a clean API is a small performance penalty.  It's worth it.