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 (http://www.bluewatersys.com/quickstart/) into our 2.6.29 kernel, which is available for download at http://www.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.

We often get customer requests for a platform that is suitable for running Adobe Flash applications. Unfortunately none of the desktop flash players are suitable for embedded devices. Finally Adobe has become aware of the huge market for embedded flash devices and produced a version of Flash targeted specifically at ARM based devices. To use Adobe's own words "Adobe Flash Lite is a highly optimized implementation of the Flash runtime for mobile phones, consumer electronic devices". First the good news.... We have successfully run Adobe's Flash Lite on our OMAP3530 Digital Video (DV) platform. While it will not play flash movies designed for high end desktop machines only (i.e. with lots of full screen scrolling), it performed much better than we expected with very smooth playback at 720p. Absolutely perfect for digital signage and kiosk type applications. The bad news.... Flash Lite is not open source and requires a royalty payment to Adobe (approximately US$7 per unit). The second limitation is that the latest version of Flash Lite (3) supports the equivalent of Flash 8 and hence does not support Action Script 3. Hence newer flash movies, designed for Flash 9 or 10 will not run. This is usually not a problem as the main reason customers want to use Flash is because of the developers familiarity with the development tools, and it is easy enough to target Flash Lite Players during content generation. Although there are a few limitations with Flash Lite, it is a very viable option for embedded platforms. Combined with the processing power of the Cortex A8 in the OMAP3530 there is finally a good embedded solution for Flash enabled products. A market space previously dominated by clunky, power hungry x86 platforms. For more information check out the Adobe website: http://www.adobe.com/products/flashlite/

The Eclipse IDE has been used for embedded development for many years now, but it has always been a painful process to setup and use. In a couple of weeks version 3.5 of the Eclipse framework codenamed 'Galileo' will be released. At the same time the CDT team are planing to release version 6.0 of the C/C++ Development Tooling plugin. What makes this interesting to the embedded development community is that the Debugger Services Framework (DSF) has been integrated into this CDT release. The DSF provides an alternative to the Standard Debug Model API of the Eclipse platform and has been designed to help achieve better performance when debugging applications on slow or remote targets. To gauge how painless it really is is use the new version of Eclipse for embedded development we decided to give the current release candidate a try. We downloaded the "Classic" package and installed the CDT, Remote System Explorer (RSE) and Subversion source control plugins. The creation and cross-compilation of a simple "Hello World" application was straight forward. The setting up and configuration of the connection to the remote device (using SSH) was slightly more complicated, but worked well. The integrated remote file viewer, shell and GDB launcher are all very useful tools that make Eclipse that much better as an embedded device development IDE. So perhaps now Eclipse is finally ready for embedded development! We have added detailed instructions on how to setup and use Eclipse with our Snapper 9260 Quickstart Kits on the Bluewater quickstart pages.

Quad-Flat No-Lead (QFN) packages are very popular and widely used nowadays in the semiconductor industry.  Its primary advantages compared to leaded packages (SOICS, SSOPs, QFPs, etc.) are its small size and greatly enhanced thermal capability, which transforms into more power handling. Let's repeat it, more power in a small size, which fits into the present script of today's electronic gadgets and products: keep it small.  At Bluewater Systems, QFNs are always present in every moderate to complex board design.  There are a lot of advantages with this package compared to leaded packages, but it is not the advantages that cause this blog to be written.  It is something about the way they are presented in the data sheet and the way that they are typically called out for a given number of pins (e.g. QFN32 or 32-pin QFN). Normally, a device's data sheet contains the "features" list which includes the device's package in the very first page, such as, "6x6 32-leadless QFN or 4x4 16-leadless QFN".  But here's the catch, QFN doesn't always imply equal number of pads on all four sides making it square in form. It can also be rectangular, which means two sides have a lesser number of pads than the other two.  QFN16 could mean 4x4 pads on all sides (image on the left) or 2x6 pads (6 pads on the longer side and 2 on the shorter side, image on the right) and so on. In PCB design, it is always a standard procedure to check the mechanical dimensions of the package to map a correct footprint, even with conventional lead packages. Usually, a package's mechanical details are put on the last few pages in a data sheet.  Worse, some data sheets don't even provide the mechanical details of the package (though this is rare for devices in a QFN package) based on experience. It is sometimes hidden in the manufacturers website. However, in large complex boards, there may be multiple devices in QFN packages with the same number of pads but different pad configurations (square or rectangular in form) which could be prone to human error by interchanging footprints at the pre-layout stage.  So, extra car must be taken when dealing with QFNs. At Bluewater Systems, as part of its evolving quality procedures, a special footprint naming convention for QFNs has been adopted. It must include a QFNs pitch, pad configuration (number of pads in two adjacent sides) and package size. It's quite a lengthy naming than the conventional footprint naming before QFNs were popular, but it is effective in eliminating errors.

ARM's new Cortex brand name encompasses a range which splits into three parts: A, R and M. The A is the high performance application range and R is for deeply embedded, deterministic performance (internal SRAM rather than cache is the rule) but still very fast. The M is out on its own. Standing for 'microcontroller' it is ARM's foray into the $1 micro space. The initial product, Cortex-M3, has spawned devices from Luninary Micro, NXP, STM, Toshiba among others. A more recent edition, the Cortex-M1 is aimed at embedding in an FPGA. A few months ago ARM announced Cortex-M0. That number must have been chosen carefully as there is nowhere to go beyond it. A Cortex-M(-2) is unlikely to appear. Last week, NXP announced that it has working silicon, the first semiconductor partner to reach this stage. NXP expects products based around this core to ship in early 2010 about 9 months from now. ARM claims 12 uW per MHz for this core. This compares to about 250 uA per MIPS quoted by TI for their MSP430. This is the chip that everyone talks about when low power is desired. Of course, the Cortex-M0 is just a core and it remains to be seen what NXP and others will put around it in terms of power consuming peripherals. Also NXP seems to be using the 0.18um process which uses about 86 uW per MHz. But it is hard to see Cortex-M0 having anything less than a large advantage in terms of power consumption when running. It also has various sleep modes as with the MSP430. With the 0.18um process NXP can clock the chips at up to 50MHz. An internal oscillator and PLL reduce the need for high speed external crystals. The range is called LPC1100. Best of all, ARM claims software compatibility with the Cortex-M3, so a relatively seamless transition should be possible for those who want to take advantage of the low power options. In other words, ARM's engineers have apparently reduced power consumption by clever design, and throwing away features without breaking the instruction set compatibility. That said, surely no one programs the Cortex-M3 in assembler as one of its selling points is that you never need to.

The Cortex-M3 has been quite successful in its market, and ARM no doubt sees a market even below that. Quoted applications include lighting, gaming controllers, and Zigbee. Some might baulk at putting a 32-bit micro in a light switch, but if the cost is right, why not? ARM is trying to help by describing it more in 16-bit terms than 32-bit. Apparently putting a 16-bit micro in a light switch is OK these days.

to be continued