Do-it-yourself embedded Linux development tools

Alexander Sirotkin

November 30, 2007

Alexander Sirotkin

Running your app
Downloading and running your code on the embedded target is probably one of the most frequent operations you'll do, so it's important to make this process as fast and easy as possible. This usually done using TFTP or JTAG, but Network File System (NFS) can make this process easy and transparent. NFS can be used by running the NFS server on your host and having makefile rule to copy the compilation results to the NFS root directory and mounting this directory via NFS from the embedded target. This way, the compiled application will appear immediately at the target without any intervention by the programmer, as illustrated in Figure 2.

When implementing the host configuration, make sure that the NFS server is installed, and add the following line to /etc/exports (after modifying IP and directory):


/home/user/nfsroot 192.168.0.*    (rw, no_root_squash, sync)

then restart the NFS server. This gives NFS clients from 192.168.0.0/24 subnet full read/write access to your nfsroot directory.

In the target configuration, make sure that the kernel is compiled with NFS support. In other words, CONFIG_NFS_FS, CONFIG_NFS_V3 and CONFIG_NFS_V4 options are enabled and the mount command supports NFS (if you are using busybox, check that the CONFIG_FEATURE_MOUNT _NFS option is enabled). You'll have to issue the following command on the target machine (probably as part of initialization script):


mount 192.168.0.9:/home/user/     nfsroot /mnt/nfs.

If you can't use NFS, whether because you can't modify the kernel or because your short term project doesn't justify the effort to configure it, you still don't have to copy your application manually from host to target. This task can be automated using expect or minicom scripts, as shown below.

Automation
Many tasks can be automated using shell scripts. Note that you can run scripts on the host as well as on an embedded target (most embedded Linux distributions include shell with scripting functionality, although it's more limited). An introduction to bash scripting can be found at www.linuxjournal.com/article/1299, but remember that you won't be able to use many of the advanced scripting options on your embedded target, as it'll likely have one of the less powerful (and less memory hungry) shells, such as BusyBox ash.

Assuming you're capable of writing a simple bash script, we'll dive into a bit more complex but useful topic, interactive scripts. Using interactive expect(1) scripts, you can automate such tasks as image download and flash programming. But you can't use simple bash scripts to automate interactive tasks because of branching and timing issues.

Basic expect(1) scripts consist of a "spawn" command that executes the utility that requires interactive automation, such as telnet or minicom and a series of "expect" and "send" commands, as illustrated by the example in Listing 2.

View the full-size image

The expect command waits until one of the patterns matches the output of a spawned process. Send sends string to the current process. The script in Listing 2 downloads and copies a new bootloader image to flash. It's written for Das U-Boot, but can be easily modified for any other bootloader or other environment. Most expect(1) distributions include a handy autoexpect script that automatically remembers the commands you type and creates an expect script for you. However, I encourage you to use automatically generated scripts only as a template for writing your own, which will be more readable and easier to maintain.

< Previous
Page 3 of 6
Next >

Loading comments...

Most Commented

  • Currently no items

Parts Search Datasheets.com

KNOWLEDGE CENTER