An Introduction to Embedded Linux Development, Part 2

Part 2 in a series on embedded development explains how to establish serial communication between an LBox and a workstation, compile tool chains and write and run a simple program.
Connect via Ethernet

If connected to the Internet when booted, the LBox dhcpcd daemon should negotiate an IP address. If this doesn't occur--check by entering ifconfig in the Minicom window--we either can assign it manually or try again from the LBox command line by entering dhcpcd -p -a eth0 &.

The LBox supports telnet, so I now could telnet into the LBox from a shell on the laptop--if I configured the laptop for telnet. As shipped, the LBox does not support SSH. However, it does have an HTTP daemon, so I could access it with a browser. A Web page already was set up on the LBox (see Figure 1) that allows one to turn on, turn off or toggle an LED on the LBox board; it also provides links to the source code. This nicely demonstrated that you could interact with the LBox through a Web interface.

Figure 1. LBox Web Page

Install the Cross Compilation Tool Chains

For any SBC, the vendor either supplies the tool chains or tell users from where to download them. Explicit directions should be provided and followed for installing the chains. These directions vary from vendor to vendor.

In our case, the tool chains were available on the CD provided with the LBox. Other software packages are included on the CD, including the uClinux source hierarchy, but we'll deal with those later and keep to the task at hand. The CD also provides an INSTALL file containing directions for installing the tool chains. These are quite simple. In particular, there is a shell script to execute that carries out the installation.

Carry Out NFS Mounting

This subsection is not particularly LBox specific and is of general interest. Compared to a workstation, the LBox has limited resources--no hard drive. It is convenient for the developer to create a workspace on the workstation hard drive and then (NFS) mount that workspace as part of the LBox hierarchy. Once mounted, this workspace can be accessed from both the workstation and the LBox. Because the workspace exists on the workstation, it is easy to create periodic archival backups, for example, on CD-ROM. And because the workspace also is mounted on the LBox, we can test code developed in the workspace by running it on the LBox without using the limited file storage capabilities of the LBox.

There are two methods we can use to create the workspace. The first presumes that both the LBox and workstation are connected to the Internet; we then can mount a workstation directory on the LBox. The second method presumes that the LBox and workstation are not connected to the Internet but are connected directly to each other with an Ethernet cable. We discuss the second method here. The first is discussed (along with telnet connection) in this FAQ.

Connecting from the LBOX directly to the workstation by way of an Ethernet cable isolates us from the wider Internet, which might be of interest for security reasons or when we don't have access to the Internet, for example, while on the road in a remote setting. That's what we describe here.

Our assumptions here are that the NFS server is up and running on the workstation, the LBox is connected directly to the workstation with an Ethernet cable and the LBox is connected to the workstation with a serial cable. In my case, some firewall rules got in the way, so I turned the firewall off--the system was isolated from the Internet anyway.

We proceeded as follows:

  • Reset the LBox

  • Start Minicom on the workstation so the Minicom window emulates a terminal for the LBox

  • Configure eth0 for the LBox (in the Minicom window) with these commands:

    
    ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
    
    
  • Configure eth0 for the workstation using a workstation shell, as follows:

    
     ifconfig eth0 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
    
    
  • Test each by pinging the other--from a workstation shell try ping 192.168.1.1 and from the Minicom window try ping 192.168.1.2

  • Assuming all worked fine, now establish the file on the workstation you want to mount on the LBox; that is, on the workstation create a new directory for your LBox stuff; let's say it's /home/fredsmith/lbox_stuff

  • Create a file /etc/exports on your workstation containing the line /home/fredsmith/lbox_stuff *(rw,insecure). Take care not to include spaces in the parenthetical options list.

  • So that the new /etc/exports is scanned, restart the NFS server daemon on your workstation. For my Debian-based workstation, I would enter /etc/init.d/nfs-kernel-server restart. Some years ago, I did run into Red Hat-based systems on which I needed to stop and then start the daemon because restart wasn't quite equivalent.

  • Use the Minicom window to make a mount point: mkdir /var/nfs.

  • Now try the NFS mount command from the Minicom window as follows:

    
      mount -t nfs -o nolock 192.168.1.2:/home/fredsmith/lbox_stuff /var/nfs
    
    
  • Investigate whether the mount was successful by examining the contents of /var/nfs in the Minicom window.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Replacement of classic automation system

pascalv's picture

Can this replace automation/control systems currently used in the industry (Allen Bradley/Rockwell, Schneider/Modicon, etc)?

If no, is it a long term goal? (approximatively when?)
Otherwise, what is fundamentally different?

Cheers,

classic automation system

Richard's picture

Certainly you could replace a standard PLC, but would want a sbc that interfaced conveniently (e.g. via optically isolated relays) to the field wiring. Real-Time Linux would be a good idea, so you could truly seize control of the hardware and have a handle on latencies and the interrupt structure. The Real-Time Linux variants already perform control applications. Personally, I would concoct a control language that consisted of concurrent state machines. Such languages have been used before in the commercial sector - as an alternative to relay ladder logic.

cheaper-than-cheap SBC alternatives

blk's picture

Wondering: Does this series apply pretty well to the really really cheap linux appliances? I'm thinking of the LinkSys WRT54G wireless router and NSLU2 network storage, both linux boxes around $70 new (or less) with people hacking the linux installs.

ref: http://www.tomsnetworking.com/Sections-article93.php

cheaper-than-SBC

Richard's picture

Cheap Linux appliances might be a good route to go. However, you do want the capability to reflash the OS unless you just want to work at the application level. And if you do have the capability to reflash the OS, you need to be able to reflash yet again if your first attempt was a kernel that won't boot. Further, if it is possible to accidentally blow away the boot loader, you want a way to reconstitute the bootloader. These capabilities are typical of well supported SBC's, but not necessarily of the cheap Linux appliances. The latter may have Linux developer/hacker lists where you could ask appropriate questions.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix