If you haven't already got one, head over here and pick up an mbed board for a small sum of money. With it you can:

• Play with a real piece of ARM hardware
• Write code in C/C++ using a web-based IDE
• Develop software without installing any tools on your computer
• See what lots of other people have done with this great little device
• Have a program running in under a minutes (yes really!)
• For US$59 it has to be one of the lowest cost ways into ARM

This unit is very similar to the Snapper UDIP module we created a few years ago, but the bug innovation is that you don't need to worry about tools. It connects to your computer over USB and you interact with it via a web site.
Sorry, we don't sell these, but see here for lots of options in various countries.

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.

We've recently come across a fantastic article in Keil's latest newsletter that we'd like to share.  This article discusses the benefits of Cortex-M3 for real-time applications, the modifications done to RTX to support Cortex-M3 and how this results in twice the performance over RTX running on ARM7TDMI. Have a read and let us know what you think! RTX Article

When using the Realview ICE, there are normally portions of the development that are often repeated. Loading and executing a specific image for example, or configuring the SDRAM controller to allow normal development to proceed. These are typically done either in a simple compiled program, or using the inbuilt scripting available in the Realview Debugger. When using the graphical environment however, even when using a single executable, the time taken to click on all the buttons to execute the task can seem laborious. However there is another method available - using the RDDI network protocol to communicate directly with the ICE unit. This protocol allows for all of the standard JTAG operations to be performed automatically from code. At Bluewater we have developed a minimal scripting interface which communicates over this API to automate the tasks which we often perform. This means that with a single click we can bring up a completely un-programmed board into a running state, upload the latest version of our code, and begin executing it with no further interaction. When dealing with a large variety of different development boards, this can be vital in ensuring that information on how to deal with each one is not lost - the script provides all the information necessary. As the details of the actual JTAG operations are still left with the ICE, all the performance advantages of the ICE are still in effect. Operations available from the RDDI network protocol include:

• Resetting the target
• Setting & retrieving register values
• Uploading images to memory
• Downloading images from memory

A sample library is provided by ARM for these purposes, available from http://www.arm.com/products/DevTools/RDDIRVI.html.

For our Big-Eye project (a 3.1 Megapixel network camera for security and remote monitoring applications), we needed an efficient software algorithm for converting the Bayer-format data used by the image sensor to RGB data suitable for sending across the network / JPEG compression. A simple C algorithm was coded which did the job. However, it was very slow - about 1.7 seconds to convert a single frame. This was using GCC 4.1.1. The code was fairly well written, using word operations to move through the three lines of the image, two pixels at a time. It was not looking good. After spending a bit of time trying a few basic optimisation techniques, we decided to try the RealView compiler. This now supports most of the GNU options and it is fairly easy to build software using it. The result was pretty astounding. With no code changes, RealView produced an execution time of around 0.3 seconds! A bit of additional fiddling suggested that further improvements might be possible. The main difference seems to be that RealView makes much better use of registers, and thus needs a lot less load/store on the stack. This is probably a common feature of many image processing algorithms. If written with efficiency in mind, they will push the register set quite hard. Much assembler optimisation relies on using the register set more efficiently. But if the compiler can do it for you, so much the better. We could easily have spent a few days working on this part of the code, and with RealView it was just a re-compile. In the end we have moved all the code over to RealView and this is now the standard build environment.