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.
Write a Program for the LBox and Run It

With the tool chains available and with the NFS mount still active, I can work in the NFS mounted directory, write a standalone program and cross compile it. I then can run it with Minicom while it resides in the NFS mounted directory.

Let's try that. Start by working on the workstation as follows:

  • Using a shell window on the workstation, enter a simple program in the /home/fredsmith/lbox_stuff directory:

      /* bye.c
      int main() {
        printf("Lbox says goodbye.\n");
  • Compile the program with the cross compiler:

    m68k-elf-gcc -m5200 -msep-data -Wl,-elf2flt -o bye bye.c -lc
  • Make sure the LBox can execute the result by entering chmod 755 bye.

Next, we work on the LBox by way of the Minicom window.

  • Navigate in the NFS mounted directory to wherever the executable is. For example, if it's at the top of the mounted hierarchy, enter cd /var/nfs.

  • Enter ls -l to assure that you are in the directory containing bye, and check that it's executable.

  • Execute the program by entering ./bye, and you should see as output: Lbox says goodbye.

In the next installment of this series, we will recompile an LBox kernel and install it on the LBox, along with a root filesystem. This gives you the option to tailor the kernel and root filesystem for your specific needs.



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?


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.



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.