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 Snapper 9G20 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 http://www.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.

For several of our projects we have had to use a Logic Analyser to determine the proper working of an existing system. The results of a captured session on the Logic Analyser is a large binary file representing the state of all 136 of its inputs, over a period of time, at around 2ns granularity. This gives an enormous amount of data which must be then viewed by the operator to determine where a problem lies. Some aspects of this can be eased through the user interface on the Logic Analyser - colouring relevant lines, or giving textual labels to certain values. But mostly it is a manual process. We have developed a protocol definition system which allows us to describe the protocol, and then automatically process the traces from the Logic Analyser, decoding the results into a human readable form. This give a double benefit - we can analyse an existing system to determine how it is working, producing our parser as we go, and once this is completed we can then run it against our own implementation to verify that it conforms to the original system. As the Logic Analyser is a completely generic digital interface, it can process almost any signaling system. Using this technique we have written protocol definitions for the following buses:

• 8250-compliant UART bus
• Kennedy tape drive bus
• Pertec tape drive bus
• SCSI bus
• NAND control & data bus
• PCI bus
• SPI bus
• CFI-compliant NOR flash bus
• DM9000 Ethernet controller bus
• Image Sensor interface bus