Energy Micro, the Norwegian ARM licensee, have expanded their Gecko Cortex-M3 product line with 100 new processors. These provide a range of features, from a huge 1MB of memory on the Giant Gecko family, to a tiny 400nA back-up power mode for power saving devices.

Available for as little as $2.47, these micros offer an excellent option for low power, high functionality devices.

For further details, see here.

Over the past 18 months or so, Atmel have put a real push into getting the most out of their ARM9EJS-based CPUs. They have managed to boost the clock speed, increase the peripheral set, reduce the power, and reduce the cost all in one go. These new chips, the AT91SAM9G20, AT91SAM9G45, and very recently release AT91SAM9M10 all run at 400MHz, with peripherals covering image sensors, ethernet, video playback (hardware accelerated on the M10!), as well as the usual set of UARTS, I²C, etc.

The big breakthrough with Atmel however has really been the power consumption and price. The AT91SAM9G20 core consumes only 80mW at full speed, and can be purchased for as little as $16 in single quantities, down to $7 in larger volumes.

Here at Bluewater we have taken great interest in these Atmel development, and have incorporated these into our new module, as well as our (upcoming) 9G45 design.

During development there are often situations in which a device is left in an unbootable state. Its flash memory has been erased, or incorrectly written, such that the unit performs no useful operation on startup. Generally, this is also how the units will be initially after assembly. Once in this state specialised tools are required to program the units. Typically, this would be JTAG, involving some kind of external JTAG adapter. This works well, as JTAG gives full access to all elements of the CPU. However, it is not without its drawbacks.

• As standard it requires a 20-way connector, which is quite large in board real-estate.
• It requires dedicated CPU pins to be routed appropriately.
• The software is often not easy to automate reliably for programming units in the factory.
• It requires an external JTAG adapter, and associated software. These are often not easily usable by an inexperienced operator.

With Atmel's AT91SAM range of CPUs, they have included a built in Boot-Rom which runs a protocol they've called SAM-BA. This code allows CPUs to be put into a programming mode when commands can be sent either over USB or the debug UART. Using this mode, we have successfully been able to program our Snapper 9260 at rates of approximately 30kB/s. This is more than ample to allow simple and reliable reprogramming of these units, using just a standard USB cable. To automate this, we've developed a SAM-BA based scripting tool, available from https://bluewatersys.com/quickstart/9260sambootassistant.php. This tool is customised for our environment, and supports several useful features

• NAND support, for read, write & erase of the on-module NAND devices.
• U-Boot environment support. This allows automatic programing of U-Boot environment variables.
• YAFFS2 image support, allowing creation & writing of a YAFFS2 filesystem directly to the NAND flash.

Using these features we can reprogram a unit, from completely erased to a standard factory level, in just a few minutes, including the boot loader, kernel and filesystem. While this is not fast enough to be suitable for factory production, it is quite suitable for the occasional situation when someone accidentally erases their system.

Previously we spoke about our efforts to optimise the boot time of our Snapper 9260 module, getting it down to ~5s. Having done a bit more work on the hardware, software, and moving to the AT91SAM9G20 module, we now have this down to ~3s from initial power applied. This is a full boot, with peripherals initialised, reading from NAND Flash for its root filesystem etc. Having used a lot of embedded systems over the years, we are very pleased with this result, as it certainly out performs all the similar devices we have seen in its class.

When developing an embedded Linux system, there are a large number of choices available, not just in terms of hardware components, but also software. A Linux system is not just about the kernel, but also the user-space software layer that sits above it. Some of the most commonly chosen options are:

• Custom/Hand-built - in some ways this is probably the most common. It allows the most flexibility, and generally results in the tightest integration. It does however require the most developer effort, and the most on-going maintenance.
• OpenEmbedded - this is a source-based Linux distribution system. In some ways it is a meta-distribution, allowing for your own customised distribution to be made. It requires a reasonable amount of initial setup effort, but once configured additional packages can be trivially added. As its named implies, this system is targeted towards embedded systems, and a lot of effort has been made to ensure it is easy to make small installations using it.
• T2 - this is another meta-distribution, although it is not solely targeted towards the embedded market, or even only Linux. As with OpenEmbedded, it allows for a large amount of flexibility
• EmbeddedUbuntu/ Embedded Fedora/EmDebian - Several of the larger Linux distributions have started to target the embedded market. They have the advantage of a huge existing installation and package base, but also have the disadvantage of a large amount of desktop/server baggage that generally isn't required on an embedded system.

Each of these systems has their own merits, and there is definitely no correct answer for all situations. At Bluewater, we have made the decision to go with a mixture of a custom & OpenEmbedded solution. We start with the BusyBox minimal suite of tools. This provides almost all of the standard Linux command line utilities. Using just BusyBox, and the libraries from the GCC compiler tool chain, we are able to get what we call our minimal root filesystem into around 3MB. This can be shrunk even further by using a smaller C library, and a cut-down selection of BusyBox's utilities. From this base, we then add packages using the OpenEmbedded distribution. These are easily added, and once we have built up our core repository of packages we can easily make custom filesystems for different projects. As with any development system, care must be taken not only to the suitablity of the solution with respect to the product, but also with respect to the developers using it. The wrong choice can result in a nightmarish mix of package versions and build environments, where only the most grand Linux guru can find their way out. The correct choice however results in a system as easy to manage as a desktop PC, where packages can be added and removed trivially, meaning developers are free to choose the packages that best solve their problems, rather than those that are the easiest to install.