Qt Creator for C/C++ development

Recently, I’ve been evaluating Qt Creator for general C/C++ development.  I’m currently involved in the development of a rather large C++ application that is approaching 200,000 lines of code and 1000 source modules.  In the past, I’ve typically used Vim for editing, and Eclipse as a gdb front-end when needed.  Qt Creator is a rather new tool developed by Nokia’s Qt team.  What initially attracted my attention was that one of the reasons the project was started was no existing tools effectively handled the Qt codebase, which is quite large.  Things I like about Qt Creator:

  • it works fairly well with any C++ Make based project.  This includes projects built with autotools as well as the Qt Qmake build system.
  • easy to import existing projects
  • it is very fast.  Indexing 200,000 lines of code happens in around a minute or so.
  • Provides a Vim compatibility mode that actually works
  • provides fast methods for finding files, symbols, and seeing where symbols are used
  • did I mention yet it is fast?

I also recorded a screencast that demos Qt Creator with a large project (can be viewed in firefox).  As always, I’m interested in what others find interesting in this or other tools.  Future efforts will be to use Qt Creator to build and remotely debug ARM binaries — I am interested in what others have done in this regard.

If you do try Qt Creator, I recommend the latest pre-release snapshot.


Gumstix Overo review

Based on the interest and number of embedded modules currently available, it appears that the OMAP3 CPU from TI will be very popular in the general purpose embedded Linux market.  One of the OMAP3 modules available is the Overo from Gumstix.  As the company name suggests, this module looks about like a stick of gum, but smaller, as shown in the photo below.  The Gumstix module provides a lot of functionality in a very small package.  It is reasonably priced, and is an excellent way to quickly create a product that has advanced functionality such as a high powered CPU (OMAP3), high speed USB, DSP, 3-D graphics acceleration, etc.  For an example of the OMAP3 performance compared to previous generations of ARM processors, see this article.

Overo size comparison to a US dime
Overo size comparison to a US dime

The module contains all the core components, and can then be attached to a custom baseboard using the two high density connectors shown in the above photo.  There are 70 signals on each of the two connectors.  BEC provides a spreadsheet of the Overo signals to assist in designing a custom baseboard.

Due to the high level of component integration, the Overo has very few components on the module.  As shown in the below photo, there are really only 3 major visible components.  The flash and RAM is stacked on top of the CPU.  The PMIC contains all the required power managment circuitry, as well as Audio and USB interfacing functionality.

Major components on the Gumstix Overo
Major components on the Gumstix Overo

The Overo module must be used with a baseboard.  Gumstix provides several development baseboards.  For production, a custom baseboard is typically created.  The Gumstix baseboards are reasonable cost, so they could be used for prototyping or low volume production if they have the required functionality.  Below is a photo of the Summit baseboard that provides DVI video out, audio, USB host and OTG, and an expansion connector with a number of signals.

Gumstix Summit baseboard (overo is not installed)
Gumstix Summit baseboard (overo is not installed)

Below is the Palo baseboard from Gumstix that can be used to interface with a LCD display.  The Palo board contains a resistive touch screen controller, and circuitry required to interface with a LCD.

Palo baseboard with Overo installed
Palo baseboard with Overo installed
Display connected to Palo baseboard.  Note the tape applied to the display to keep from shorting to components on baseboard.
Display connected to Palo baseboard. Note the tape applied to the display to keep from shorting to components on baseboard.

The Overo does not include an Ethernet controller, so you typically use a USB-Ethernet adapter for development.  Below shows a typical development setup.

Typical USB-Ethernet connection through a USB hub.
Typical USB-Ethernet connection through a USB hub.

One of the things about the OMAP3 that makes it very attractive for embedded development is the amount of software support, and the number of development and production solutions available.  The OMAP3 is very well supported by the OpenEmbedded project, and TI is very active in making contributions to various open source projects.  This greatly increases the quality and availability of advanced software functionality needed to support a complex system like the OMAP3.

Size comparison of several OMAP3 systems
Size comparison of several OMAP3 systems
WIFI and BT antennas connected to Overo module
WIFI and BT antennas connected to Overo module

There are many options for software development with the OMAP3 systems.  Below is a photo of a very simple Qt application.  GTK+ and Enlightenment are other popular GUI toolkits.  With 256MB of both flash and RAM, this is more than enough memory for most embedded applications, and provides plenty of headroom for adding features for future product revisions.  The Overo has the CPU processing capability to run advanced GUI applications with 3-D affects, as well as advanced web application frameworks like web2py that previous generations of ARM CPUs could not effectively run.

A simple Qt application that controls LEDs and reads user switch
A simple Qt application that controls LEDs and reads user switch

The Gumstix Overo provides an excellent value for developing advanced products.  Especially for low volume products, when you compare the effort and time required to develop a full custom OMAP3 solution versus a simple Overo baseboard, using a module can provide significant advantages in terms of time to market, and development cost.


Wi2Wi W2CBW003 Wifi/Bluetooth module review

The Wi2Wi W2CBW003 is a highly integrated module that provides both Wifi and Bluetooth radios for embedded designs. This module is ideal for embedded designs, as it provides a lot of functionality in a small package and includes standard interfaces like SPI, SDIO and serial that connect with most embedded CPUs. With the availability of modules like the W2CBW003 and standard drivers in the Linux kernel, including radio functionality in an embedded device is very doable, even for low volume products. Wi2Wi provides an evaluation board for the W2CBW003 with a SDIO connector, UART connector, and BT Audio Connectors. For this review, the eval board was connected to a Marvel PXA270 ARM processor, and evaluated with current Linux and associated software.

W2CBW003 Overview

The W2CBW003 module integrates both WiFi and Bluetooth functionality in a 12mm x 12mm x 1.6mm package. The WiFi portion is based on the Marvell 88W8686, and the Bluetooth on the CSR BC04. Both of these components are well supported by Open Source software. Some other features include:

  • Separate Antennas for WiFi and BT.
  • ROHS compliant
  • Single Supply at 3.3V
  • 802.11g support (54Mbps)
  • Both SPI and SDIO interfaces for WiFi
  • UART interface for BT
  • PCM audio interface for BT

Pictures of the module and the demo board are shown below.



Evaluation System Configuration

The test software included with the Wi2Wi eval board is for a Windows PC, is provided in binary format only, and was not used in this review. For this review, I plugged the W2CBW003 demo board into a Compulab cm-x270 board (PXA270 cpu) running a 2.6.29-rc7 Linux kernel and a recent OpenEmbedded Angstrom distribution. With the exception of the Marvell Wifi Firmware, all software in this setup is Open Source and is available in the Linux kernel, and as packages in the OpenEmbedded Project.

When booting the kernel, you will see the following messages:

mmc0: new SDIO card at address 0001
libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
libertas: 00:19:88:06:0b:2e, fw 9.70.3p25, cap 0x00000303
eth2 (libertas_sdio): not using net_device_ops yet
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: eth2: Marvell WLAN 802.11 adapter

The “command 0x00a3 failed” messages are harmless, and have to do with features that are not supported. After the system boots, you will now see a new ethX network device:

root@cm-x270:~# ifconfig -a
eth2      Link encap:Ethernet  HWaddr 00:19:88:06:0B:2E
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:65902 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1758 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13550002 (12.9 MiB)  TX bytes:251627 (245.7 KiB)

The “iwlist eth2 scanning” command will list available access points.

Connecting to Open WiFi Networks

A connection to an open wifi network can be accomplished by placing the following in /etc/network/interfaces:

iface eth1 inet dhcp
    wireless_mode managed
    wireless_essid any

And now execute “ifup eth2”:

root@cm-x270:~# ifup eth2
udhcpc (v1.13.2) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending select for
Lease of obtained, lease time 86400
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns
adding dns

root@cm-x270:~# iwlist eth2
iwlist: unknown command `eth2' (check 'iwlist --help').
root@cm-x270:~# iwconfig eth2
eth2      IEEE 802.11b/g  ESSID:"bec3"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:18:39:C1:AD:4A
          Bit Rate:1 Mb/s   Tx-Power=13 dBm
          Retry short limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Power Management:off
          Link Quality=84/100  Signal level=-37 dBm  Noise level=-87 dBm
          Rx invalid nwid:0  Rx invalid crypt:14707457  Rx invalid frag:0
          Tx excessive retries:58  Invalid misc:3   Missed beacon:0

WPA Secured WiFi Networks

The OpenEmbedded console image includes the WPA Supplicant packages which is used to manage wireless connections to secured networks. To set up the system for WPA encryption, modify the following files:

iface eth2 inet dhcp
   wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
   wpa-driver wext

      pairwise=CCMP TKIP
      group=CCMP TKIP
      psk="ascii passphrase"

Then, execute “ifup eth2”, and you should see something like:

root@cm-x270:~# ifup eth2
WPA: Configuring Interface
udhcpc (v1.13.2) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending select for
Lease of obtained, lease time 86400
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns
adding dns
root@cm-x270:~# iwconfig eth2
eth2      IEEE 802.11b/g  ESSID:"bec"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:40:10:10:00:03
          Bit Rate:1 Mb/s   Tx-Power=13 dBm
          Retry short limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:<too big>   Security mode:open
          Power Management:off
          Link Quality=64/100  Signal level=-68 dBm  Noise level=-89 dBm
          Rx invalid nwid:0  Rx invalid crypt:-1463809279  Rx invalid frag:0
          Tx excessive retries:22524  Invalid misc:3   Missed beacon:0

Other Observations

With the above networks, the bec access point was much further away than the bec3 AP, so you will notice the difference in link quality. “iwlist eth2 rate” can be used to list the current connection rate. When the network is idle, it sits at 1Mb/s. When downloading a large file, it will climb to 36 or 54Mb/s, depending on link quality.

Production Issues

The review demonstrates that it is fairly simple to set up a demo quality Embedded Linux system with WiFi. Some of the issues that would likely need addressed for a production system include link management, test software for certification, and power management.

There are several ways to programatically control WPA Supplicant including linking to the wpa supplicant control interface, or using DBus. There are several WiFi management applications available including Gnome NetworkManager (used in desktop systems), and connman which seems a little better suited for embedded systems.

Unless you use a completely pre-certified module + antenna solution, you will likely need to do some level of agency certification. As many products use a custom antenna, this is an important issue to consider and plan for. While Marvell provides test software and firmware, it will likely require some work, as their software is designed to be used with their in-house drivers rather than the libertas driver which is available with modern kernels.

Also, if you want to minimize the power usage, some work will be required to figure out the power modes supported, and how to implement/control them. With this module, the Wifi and BT portions run off the same crystal, so if you only want the BT active, you will need to actively power manage the Wifi portion to a low power state instead of completely disabling it.


TheW2CBW003 module is an attractive solution for products that need WiFi functionality. With the availability of modules like this, and mainstream open source software, the technology is available to about anyone, including low volume manufacturers. Standard interfaces such as SDIO make it possible to interface this module with about any modern ARM processor that can run Linux. Software support in the Linux kernel, wpa supplicant, and the Linux wireless tools provide the needed software support to implement a very complex system with relatively little effort.


Sprint 598U USB Broadband Modem in Embedded Systems

One thing that works really well in Linux is support for USB Broadband modems. While it usually takes a little fiddling with PPP scripts, it is generally not too difficult to get working. One of the reasons for this is most modems implement a USB serial interface, and then the modem is controlled with standard AT commands. A customer who currently supports a Verizon USB modem in their product wanted to add support for a Sprint modem. After a little research, we settled on the 598U from Sierra Wireless. Below is a picture of the 598U plugged into an industrial terminal.

sprint 598U modem

Why are USB Broadband modems useful in Embedded Systems?

As systems become more complex, and time to market is shrinking (thus less testing), it is becoming increasingly important to be able to remotely diagnose problems. With a broadband modem like the Sprint 598U, developers can remotely log into a device using SSH, and debug problems. This is a huge benefit. The cost of the modem and a 1 year data plan becomes fairly insignificant when you consider the cost to fly a developer on-site to debug issues. While there are other ways to remotely access an embedded system, such as reverse ssh, the simplicity of the broadband modem is attractive as it bypasses the firewall issues. Even with reverse ssh, I’ve run into paranoid sys admins who block the outgoing port 22 on their networks, which makes reverse ssh difficult. Once you have the IP address of the broadband connection, you can connect to it directly with ssh from anywhere in the world. I’ve accessed systems that were being field tested in New Zealand from the United States, and it worked great.

Increasingly, the value of complex embedded systems is shifting from control to data. While the control aspect is as important as it ever was, access to data is what is giving many products and businesses the competitive edge. Being able to collect data and visualize how the system is performing is becoming increasingly important to maximize performance. And sometimes this data must be collected in real-time. Scenarios where USB broadband modems might make sense:

  • remote sites that do not have internet connectivity
  • mobile applications such as vehicle terminals
  • temporary installations where the system is only located in one place for a limited time
  • situations where it is very difficult to get administrators of the local network to cooperate in adding the embedded system to their network

Finding PPP Config information

I usually develop as much as I can on x86 systems (vs. an embedded target) as it is a lot more convenient, so I plugged the modem into a Ubuntu 8.10 laptop. While Ubuntu 8.10 recognizes and configures a UM150 Verizon modem, it does not automatically configure the 598U. Typically, the next step is to google around for information on various support forums on how to set up the PPP config files, as most manufactures don’t provide support for Linux. As I could not find any existing information for the 598U, I decided to see if Sierra Wireless published any information. Was I ever suprised when I found this page. Sierra Wireless provides fairly comprehensive information on using the modem under Linux, and their PPP scripts actually worked — great job! But in the end, when I plugged the 598U into the embedded device that already supported the Verizon modem, it just worked with my existing PPP scripts. This is another indication of the value of using common code and interfaces in Linux.

The Linux Advantage

When you run Linux in an embedded system, using a USB broadband modem becomes fairly simple. It is actually a little bit deceiving as to what all has to happen. Different modems use different chipsets, and thus different drivers. While they all eventually expose a USB serial interface, there are enough differences to require separate drivers. As an example, the 598U uses the “sierra” USB-serial driver. This driver is 782 lines, plus it utilizes a common USB serial framework that is many times this size. On the application side, the pppd framework is used to manage the modem and the network connection. Starting the connection is as simple as running “pppd call cdma” from your application. The pppd application manages getting an IP address, setting up nameservers in resolve.conf, etc. Because all broadband modems are supported by a common application interface and very similiar drivers, supporting multiple modem vendors is actually quite easy. Contrast this to the Windows driver scenario where every vendor provides their “own” driver, and their “own” application user interface, and their “own” way to initiate an internet connection, and it is not obvious to me how you could easily control all this in a consistent, automated fashion in an embedded device. The way we set it up is you plug the modem in, and a few seconds later the system is automatically connected to the internet. There is nothing for the user to configure, initiate, etc. Printing from Linux in embedded applications is similiar.

This is another example of how it is possible to leverage the work of many to add advanced functionality and features to a device with very little development cost. Getting more done with less should be an attractive (and perhaps critical) way to operate for any company seeking to remain competitive.


Using a Verizon USB720 modem in an Embedded Linux system

The Verizon USB720 Cellular modem is a quick and easy way to add wireless internet connectivity to your embedded system.  Why might you want to add cellular  connectivity to your embedded device?  Remote access and diagnostics is a big reason.  One customer I have is planning to supply all their distributors with a USB720 so they can easily upload log files from devices in the field.  The alternative is copying the log files to a flash drive, finding a PC connected to the internet, and then uploading the files — too much hassle, therefore it does not get done.  Also, think about the cost of sending a field support person on-site to troubleshoot problems versus shipping them a USB720 and accessing the device remotely.

The USB720 is a fairly small device that plugs into the ubiquitous USB port.  This articles covers some of the details on how to configure an embedded Linux system to work with this device.

Why is the USB720 a good fit for wireless connectivity in Embedded Systems?

Some reasons the USB720 (or other USB based cellular modems) is an attractive option:

  • fairly fast: provides typical download speeds of 600-1400kbps, and upload speeds of 500-800kbps
  • convenience: it plugs into a USB port.  No taking apart the box and installing an embedded module, etc.
  • affordable: with plans around $60/mo, its a lot cheaper than sending field support people on-site to debug every problem.
  • uses standard PPP protocols for connection.  That means it works with Linux.
  • supported by the mainstream Linux kernel


Kernel Configuration

The USB720 looks like a USB-serial device to the host system.  If you plug it into your Ubuntu desktop Linux system, all the needed kernel pieces are there and it will just work.  With your embedded system, you need to make sure a number of kernel options are enabled including:


The CONFIG_USB_SERIAL_OPTION selection enables a driver that is specifically optimized to work with the USB chip found in many cellular modems.  Once you enable the above modules, and if you are running udev, simply plugging in the device will cause the appropriate modules to load and a /dev/ttyUSB0 device will now appear.

PPP Scripts

The most difficult part of this exercise is figuring out how to configure the PPP scripts.  Verizon of course does not tell you how to configure their device and only supplies software for Windows and MAC.  There are a number of howtos available on the internet, but most of them are tailored to using kppp or wvdial. Neither are very practical for embedded systems. Fortunately, the standard pppd daemon is fairly easy to use, is easy to build for embedded systems (it is already included in OpenEmbedded), and seems to work very well.  The following scripts are needed:


connect "/usr/sbin/chat -v -f /etc/ppp/peers/verizon_chat"


'' 'ATZ'
'OK' 'ATDT#777'


"<phone number>"  *       "vzw"

At this point, you can run pppd call verizon and you should see something like:

 root@cm-x270:~$ pppd call verizon
Serial connection established.
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
Warning - secret file /etc/ppp/pap-secrets has world and/or group access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x539657b7> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1500> <asyncmap 0x0> <magic 0xb9b652e5> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <mru 1500> <asyncmap 0x0> <magic 0xb9b652e5> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x539657b7> <pcomp> <accomp>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr> <ms-dns1> <ms-dns3>]
rcvd [LCP DiscReq id=0x1 magic=0xb9b652e5]
rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
rcvd [IPCP ConfReq id=0x0 <addr>]
sent [IPCP ConfAck id=0x0 <addr>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr> <ms-dns1> <ms-dns3>]
rcvd [IPCP ConfNak id=0x2 <addr> <ms-dns1> <ms-dns3>]
sent [IPCP ConfReq id=0x3 <addr> <ms-dns1> <ms-dns3>]
rcvd [IPCP ConfAck id=0x3 <addr> <ms-dns1> <ms-dns3>]
not replacing default route to eth0 []
local  IP address
remote IP address
primary   DNS address
secondary DNS address
Script /etc/ppp/ip-up started (pid 2303)
Script /etc/ppp/ip-up finished (pid 2303), status = 0x0
root@cm-x270:~$ ifconfig
ppp0      Link encap:Point-to-Point Protocol
          inet addr:  P-t-P:  Mask:
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:64 (64.0 B)  TX bytes:94 (94.0 B)

You are connected 🙂

Using the OE ppp package

Add ppp support to your image using OE is fairly straightfoward:

  • add the kernel modules to your image
  • add ppp to your image
  • add a custom package that includes the configuration scripts listed above

One thing that may trip you up is the ppp scripts are expecting resolv.conf to be in the following location: /var/run/resolv.conf.  The reason for this is we want resolv.conf in a RAM file system to prevent unneeded flash wear.  Therefore, /etc/resolv.conf should be configured in your rootfs as a soft link to /var/run/resolv.conf.


The Linux kernel support for USB720 and the pppd package offer a quick, robust way to add cellular network connectivity to about any embedded Linux system that has a USB host port.  As systems become more complex, it will be increasingly important to be able to remotely access systems in the field to troubleshoot problems, help users with configuration, etc.  The USB720 offers a quick way to provide this type of connection without going through the expense of designing cellular connectivity into your product.  One thing I usually encourage all my customers to do when designing new products is expose a USB host port, even though they may not see any immediate use for it.  This is one of those reasons.

Below is a picture of a USB720 connected to a Compulab cm-x270 development system.



Atmel AT32AP7000 development board review

I recently purchased an Atmel NGW100 development board which includes an Atmel AT32AP7000 CPU.  This CPU is based on the new Atmel AVR32 architecture, and is capable of running full Linux.  This review covers the basics of this development board, the AVR32 architecture, options for building Linux for this system, as well as opinions on how a new architecture can succeed in a field of well established architectures like ARM and MIPS.

What is AVR32?

The AVR32 architecture defined by Atmel is a 32-bit RISC load/store architecture. There are several different versions of the core.  Atmel currently supplies two classes of AVR32 cpus:

  • UC3 Flash MCUs – low end devices with integrated RAM and flash, no MMU, and look similar in capability to ARM7 microcontroller type devices.
  • AP7 Application Processors – faster devices, include MMU, seem similar in capability and speed to ARM9 application processors such as Atmel’s AT92SAM devices.

As I am most interested in CPUs that can run Linux, this review will focus on the AP7 (AVR32 AP) class devices.

It seems that AVR32 is Atmel’s answer to ARM Cortex.  Some features of the AP7 devices:

  • good code density
  • DSP instructions that execute in a single cycle
  • Full MMU
  • Instruction and Data caches
  • SIMD extensions
  • dynamic branch prediction

The MMU in the AP7 devices is interesting in that page tables are handled in software similar to a MIPS device.  In a ARM CPU, the page tables are located in physical RAM and are strictly defined by the ARM architecture and page faults are handled in hardware.  With MIPS (at least some devices) and AVR32, the MMU basically consists of a TLB (Translation Lookaside Buffer) that maps virtual addresses to physical address.  As the TLB is limited in size, any misses are handled in software.

NGW100 Development board

The NGW100 development board is available from a number of distributors (including Digikey) for about $70.  The board includes the following major components:

  • Atmel AT32AP7000 CPU
  • 32MB of SDRAM (MT48LC16M16A2)
  • 8MB Parallel NOR Flash (AT49BV642D-70TU)
  • 8MB Serial NOR Flash (AT45DB642D)
  • 2 Ethernet ports
  • SD/MMC slot
  • RS232 port
  • USB Client port
  • Microcontroller for board control (ATtiny24-20SSU)


Linux Support

Atmel is directly supporting the development effort for the AP7 processors.  They seem to be doing it right in that they are pushing support directly into the mainstream kernel.  Currently, Atmel provide patches for GCC and uClibc.  There is already efforts underway to provide AVR32 support in Openembedded, which will enable developers to quickly build full featured Linux distributions for AVR32 based products.


It will be interesting to see how the AVR32 based products work out.  On one hand, one could argue that a custom architecture like AVR32 can’t succeed as it does not have an extensive ecosystem of tool vendors in place like ARM and MIPS.  But, the availability of open source software such as GCC and Linux is rapidly lowering the barrier to entry for creating tools for new architectures.  No longer do you need to wait for commercial tool vendors to provide software support.  The model for software development is changing.

In comparison to Atmel’s AT91SAM parts, its difficult initially to see what the AVR32 parts offer over the SAM parts.  For one, they are lacking a USB Host port which is becoming increasingly important to have in embedded Linux systems.   Perhaps they offer other advantages such as lower cost and power.  As we gain experience with these parts, I’m sure we’ll find applications where they are an excellent fit.


Moxa UC7408 Review

I am currently evaluating a Moxa UC7408 for one of my customers.  The UC7408 is a small fanless industrial computer that runs Linux or Windows CE.  This article provides a basic overview of this unit and a review of some of the UC7408 features and the Linux distribution Moxa provides.


The basic specifications for the UC7408 are:

  • relatively small size and fanless
  • Intel Xscale IXP-422 266MHz Processor
  • 8 RS232/422/485 serial ports
  • 8 digital Input and 8 digital output ports
  • dual 10/100 Ethernet
  • PCMCIA, CompactFlash, Wireless LAN Expansion (supports 802.11b/802.11g)
  • Runs Linux or WinCE
  • Console serial port


The documentation Moxa provides is adequate and fairly detailed.  The moxa documents include a quick install guide, hardware user’s manual, and a 114 page user’s manual.  As good as this documentation is, a general knowledge of Linux is always helpful when working with embedded Linux systems.  Basics like using SSH, FTP, Telnet, and basic Linux system administration are essential when working with embedded Linux.

Linux Distribution

The Linux Distribution provided by Moxa is fairly full featured.  A few highlights with the v1.8 Linux firmware:

  • Provides a 26MB user JFFS2 flash partition.  This partition is read/write and is about 45% full leaving about 14.5MB for user files.  It is probably also possible to delete some of the files that are not required, freeing up more space.
  • Apache & PHP support
  • SSH
  • a number of other utilities are provided such as telnet, ftp, iptables, etc.
  • VI editor
  • Many command line utilities found in most Linux systems.
  • 2.4.18 Kernel

The Linux distribution seems to be based on MontaVista Linux and seems fairly solid.  I ran through some of the basics like mounting a CF card and everything seems to work.

Firmware Updates and Recovery Mode

Moxa provides a mechanism to update the firmware in the system.  This update is a global flash update that programs the entire flash and will erase all user changes.  The update works by enabling a RAM file system and copying the new flash image to the ram file system.  Running an update command that copies the firmware update file into flash.

The 7408 contains a stripped down version of Linux in a separate flash partition that can be booted in a recovery mode if the User flash partition becomes corrupted or unusable.  This mode can be enabled by pressing the “Reset to Default” button on the unit and powering it on.  In this mode, there is no ssh support and you must ftp an image from an ftp server to the device and then reflash it.  This requires you to set up an ftp server that the Moxa system can access.  While this is an entirely workable solution, it may be a challenge for inexperienced Linux users.


Moxa provides a Linux and Windows toolchain to use with the device.  I have built a number of packages with the Linux toolchain and it seems to work well.  It is based on GCC 3.3.2.  Cross compiling applications for embedded Linux is always a challenge and in a future article I will present a way to use OpenEmbedded to compile a number of packages using the Moxa toolchain.

Possible Improvements

There would be some benefits if the system was a little more open in the following areas:

  • access to the bootloader console and documentation.  This would allow developers to more easily flash their own software.
  • readily provide source for GPL components.  Moxa provides a form that you can fill out to receive GPL source code on a CE.  The cost is $100.

One of the big advantages of using Linux in an embedded system is the ability to use the many open source components available.  The easier an embedded solution provider makes this for developers, the more value their system provides.  See the white paper Tips for Planning Your Embedded Linux Project ( for more ideas on this subject.


Overall, the Moxa system seems very usable and the hardware is quite nice.  Stay tuned for future articles about how to get the most out of this system.





Glomation GESBC-9302E Review

Recently, I’ve had the opportunity to work with a Glomation GESBC-9302E single board computer.  This SBC contains a Cirrus Logic EP9302 ARM processor and options for plenty of RAM and Flash memory which means you have many options for writing your applications including high level languages like C# and Python.  In this review, I’ll cover some of basic features of this board and where this board might be useful.

Why the GESBC-9302?

One of the most attractive features of the GESBC-9302E is cost.  The base model with 32MB of RAM, and no NAND flash costs $95 at quantities of 1 unit.  For a model with 64MB of RAM, and 128MB of flash, the cost is $120.  Looking at the board, its simplicity is very evident.  There is basically a CPU, flash, ram, a few linear power supplies, and a very limited amount of support circuitry.  There really is not much to it.


We are helping a customer use the GESBC-9302E in a project where it is functioning as a gateway between a local Zigbee wireless network, and a server located on the internet.  The customer had originally considered using a Linksys NSLU2 for the gateway device during the alpha testing, but upon consideration it seemed like the GESBC-9302E is a better choice in this application for the following reasons:

  • the GESBC does not cost a lot more than a NSLU2
  • you can buy the GESBC with plenty of NAND flash.
  • the GESBC provides two serial ports
  • the GESBC provides many signals on headers than can be used with cables or a daughter card.

Having raw NAND flash on the board is a significant advantage in my opinion.  I’ve run into considerable hassles with consumer grade flash devices in the past (SD, USB Flash, etc).  Although there are industrial grade flash devices, they tend to be more expensive.  My preference at this point for reliable storage in an embedded Linux system is JFFS2 on a 64-128MB raw NAND flash device.  With 128MB of NAND flash, there is plenty of space for a full featured Linux distribution.

With 2 USB ports, plenty of general pupose I/O pins (GPIO), and lots of memory, there is not a lot you can’t do with the GESBC in your typical headless control or gateway type application.  Being able to interface to a number of USB peripherals, and support for high level languages makes this SBC+Linux ideal for implementing a device that may need to talk web services or other complex network protocols.

Software Support

Most of the GESBC functionality is fairly well supported in the mainstream Linux kernel.  Simply configure the kernel for the EDB9302 machine and most things will just work.  There are several pieces missing from the mainstream kernel for the GESBC that are useful: NAND flash support, and a change needed to make the Ethernet work.  For the NAND flash, I extracted a MTD driver from the Glomation kernel source code.  The Ethernet change is a small tweak to the platform files.  These changes are available for the 2.6.24 kernel in a public git repository at:

The GESBC uses Redboot for the bootloader.  No complaints with the bootloader so far — it does everything I need including loading images from a TFTP server.  The bootloader does not support writing images to NAND flash, so to load an OS image into NAND flash you typically have to boot a Linux OS from NOR flash, USB flash, or NFS root, and then use the userspace mtdutils to write an image into NAND flash.

Glomation provides a sample Linux image, but I prefer to use images generated by OpenEmbedded so that I have support for things like C# , Python, and thousands of other packages.  Support for the GESBC has been added to OpenEmbedded and I’m in the process of updating the kernel support to 2.6.24.


Overall I’m very pleased with this SBC.  Glomation has been very responsive to requests and has been a good company to work with. I still need to apply a fix for a known soft reboot issue with the 2.6 kernel and enable a driver for the RTC on the SBC.    Future articles will detail how to load Linux images built with OpenEmbedded on this device.


Compulab EM-X270 Review

The EM-X270 is a full featured computer board from Compulab ( designed for handheld/mobile applications.  The board includes options for about anything you might need in a portable system including a PXA270 processor, GSM radio, GPS, Wifi, Bluetooth, Audio, SD/MMC, USB, battery circuitry, and the list goes on.  The EM-X270 is designed to give you a big head start in designing a handheld computing device, and can significantly reduce time to market and design costs.  This article provides a high level overview of this product, how it might be used, and lots of photos.

EM-X270 Overview

The EM-X270 is a computer board about the size of a display you might find in a typical PDA.  While the size is probably a little large to be used in consumer devices like phones and PDAs, it seems like a nice size for slightly larger products used in vertical industries.


As already mentioned, the EM-X270 includes about all the base features you might need in a mobile computing device.  An expansion connector is also included that allows you to easily add custom circuitry to the system.  The stack-up between the EM-X270 and an expansion board is shown below:


The EM-X270 differers from most other embedded computer modules in that it is a little more application specified, and quite a bit more circuitry is included in the design such as power supplies, battery charging circuitry, radios, etc.

Why EM-X270?

Why are we interested in the EM-X270?  If all you need is a generic handheld computer, there are plenty of options from PDAs to off-the-shelf industrial handhelds.  However, if you need a handheld that provides some additional features not typically found in existing devices, then you can use the EM-X270 plus a custom baseboard and packaging to add your high value features.  Depending what you need to add, the expansion board can be a simple 4 layer board which is very easy to design and manufacture.  All of the complex PCB design and assembly is already done for you on the EM-X270 module.  This allows low to moderate volume manufactures design products where they would not otherwise have the time and budget for designing a full custom processor board.   Some example applications might be handheld products for the medical, industrial, and test and measurement industry.

Compulab’s pricing model is also very interesting.  Compulab will custom build EM-X270 modules with just the options you need.  The base price without any extra features (such as radios) is $122 for 1000 pieces.

The EB-X270 Evaluation Kit

Compulab provides a EB-X270 Evaluation kit for getting started with EM-X270 development.  Like their other Evaluation klits, is is very full featured and very well done.   An extender board is provided that adds Ethernet, JTAG, and several other useful connectors for development.


The eval kit also includes all necessary cables, a display, battery, etc.


Software for the EM-X270

Compulab provides software support for both Windows CE and Linux.  This includes very up-to-date support for kernel version 2.6.23.  EM-X270 machine support has also been included in the OpenEmbedded project for building full featured Linux images.  This combination will drastically reduce development costs compared to solutions provided by many other vendors.  All too often, single board computer vendors provide an ancient kernel, a hacked up root file system and call it a “Linux BSP”.  Actually, any time the term “Linux BSP” is used, you should probably be a bit wary.  A much more attractive solution for those of us building products using Linux is for processor and module vendors to say “our products are supported in the mainstream kernel and OpenEmbedded sources”.  Compulab is doing it right.

OpenEmbedded provides many interesting options for devices like the EM-X270.  One of the most interesting might be the ability to run the OpenMoko software on industrial devices.

Compulab provides a Linux demo image built with OpenEmbedded that runs the GPE Palmtop Environment.  The method for loading this image is interesting, and similar to the method I have been using for some time with systems based on the cm-x270 module ( in that it used mtd-utils from a running Linux system to erase and write to the NAND flash.  The bootloader in the EM-X270 is able to boot a kernel and rootfs directly from a USB Flash disk.  This “LiveDisk” image, as Compulab calls it, contains a small utility that programs an image from the USB flash disk directly into NAND flash.

As with any modern Linux based embedded system, there is a lot going on in a very small package.  Managing this complexity effectively requires some amount of experience.  Stay tuned for future articles that discuss using OpenEmbedded to build software for the EM-X270.

Additional Photos





Compulab cm-x270 PXA270 module review

We are in the process of supporting a customer who is designing a product that uses the Compulab cm-x270 “Computer-on-module”.  The cm-x270 is a small computer module 66x44x7mm that contains an Intel PXA270 ARM processor similar to those found in many PDAs or smart phones.  This review provides an overview of the cm-x270, why it was selected, and how we are using it.

Project Needs

For this project, we needed a low cost embedded computer that could drive a VGA (640×480) color display.  The graphical user interface for the device was fairly advanced, so we were also looking at a system that could run a modern OS with an advanced graphical toolkit.  After discussing the display requirements with the customer, we concluded that we needed a 32-bit processor with a LCD display controller.  As there was some custom circuitry needed, a configuration where the customer could design a custom baseboard and use an off-the-shelf computer module seemed optimal.  The schedule was also very aggressive and we did not have the time or budget to develop a full custom processor board.


After researching a number of computer modules, we chose the cm-x270 from Compulab.  The cm-x270 is a module that includes the following components:

  • Intel PXA270 ARM processor (up to 520Mhz)
  • 802.11b Interface
  • up to 128MB SDRAM
  • 128-512MB NAND flash
  • up to 4MB NOR flash
  • PCI
  • Serial Ports
  • Touch panel controller (UCB1400)
  • Host and Slave USB
  • and other features …

For more details visit the compulab web site (http:// ).  The cm-x270 provides a very impressive number of features in a very small space.

Below is a picture of the cm-x270 mounted on the Compulab SBC-X270 baseboard with a VGA display.  The system is running the GPE Palmtop Environment built with OpenEmbedded.


Low Cost

Perhaps the most impressive feature of the cm-x270 is the cost.  When ordering in volume, Compulab will build the module with only the components you need.  For prototyping, you can order a standard offering with all components populated.  Starting a price of $50, it is the lowest cost module we found.  The configuration we will be using costs around $98 in 2K quantities (64MB DRAM, 4MB NOR Flash, 512MHz + 128MB NAND Flash + Audio/Touchscreen + RTC).  Eventually, we may be able to reduce some of the features and get the price down around $70 per module.

At this price, the cm-x270 provides a very cost effective way to develop a low volume product (a few thousand per year) with advanced features provided by the PXA270 processor.


The bootloader and hardware design of the cm-x270 is proprietary.  Compulab does not supply schematics for the design or source code to the bootloader.  The documentation provided is adequate and provided all the information we needed to complete the design.  Compulab also provides schematics for their development baseboard, which is helpful.


The cm-x270 bootloader provides typical features found in an embedded processor bootloader, including: a serial console, NAND and NOR flash programming, download images from a tftp server, downloading images over a USB connection to a PC, and a number of other configuration commands.  The tftp download works very well and is fast.  The USB download is much slower, but is convenient for systems that do not have a network connection.  The USB download requires a windows PC with a specific version of Microsoft ActiveSync installed, which is unfortunate.  A more general solution that uses something like libusb ( instead of ActiveSync would be preferred as it could then run on both Windows and Linux computers.

Linux Support

Compulab provides a fairly complete port of the 2.6.16 Linux kernel for the cm-x270 in the form of a kernel patch.  Most of the peripherals we tested seem to work with the following exceptions:

  • The SD card driver is not preempt safe.  In this application, we need kernel preemption turned on to meet certain real-time requirements.
  • The Touch driver contains a small bug that does not allow applications using it to exit properly

Overall, support is pretty good and enabled us to get started with development quickly.

NAND Flash Driver

As the Compulab module only provides 4MB of NOR flash, using the NAND flash is a requirement when implementing a full featured Linux system with an advanced graphical user interface.  Compulab provides a binary module that is linked into a kernel driver to support the NAND flash.  This driver provides a block interface on which standard filesystems like ext2 can be used.  The NAND driver has worked fairly well, although we have seen several cases where we get I/O errors if we remove power to the device without shutting down the system properly.  The way to recover is to do a low level format the NAND flash.  This should not be an issue with this product as we will have a backup battery that will be used to power the system during shutdown if power is removed.  We may eventually move to an open source JFFS2 flash driver as time permits.

The proprietary NAND driver presents an additional wrinkle in that the driver cannot be linked into the kernel due to GPL licensing requirements.  One solution is to boot a small root file system from NOR flash that includes the NAND driver module, and then proceed to boot from NAND flash.

GNU/Linux Root File System

Compulab provides an example root file system (I think based on Debian) and suggests using scratchbox to build applications.  We looked at it briefly, but then decided to build our own rootfs using OpenEmbedded for the following reasons:

  • We can easily add additional packages from the extensive OpenEmbedded catalog as needed.
  • Allows us to have an rootfs independent of the module — we can more easily move to other processor modules or architectures in the future.
  • OpenEmbedded provides us with mechanisms for package management and building complete images that include our applications and tweaks to the OS.

For more information on OpenEmbedded, read our “Introduction to OpenEmbedded “.  With OpenEmbedded, we were able to quickly build a toolchain and a root file system that included the kdrive version of Xwindows and GTK+ libraries.  This rootfs fits in less than 32MB of flash disk space, which is much smaller than Compulab’s OS image.

We have also added machine configuration files to the OpenEmbedded project to support the cm-x270:

Design Support

Compulab seems mainly interested in customers who are interested in purchasing modules in volume.  They do not sell low cost development boards such as LogicPD’s $500 board.  Compulab requires you to purchase a fairly high cost development system ($1900) in order to get started.  Part of this cost is to pay for Compulab’s support costs.  For companies who do not have experience designing systems with PXA270 class processors, we highly recommend getting some up-front help from someone who has experience with these systems.  Even though the module takes care of a lot of the design complexity, it helps to have a detailed understanding of the PXA270 and associated components, as you still need to interact with them.  Consulting companies like BEC Systems can provide assistance in the form of hardware design reviews and Linux OS support to accelerate projects and help avoid costly mistakes and delays.  As Compulab designs only the module, there is only so much they can do when you run into problems — as shown in the next section.

Issues Encountered

Overall, the project using the cm-x270 has gone well.  The only real challenge we have faced is a latch-up issue with the ITE PCI controller on the cm-x270 module.  It appears that this part is very sensitive to the characteristics of the 3.3V supply to the module.  After a considerable amount of debugging and testing, we were able to solve this problem with some filtering and slowing down the rise time of the 3.3V supply.  This is a good example of where a project can get difficult very quickly when things don’t work as expected.


So far, the cm-x270 has worked very well in this project.  With its low cost, it is a very attractive option for companies wanting to implement advanced functionality in their products, but don’t have the time, sales volumes, or experience to justify a full processor board design.  Feel free to post comments about your experiences using embedded computer modules.