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

KEY INGREDIENTS

So, where do you start? The preceding paragraph describes a lot of nice stuff, but if it isnıt put together properly itıs still not going to be much more than just a monitor destined for replacement by the application code after itıs written. What makes this platform somewhat unique is the fact that itıs heavily intertwined with a tiny flash file system (TFS). Each of the components in the monitor will be described, with emphasis on how including an FFS makes things more powerful. In addition, there are tools needed on the PC to pull all of this together, so Iıll talk a bit about them.

One final note before digging in, this design is the result of many rewrites. Some of the rewrites were to clean up sloppy code and comments, some to reorganize in a more CPU-platform-independent way, and others to adjust the design based on lessons learned from previous implementations. Iım sure over time, a few more will be done based on reader feedback, as I am not claiming that this is the "beats all others" monitor. The point here is to introduce an implementation that has worked for me on several projects and to make this a learning experience for all of us. Here are some key things that I have learned from writing several monitors:

• Keep things simple, and be aware that the command set you write will be used by other people.
• Provide a strong help facility for each command in the CLI, not with a user manual but through the CLI.
• If you can write the function in C, do it. Get out of assembler as soon as you can. Hand-tweaking certain functions for performance is fun, but itıs not at all portable.
• Use as little of the CPU-specific features as possible. This monitor doesnıt even enable interrupts on the CPU.
• Design your code for reuse and maintainability. If you are writing code that could ultimately end up on several different target platforms, try to keep a clean line between the target-specific code and target-independent code. I think itıs better to duplicate some code to maintain cleanliness instead of filling up a file with gobs of #ifdefs.
• Realize that there are several parts to the monitorıthe CLI that the monitor presents to you, the API that the monitor presents to the application, and the tools that will run on the PC to interface to the monitor for downloading files and for general communication with the target. And, with that comes the fact that this is a package, not just a block of code destined for one target board.
• And probably most important, realize that the intent of the monitor is not to demonstrate the CPU/hardware platform it is residing on. Its purpose is to provide a common boot platform that you can reuse on future projects.

PREVIOUS • NEXT