Embedded Systems Design Europe - April 2008 - (Page 30)

linux ing Cscope and SilentBob to analyze source code,” www.linux.com/article.pl? sid=07/03/05/1715201). And don’t forget to print the Emacs reference card (refcard.ps) that came with your Emacs installation. 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 makeﬁle 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 conﬁguration, 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) 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 conﬁgure 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 ﬂash 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. 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 ﬂash. It’s written for Das U-Boot, but can be easily modiﬁed 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. DEBUGGING Debugging embedded Linux is tricky, because the technique can be different depending on whether you are debugging applications, drivers, or kernel code. The only common element is the 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 conﬁguration, make sure that the kernel is compiled with Listing 2 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. #!/usr/bin/expect spawn minicom send “\r” expect “>” { send -s “tftp 0x1000000 u-boot.bin\r” } expect “done” {send -s “protect off 0x20000000 0x2007ffff\r” } expect “Un-Protected” {send -s “erase 0x20000000 0x2007ffff\r”} expect “Erased” { send -s “cp.b 0x1000000 0x20000000 0x20000\r” } expect “done” 30 APRIL 2008 | embedded systems design europe | www.embedded.com/europe 028-029-030-031-032_ESDE.indd 30 8/04/08 12:41:17 http://www.linux.com/article.pl?sid=07/03/05/1715201 http://www.linux.com/article.pl?sid=07/03/05/1715201 http://www.linuxjournal.com/article/1299 http://www.linuxjournal.com/article/1299 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - April 2008

Embedded Systems Design Europe - April 2008 Contents Chip Industry Confronts 'Software' Gap Wind River's VxWorks OS Part of the nEUROn UCAV Demonstrator iSuppli Cuts Electronic Equipment Forecast Study Says GigE Vision Not Mature Chip Aids Wireless Health Monitoring Kontron Reports Strong Financial Growth Xilinx Completes Virtex-5 Line-Up French Project Builds Open Platform Home Automation Group Uses Enocean Radio Layer MIPs Adds Multi-Core Option to Portfolio Cover Feature: Next Gen Programmable Chips: Why Can't Hardware Be More Like Software? Improving Productivity & Quality With Domain-Specific Modeling Efficient CRC Calculation With Minimal Memory Footprint Do-It-Yourself Linux Embedded Development Tools Hardware/Software Verification Enters the Atomic Age New Products Advertising Contacts

Embedded Systems Design Europe - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.