THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

USING A BOOT MONITOR IN EMBEDDED SYSTEMS

Part 2ýBuilding on the Basics
by Ed Sutter

Start ý The Ethernet Interface ý The Command Line Interface ý "Get Your Tokens Here" ý One Last Topic About CLI ý Executable Scripts ý Application-to-Monitor Hook-Up ý The Moncom() Function ý The Monconnect() Function ý Letýs Regroup ý Xmodem and Tftp ý OK, Iým Done! ý Sources and PDF

EXECUTABLE SCRIPTS

Iýve talked about a fairly useful CLI processor, but if all you can do is execute one command at a time by typing the command in manually, you still donýt have anything really special. Iýve hinted at this already and shown an example (the monrc file), so letýs combine the capabilities of the CLI with the underlying flash file system (TFS) and provide some scripting capabilities. For the sake of this article, scripting is simply the ability to create a file of commands, one per line, and execute that file as if it was a command. This capability, coordinated with a handful of commands that provide some conditional branching and looping, provides you with a small programming environment right in the monitor.

First, take a step back and consider the command set in the monitor. The core set of monitor capabilities will include commands that twiddle with memory and I/O a bit, some interface commands for Ethernet and RS-232, a CLI interface into the flash file system, and a handful of commands that are dedicated to providing some simple programming capabilities like conditional branching and subroutines (see Table 2).

Based on my earlier CLI discussion, if this was your command set, then each of the entries in the left column would be the name of the function, and the text in the right column would be the first line of the helptext[] string array for that command.

Because scripting fundamentally requires a file system (because the script itself is a file of commands), the scripting capability comes with TFS and is actually quite simple. In the simplest case, all youýll need to do is retrieve one line of the file at a time and pass that line to the docommand() function discussed earlier. When you reach the end of the file, youýre done. The script runner in Listing 7 does just that, plus just a little more for handling tags and subroutines. Note, however, that there are some limitations.

The script runner in Listing 7 uses the TFS API to interface with the script file. Some of the variables are manipulated by the goto, gosub, and return commands with their code shown in Listing 8 Note that this code would be executed during the execution of the script and would alter the state of the script runner slightly.

And finally, Listing 9 is the code associated with the exit command. Notice how the goto, gosub, and return command have a similar look.

With this fundamental set of functions plus the use of shell variables, additional capabilities can be added easily. For example, a powerful if command is available to do conditional testing and branching. Without going into the detail of the code behind if, just think about it. The CLI syntax is if {item1} {test} {item2} {action}, where item1 and item2 would be the variables being tested, test would be one of some set of strings that represent greater than, less than, and so forth, and action could be exit, return, gosub tag, or goto tag. To keep things simple, this script runner does make the assumption that there is one complete command per line, so there is no interactive mode.

To finish up without getting into a lot of detail about each of the commands, you can build a script. You can blink a memory-mapped I/O pin that has an LED on it until a location in memory is nonzero (see Listing 10).

PREVIOUS • NEXT