Summary

Thats it. Ive described the directory structure, the target-specific makefile, the config.h file used to include only the portions of the monitor I need, and the major blocks of the porting process. Having walked through the steps, you can see that the config.h file also serves as a mechanism to control the complexity of the port. Instead of trying to deal with everything all in one shot, you can use config.h to add one subsystem at a time.

This example was somewhat unique because it put a monitor into a system that already had a monitor. If the DBUG monitor were removed, I would have been forced to use some facility like a BDM or JTAG downloader or a memory emulator to get the initial versions running. In the worst case, I could have just manually burned the boot flash.

Now a confession: I mentioned earlier that I shamelessly re-used code from Motorolas DBUG monitor. I went through this entire port with very little experience on the MCF5272C3. Despite this problem, I was able to cut and paste pieces of the DBUG monitor into specific points in MicroMonitor to quickly get it up and running. There are two good points to gain from this:

• The Motorola folks did a very nice job organizing the DBUG source code.

• If boot code already exists for a target (and it almost always does but maybe not always as well organized as DBUG), then porting MicroMonitor is very straightforward.