We have been maintaining a version of the Linux 2.6.20 kernel for around 2 years time now.  Since 2.6.20, a number of features have been added to the mainline kernel which are of interest to us.  Some of these new features are:

• Support for the AT91SAM9G20
• System on chip camera support
• Improved WiFi support
• SDIO and SDHC card support
• Power supply class for managing batteries

In addition to support for new features and drivers, there are a number of benefits to using a recent kernel:

• It is easier to get support with issues and bugs.
• Patches posted on mailing lists are easier to apply to recent kernels.
• It is easier to port patches developed against a recent kernel to be considered for mainline acceptance.

Andrew Morton discussed some of the above benefits in his keynote talk at the CELF Embedded Linux Conference in 2008.  The slides from his talk are available at http://www.celinux.org/elc08_presentations/morton-elc-08.ppt. We choose to use 2.6.29 as the base for our new supported Linux kernel (at the time of writing, the latest stable kernel is 2.6.30).  We have now ported most of the support for our Snapper CL15 and Snapper 9260 Single Board Computer Modules (https://bluewatersys.com/quickstart/) into our 2.6.29 kernel, which is available for download at https://bluewatersys.com/public/linux/linux-2.6.29-snapper.tar.gz. During the upgrade from 2.6.20 to 2.6.29, we have taken the opportunity to drop a large amount of our lecagy code and to clean up other code to better conform to the Linux kernel coding standards.  The long term goal is to improve the maintainability of our kenel code and, wherever possible, push support for our platforms to the mainline kernel in order to ease the upgrade process for ourselves in the future.

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.

Traditionally, Linux-based applications have been built using GNU tools. Even today, Bluewater uses mostly GNU tools for application development, and always for the Linux kernel. For many years, Symbian used the GNU tools also. The rationale was that GNU tools are cheap and functional, and allow access to the widest possible developer base. However, this strategy broke with companies like Nokia and Ericsson. These companies were very happy with the idea of investing significant sums of money in better tools, and regarded the use of GNU as a missed opportunity. Symbian has therefore moved to a dual approach, with serious developers using RealView and casual developers using GNU. The benefits of RealView include a better compiler (faster and smaller code, more features, better documentation) and better debugging support. Microsoft has followed a different approach with Windows CE. Microsoft uses their own compiler with a number of vendor-specific extensions, and has little interest in encouraging other tools vendors. While this approach provides a highly functional, customised and integrated IDE, it forces customers to rely on the Microsoft ARM compiler, which is not exactly the best in the world. It seems that Linux is moving to the dual-tools approach used by Symbian. This will offer the best of both worlds - low cost GNU tools and highly functional RealView tools. To illustrate the potential benefits, recently we build a bayer filter algorithm with both GNU and RealView. This was for our Bigeye Camera project. The RealView-compiled code executed in about 400ms, versus 1.7 seconds for GNU, so RealView code was 4 times faster! This is an extreme case (other results show around a 10-20% benefit) but it does illustrate the potential benefits of using RealView. A few years ago ARM introduced a --gnu flag into their RealView compiler. Using this, Bluewater Systems has written an applications note for ARM on how to build application software and libraries for Linux using RealView. Today, building Linux applications using RealView requires a fair bit of fiddling, and detailed tools knowledge. But ARM is working on this, as evidenced by the better support in each release for the last several years. The goal seems to be to replace GNU entirely in the tools chain. Bluewater uses RealView tools for bringup, debugging Linux kernels and for debugging WinCE via EXDI2. Our engineers are itching to get a better development environment (particularly in debug) than that offered by GNU. We already have a foot in the water in this area. The next major step for us will be building our Snapper-targeted OpenEmbedded release using RealView. Time frames are unclear at the moment, but even with the current RealView tools we have been able to develop a script which handles translation of most common command-line arguments. The next 12 months should see a big leap forward in Linux tools support, and resulting software performance and engineer productivity. We will keep you posted on our progress. Availability of RealView tools looks like it's becoming a key benefit of using Linux.

When building embedded devices, one of the fundamental activities we do is coupling [suitable CPU A] with [selection of special-purpose peripherals B]. This gets you from having a feature-rich (but boring) SOM to a specialised device offered a wide range of sensory inputs and options. Being an embedded platform however, complexity, pin counts and space is at a premium - so instead of the more powerful IDE, PCI, PCIe or similar interfaces, words like I2C, SPI and RS232 tend to crop up a lot. In this note, I'd like to focus on I2C. I2C (Inter-Integraced Circuit,(http://en.wikipedia.org/wiki/I%C2%B2C), a.k.a. TWSI (Two-Wire Serial Interface), is a mostly-standardised interface using two control lines -- SDA (Serial Data) and SCL (Serial Clock) -- and in-band clocking. In practice, different I2C devices use very similar protocols -- with subtle differences: clocking behavior, addressing, transaction format, etc. Basically, they're all compatible, except when they're not of course. Under Linux, a wide variety of I2C  devices are supported; in addition, Bluewater regularly writes drivers as we use new I2C devices in our designs. At the time of writing, custom-supported I2C devices include:

• Chrontel CH7004 Video DAC ]
• Dallas Semiconductor DS1339 real time clock [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3470]
• Maxim/Dallas ds2782 Stand-Alone Fuel Gauge IC [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4779]
• Micron MT9T001 Image Sensor [http://download.micron.com/pdf/datasheets/imaging/MT9T001_3100_DS.pdf]
• Omnivision OV3640 3.1 mega-pixel camera [http://www.ovt.com/products/part_detail.asp?id=129]
• Analog Devices AD7414 temperature sensor [http://www.analog.com/en/temperature-sensing-and-thermal-management/digital-temperature-sensors/ad7414/products/product.html]
• Dallas Semiconductor Maxim DS4520 I/O expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4340]
• ST LIS3LV02DQ MEMS Intertial Sensor [http://www.st.com/stonline/products/literature/ds/11115.pdf]

In addition to Linux, we also use I2C devices in lightweight embedded solutions:

• Analog Devices AD5242 Dual-Channel Digital Potentiometer [http://www.analog.com/en/digital-to-analog-converters/digital-potentiometers/ad5242/products/product.html]
• Analog Devices ADG791G 4-Channel SPDT Switch [http://www.analog.com/en/switchesmultiplexers/analog-switches/adg791g/products/product.html
• Maxim/Dallas MAX7311 16-Bit I/O Port Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3727
• Maxim/Dallas MAX7313 16-Port I/O Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4101]

Of course, this list will keep expanding as additional devices are used in products.