Java applications are platform independent.  This means that a Java class file can be run on either a desktop PC or an embedded ARM platform without needing to be recompiled.  This can reduce development time greatly since an application can be developed on a standard desktop PC and then re-deployed on an embedded ARM platform with little or no extra effort. The main page for embedded Java development is: http://java.sun.com/javase/embedded/. Java SE 6 is unfortunately only supported on ARM v6 or higher.  However, Java 1.4.2 is supported on our ARM v5 based Quickstart Kit. Sun are expecting to release a version of Java SE 6 with support for ARM v5 processors by the end of August. The embedded version of Java 1.4.2 is only 25MB when installed and can run on devices with as little as 32MB of memory.  The embedded Java version of Java 1.4.2 is a full J2SE implementation except that it is "headless", which means that there is no support for mice, keyboards or framebuffer devices. To download the Java 1.4.2 run-time for use on Bluewater's Quickstart Kit:

1. Go to http://java.sun.com/javase/downloads/embedded.jsp
2. Under "Java SE for Embedded 1.4.2", "ARM Linux - Headless" select "EABI, glibc 2.4, Soft Float"
3. Fill out the survey and provide an email address
4. You will be sent an email with a link to a download
5. Download the archive
6. The archive can be installed by simply unpacking it to a convenient location (for example, /local/java)

To create a simple hello world application, creae a file called Hello.Java with the following contents:

public class Hello {

public static void main(String args[]) {

System.out.println("Hello World from Java on the Quickstart Kit");

}

}

To compile this you need to have the Java SDK installed on your PC.  The file Hello.class can be built as follows:

javac Hello.java

You can then run this on either your PC, or on Bluewater's Quickstart Kit.  On the Quickstart Kit you will need to supply a classpath which includes both the Java installation directory and the path for your hello world class file.  For example, if you have the embedded ARM Java run-time installed in /local/java, and your Hello.class file in is /home/ryan/java then you can run it as follows:

java -classpath /local/java/lib:/home/ryan/java Hello

If all goes well, you should see the output of the hello world program.

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.

Embedded development boards have, in the last few years, progressed from being expensive platforms only available to professional or commercial developers, to almost-commodity devices accessible to anybody with an inclination to tinker. In the same time, the processing power available has progressed from cramped 8-bit micros to something resembling a previous-generation desktop, in a board the size of a deck of cards. As a result, there has been an emergence of hobbyist devices, ranging from the intimidating to the inane, of which we'll highlight a few here. Deeply impressive: Autonomous Trans-Atlantic Sailboats [From: http://www.roboat.at/en/technologie/] The Microtransat Challenge is a trans-Atlantic race of fully autonomous sail boats, designed to stimulate development of autonomous sailing boats. There are currently 12 teams registered for the 2009 race, with control systems ranging from commodity PC hardware to a custom FPGA-based system PCB. Resilience, intelligence, a wide range of sensor options and energy efficiency are key to success for these boats – a task to which modern embedded processors are ideally suited. Inevitable, in a way: RFID Cat Doors [From: http://ioanghip.googlepages.com/catdoor – controller laptop not shown] The key to invention is to recognise a need, and address it. In this case, the need is controlling the use of a cat door - whether to prevent other cats entry, or to control what the cat is allowed to bring in with it. In both these cases, the hacked-together prototype is a mishmash of commodity desktop computer hardware and components - a mixture that ideally lends itself to being simplified through the use of a smart embedded controller. While this may seem like an obscure product, commercial variations now exist: RFID Cat Door Pet Porte® Microchip Cat Flaps Just cool: Persistence-of-Vision LED Bike Lights [From: http://www.ladyada.net/make/spokepov/index.html] Persistence-of-vision means that rapidly-moving light sources will appear to be present for longer than they actually are, in this instance allowing a rapidly spinning line of LEDs to appear as a solid surface. Combine this with a small micro-controller, a sensor capable of determining rotational position, and you have the ability to display arbitrary images – or to turn your bicycle into a stunning mobile billboard. Again, this appears to be a fairly niche device – more of a toy than anything – but it has been commercialised by a number of companies: SpokePOV Kit MonkeyLectric Monkey Light Hokey Spokes Pimpstar Dub Custom Wheels The focal point here is that the line between hobbyist and commercial development is blurring: build something interesting, and you might find people lining up to give you money.

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.