Samsung Semiconductor announce a new model in their Exynos Cortex-A9 CPU line. The new Exynos 4212 offers a dual core processor running at 1.5GHz,  video playback/recording of 1080p video, and a direct on-chip HDMI 1.4 interface. These features, combined with the 30% power efficiency from the 32nm process over the previous process, mean that this core is well placed for the tablet and high-end smart phone markets.

Sampling is expected to be available in Q4 2011.

For further details, see here.

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.

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.