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 1ıConstructing the Platform
by Ed Sutter

Start ı The Typical Package ı What are the Alternatives? ı Key Ingredients ı MicroMonitor Run Time Startup ı Just After Reset ı Establish Exception Handlers ı I/O Initialization ı Flash Memory Drivers ı Sources and PDF

WHAT ARE THE ALTERNATIVES?

Well, you have two. You can say, "Fine, I never saw the need for a monitor anyway," and continue the course youıre currently on or you can investigate a bit further to see if there is a place for a well-designed monitor for embedded systems. I wrote the remainder of this series with the assumption that youıre interested in the idea, so for starters, Iıll change the name "monitor" to "generic embedded system boot platform." Right off the bat, itıs starting to sound better! OK, not really, but I liked the idea.

The point is that you must immediately think of the boot code as something that could potentially exist throughout the life of the project. If you donıt do this, youıll end up with just another monitor, with the same problems mentioned earlier that will be discarded as soon as the application is solid enough to take over the target system. Instead of picturing a simple command line interface and a few peek-and-poke commands, letıs raise the bar. As the new name implies, your boot code will provide a common platform for a variety of different embedded system projects. Its look and feel will be independent of the underlying CPU complex and will only require flash memory and an RS-232 port to run. But ideally (and Iıll assume it to be the case), an Ethernet interface is also supported and recommended.

What will you need? First and foremost, a flash file system (FFS). This immediately opens up a lot of possibilities. Files can be used for just about anything. As a matter of fact, the monitor will use a file in the FFS to configure itself at boot time. Throw in DHCP/BOOTP for dynamic configuration, a CLI through RS-232 or Ethernet UDP, TFTP/XMODEM for bidirectional data transfer, and an environment whose characteristics are transferable to the application that it turns control over to. Plus, use of this platform doesnıt limit the design to any particular RTOS. As a matter of fact, it can be used to help develop the BSP that will ultimately be used with the RTOS. Or, depending on the needs of the project, it may not need an RTOS. The application can be a simple, single-threaded ELF, COFF, or A.OUT executable that is automatically loaded and the entry point jumped to at startup. Now weıre talking! This has to get you excited! Whew! I need to relax for a minute.

PREVIOUS • NEXT