Choosing Embedded Processors for AltOS
When Bdale and I started building rocketry hardware together, we had
already picked out a target processor, the TI
cc1111.
We picked that chip almost entirely based on the digital transceiver
that is built in to the chip, and not because we had any particular
love for the 8051 microcontroller. At that time, I’d seen people
struggle with PIC processors, battle AVR to a draw and spend a lot of
time trying to get various ARM processors running. So, the 8051 didn’t
seem all that far from normal, and the cc1111 implementation of it is
pretty reasonable, including credible USB support and a built-in DMA
engine.
Since those early days, we’ve gone on to build boards with a slightly
wider range of processors:
TI cc1111
Atmel ATmega32U4
Atmel ATiny85
STMicroelectronics STM32L151/STM32L152
NXP LPC11U14
Bdale thinks we should reduce the number of components we use to focus
our efforts better. He’s probably right, but I have to admit that I’ve
had way too much fun getting each of these chips running.
I thought I’d spend a bit of time describing our general process for
selecting a new CPU.
Free software. I’m long past the age at which I trust hardware
vendors to deliver credible binary software. If you want me to use
your silicon, make sure the tools required to use it are all free
software.
Debian support required. Bdale and I do everything on Debian, so
any processor we use needs to have tools that run under
Debian. We’re more than willing to package software for Debian, so
if it’s just generic Linux-compatible free software, that’s fine.
Built-in USB. Everything we build needs to talk to a computer for
configuration and data download. Don’t even think of asking me to
attach another chip for USB support. Ok, so the ATtiny85 doesn’t
qualify here, and that project does use an external chip for USB
which is connected to the ATtiny85 through an LED and
phototransistor. I was excited when TI came out with the
CC340
chips because the MSP430 is a much nicer CPU than the 8051. But,
they still haven’t added USB. If I’m going to add another chip for
USB, it’ll be a CPU anyways, at which point I’ll use a stand-alone
RF chip.
Cheap developer boards. TI sells a tiny little cc1111 developer
board; STmicroelectronics and NXP both sell boards that include a
programmer and a target CPU for prototyping software. And, there
are a million “Arduino” clones with various Atmel processors on
them. Cheap means I can buy them without thinking too hard; having
a built-in programmer means that early OS development can be done
without first having to figure out how to wire up a programmer.
Probably 32 bits, probably an ARM. Yeah, the cc1111 and Atmel
processors were fun to bring up, but I’m pretty much over the 8-bit
microcontroller now. ARM processors are far more sophisticated in
terms of power management and built-in device capability, plus
they’re a ton faster at doing any math. The ATtiny85 remains an
exception here; it’s smaller than any ARM I can get, and so it’s
still useful for projects too small for an ARM.
Available in small quantities from a reasonable on-line retailer
like Digikey, Mouser or even Avnet Express. I’d love to try out the
new low-cost STM32L100 parts, but the only one available is the
largest one in the 64LQFP package, and I really don’t need that
many pins for most products.
CC1111 involved a lot of software hacking
The 8051 processor in the CC1111 is very well documented, including
the two-wire debugging interface. What was missing was a canned
solution for programming and debugging the chip from Debian. However,
with sufficient motivation and accurate docs, I was able to create a
programmer from a USB device with a couple of GPIOs and a lot of ugly
software on Linux. That sufficed to get the USB stack limping along,
at which point I wrote a much faster programmer that ran on the cc1111
itself and could program another cc1111.
With that, I created an assembly-level debugger that could be hooked
to the existing SDCC source level debugger and had a full source-level
debugging environment for the 8051. This turned out to be way better
than what I could get on the Atmel processors, where I’ve got a
program loader and a whole lot of printf debugging.
STM has been great
The STM32L-Discovery board has a standard STM debugging setup for the
Cortex SWD interface right on the same board as a target CPU. That
made for completely self-contained development, with no jumper wires
(a first for me, for sure). There’s free software,
stlink which can talk over the
debugger USB connection to drive the SWD interface. This is sufficient
to flash and debug applications using GDB.
Of course, GCC supports ARM quite well; the only hard part was
figuring out what to do for a C library. I settled on pdclib, which is
at least easy to understand, if not highly optimized for ARM.
We’ve built a ton of boards with the STM32L151 and STM32L152; at this
point I’m pretty darn comfortable with the architecture and our tool
chain.
Adventures with NXP
The NXP LPC11U14 is a very different beast. I’m using this because:
It’s small (5mm x 5mm)
It’s cheap ($1.48 q100)
The LPCXpresso board looks much like the STM32L-Discovery, with a
debugger interface wired to the CPU directly on the board. However, I
haven’t found free software tools to drive this programmer; all I’ve
found are binary-only tools from NXP. No thanks.
Fortunately, the LPC11U14 uses exactly the same SWD interface as the
STM32L, so I was able to sever the link between the programmer and the
target on the LPCXpresso board and hook the target to an ST-Link
device (either the one on the STM32L-Discovery board, or the new
stand-along programming dongle I bought). With that, I wrote an
openocd script to talk to the LPC11U14 and was in business.
What I found in the NXP processor was a bit disturbing though —
there’s a mask ROM that contains a boot loader, which always runs when
the chip starts, and a bunch of utility code, including the only
documented interface to programming the flash memory. I cannot fathom
why anyone thought this was a good idea — I don’t want a BIOS in my
embedded CPU, thankyouverymuch; I’d really like my code to be the
first instructions executed by the CPU. And, any embedded developer is
more than capable of programming flash using a register specification,
and calling some random embedded code in ROM from the middle of my
operating system is more than a bit scary.
NXP could do two simple things to make me like their parts a whole lot
more:
Publish the programmer source code. The programming dongle is a
tool for selling your silicon, not a separate revenue stream.
Publish the source under a free software license (GPL recommended,
of course). We’ll take it, make it better, and ensure that you get
the changes back to help your other customers. It’s a win-win plan.
Document the flash programming registers. Yeah, I could probably
disassemble the mask-rom bits that are on the chip, but I have
better things to do with my time. Heck, go wild and document any
other hidden bits in the silicon. Again, we’re embedded developers,
we don’t like magic hardware hidden from view any more than PC
developers like the BIOS and SMM.
Right now, I’m hoping the STM32L100C6 parts become available in small
quantities so I can try them out; they promise to be as cheap as the
LPC11U14, but are better supported by free software and offer more
complete hardware documentation. Yeah, they’re a bit larger; that will
probably be annoying.