The THRSim11 68HC11 Simulator

Dr. Dobb's Journal March 1999

By Wilbert Bilderbeek, Harry Broeders, and Alex van Rooijen

THRSim11 is a Windows-based simulator that lets you edit, assemble, simulate, and debug programs for the Motorola 68HC11 microcontroller. THRSim11 simulates the CPU, ROM, RAM, and all memory-mapped I/O ports and onboard peripherals, such as the timer (including pulse accumulator), analog-to-digital (A/D) converter, parallel port, serial port, and I/O pins (analog and interrupt). Furthermore, a number of simulated external components can be connected to the pins of the simulated 68HC11 while debugging, including LEDs, switches, analog sliders (with variable voltage potential), and serial transmitters/receivers. There is also a 4×20 LCD character display mapped in the address space of the 68HC11.

THRSim11's user interface lets you view and control every register (CPU registers and I/O registers), memory location (data, program, and stack), and pin of the simulated microcontroller while debugging. You can also stop the simulation at any combination of events.

THRSim11 got its start in 1992 at the Rijswijk Institute of Technologies in the Netherlands. We are now working on the THRSim11 Component Development Kit, which lets you develop your own components. These can then be connected to the pins, registers, and/or memory locations of simulated microcontrollers. Because this framework is based on Microsoft's COM specification, any programming language that supports COM can be used. The components currently available include LED, switch, seven segment displays, and logical ports. A freely available demo version of THRSim11 3.06 is available at http://www .thrijswijk.nl/~bd/thrsim11/ thrsim11.htm, and from DDJ (see "Resource Center," page 5).

Central to THRSim11's design is the Observer pattern (see Example 1), described by Erich Gamma and Richard Helm in "Observations on Observer" (Dr. Dobb's Sourcebook, September/ October 1995), and Design Patterns, by Erich Gamma et al. (Addison-Wesley, 1995). To implement THRSim11, we extended Observer to make the pattern easier to apply. (We also made extensive use of Observer when we implemented the simulation of the 68HC11's onboard devices -- timer, serial ports, parallel ports, A/D converter, and the like.) The heavy use of the Observer pattern resulted in an application that consists of several components or modules loosely coupled together. Each component consists of several subjects and observers which can be connected to the observers and subjects of other components. This makes the THRSim11 68HC11 simulator program easy to extend. You can, for example, connect a simulated AND gate to the pins of the simulated 68HC11 as easily as you can connect a real AND gate to the pins of a real 68HC11.

When we originally evaluated the Observer pattern, we asked the following questions:

• Since every ConcreteObserver has to call attach()/detach() in relation to a Subject, can this responsibility that all ConcreteObservers share be transferred to a common base class (Observer)?
• Since every ConcreteObserever must contain a reference to the ConcreteSubject it observes, can this reference be defined in the common base class (Observer)?
• Since every kind of ConcreteSubject must be derived from Subject, is it possible to automate the generation of ConcreteSubjects?
• If a ConcreteSubject being observed by a ConcreteObserver is destroyed, can we avoid the reference inside the ConcreteObserver becoming a dangling reference?
• If a ConcreteObserver observes more than one ConcreteSubject, the following problem arises: If the ConcreteObserver receives an update() call, it cannot determine the cause of this call. So the ConcreteObserver does not know which value it should update. According to Gamma and Helm, the solution to this problem is to send along a parameter with the update() call. This can be the pointer of the ConcreteSubject that caused this update() call. But this leads to a switch statement inside the ConcreteObserver::update() member function to determine the cause of the update() call and take appropriate action. This switch statement switches on an alarm bell inside our object-oriented minds because it is more often than not a sign of improper object-oriented design. Is there another way to observe several ConcreteSubjects from within one Concrete-Observer?

Example 2 illustrates how we extended the Observer pattern to answer "yes" to all of the aforementioned questions. As you can see, we moved the link from ConcreteObserver to ConcreteSubject to their base classes (from Observer to Subject). This makes it possible to avoid dangling references. The template Model<T> can be used to generate a simple ConcreteSubject that encapsulates a value of type T. The template CallOnWrite<T,C> can be used to generate a kind of smart pointer to every Model<T> that a component C wants to observe. We used Microsoft's COM to extend this pattern even further to make it possible to observe models from within other applications. More information, including all source code, is available at http://www.thrijswijk.nl/~bd/thrsim11/ddj/.

DDJ

Back to Article