Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Intro to Embedded Linux: Development models

Posted: 18 Dec 2014     Print Version  Bookmark and Share

Keywords:Embedded Linux  processor  RAM  Ubuntu  RHEL 

There are two different models of Embedded Linux development: Cross-platform and self-hosted.

Cross-platform development
The traditional model for Embedded Linux (and all embedded system development) is cross-platform development. In this development style, you create your software on a powerful host system (like your desktop computer) and then transfer the binary image to a much smaller target system. Your host computer has many features which make it an excellent development environment: a fast processor, lots of memory and disk space, a big display, and all of the tools you need. You have documentation and access to the Internet for articles, support, or software.

Your target system is likely designed for a specific application, such as router, media player, file server, controller, or some other purpose. The processor is generally limited in power and speed, selected to meet the requirements of the application. Often, the processor architecture for the target system is different from your host system, selected for low price or integrated peripherals. The target's system memory, both RAM and persistent, is limited, just the amount required to run the application programs. Connections from the target system to the "outside world" are only those needed to run the application. For example, a file server would have a network connection and connections for hard disks, but no display or keyboard connections.

 Typical cross-development setup for working with embedded board

Figure 1: Typical cross-development setup for working with embedded board, in this case, a Linksys WRT54G router.

You use cross-compilers on the host system to compile your kernel and application programs into a binary image that you transfer to the target system. The cross-compiler, as well as a cross-debugger, may be different versions than the host system compiler and debugger, designed to support the target processor. For the most part, they work exactly the same as the corresponding tools on the host system. Other than the cross-development tools, you use the host tools for everything else, from editing files, to building the kernel or applications. The versions of the kernel or application programs used for the target system may be different from those on the development system. Your development system may have a standard distribution, like Ubuntu or RHEL, while your target system has a newer kernel which is still under development and may not be completely stable.

There are some added complexities with the cross-platform development model. When you compile your program for the target, it is important that the system header files for the target are used, and not the system headers for the host. You can imagine the problems which might occur if one of your compiles incorrectly uses a host system header which defines an int to be 64 bits when the target uses 32-bit ints. Most of the time, the cross-compiler takes care of insuring that the headers for the target system are used when compiling programs for the target.

You will need to build a complete file system, including the kernel, application programs, and all of the directories needed to populate a Linux file system. There are several tools which will help do this, such as buildroot, OpenEmbedded, or Yocto. We'll discuss these in a future article.

Another complexity is that the file system on the target may be different from the host. Many targets use flash memory for storage, which might use the Journaling Flash File System (JFFS) instead of the EXT file system used on hard drives on the host. You will need to convert the file system on the host into the binary format needed to transfer to the target and write to the flash memory.

Depending on how the target boots, you might need to configure a TFTP server and DHCP server on your host. That usually means that you will use a different network connection on the host system to connect to the target and not the one you use to connect to the Internet. (Corporate IT departments are understandably unhappy when they discover rogue DHCP servers responding to requests on the corporate network.)

1 • 2 Next Page Last Page

Comment on "Intro to Embedded Linux: Development..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top