Introduction To Embedded Microcomputer Systems Motorola 68116812 Simulations

Running Motorola 6811/6812 Simulations for Your Embedded Systems Course

The 6811 and 6812 microcontrollers are old, but they still show up in a lot of undergraduate embedded systems syllabi. You'll find them in courses covering basic timer modules, ADC/DAC, serial communication, and GPIO handling. The simulations are usually straightforward if you know what you're working with, and they're more about confirming your register logic than doing anything fancy. The simulations generally revolve around a few core setups. You write code, compile it into a .S19 or .M19 hex file, load it into the simulator, set breakpoints, watch registers change, and verify behavior against the datasheet. The 6812 adds a CRC module, more I/O, and more timer channels over the 6811, but the toolchain and debugging flow are essentially the same. The most common simulator environment you'll encounter is the Motorola CodeWarrior Development Studio, specifically versions like Codewarrior 5.0 or earlier that had built-in 6811/6812 target support. Some universities also used standalone simulators like Sim6811 or custom MATLAB/Simulink models. If your course is using something specific, the lab manual will point you at it. The general principles below apply regardless of which tool you end up using.

Here's the practical setup. You install the simulator or IDE, create a new project targeting the MC68HC11 or MC68HC12, select your assembly or C compiler, and write your code. For a basic exercise, you might toggle a GPIO pin and observe it on a virtual oscilloscope or logic analyzer inside the tool. For a timer exercise, you configure the Timer Input Capture or Output Compare module, set the prescaler and modulus, and watch the counter register increment on each simulated clock tick. The key thing to remember is that the simulator runs at a configurable clock speed. A 2 MHz crystal gives you a machine cycle every 12 microseconds on the 6811. If your delays seem wrong, check whether the simulator clock matches the target hardware configuration in your code. I ran into a specific issue once where my 6812 timer output compare code appeared to work in simulation but produced completely wrong timing when deployed to actual hardware. The problem was that the simulator assumed the external oscillator was enabled and the PLL was locked, but my code never actually performed the system clock initialization sequence from the datasheet. The simulator ran the timer off its internal default clock rate while the real chip was stuck in a different clock mode. The fix was adding the full clock setup routine from section 4.3 of the HC12 Reference Manual before the timer configuration code. Once I did that, simulation and hardware behavior matched exactly. Here's a practical example of a basic simulation workflow using assembly. Let's say your assignment asks you to read an analog voltage from channel 0 of the ADC and trigger a comparison against a threshold. You start by configuring the ADC control register ADBCTL. You set the conversion rate bits, enable the ADC, and select the input channel. Then you write a loop that starts a conversion, polls the ADC interrupt flag, reads the result register, and compares it to your threshold value. In the simulator, you can inject a simulated voltage value directly into the ADC result register rather than building an actual analog circuit. This saves time and lets you focus on the digital logic.

For serial communication exercises, the 6811/6812 has SCI and SPI peripherals. The SCI simulation is relatively simple since you just verify that transmitted and received data registers match when you loop the module back. The SPI simulation is trickier because you need to manage clock polarity and phase settings carefully. I found that many students get tripped up on the SPI mode configuration, specifically the CPOL and CPHA bits in the SPCR register. Setting the wrong combination causes the first clock edge to sample data incorrectly, and the simulator will show corrupted transmissions that look like hardware failures. The workaround is to always double-check your mode against the datasheet timing diagrams before running the simulation. There's a table in chapter 15 of the HC12 reference manual that maps all four SPI modes clearly. A common pitfall with these simulations is the assumption that the simulator handles all memory types the same way. The 6811 has EEPROM, FLASH, and RAM in different address spaces. If your code writes to an address outside the RAM range, the simulator may silently ignore it or throw an access violation depending on the tool. Always verify that your variable declarations map to the correct memory type. In assembly, you use org directives to place constants in EEPROM or FLASH and use the .rs directive or direct memory allocation for RAM variables. Mixing these up causes hard-to-debug issues where data appears to initialize correctly in simulation but vanishes between reset cycles. Another thing beginners consistently miss is the difference between the 6811 and 6812 register names. The 6812 has extended registers and additional peripherals. If your course materials reference 6812-specific features like the CRC module or the second ADC block, make sure your simulator project targets the HC12, not the HC11. Using the wrong device profile means the simulator won't recognize those registers and your code will either fail to compile or simulate incorrectly.

If you're looking for simulation files or project templates, check your university's lab repository. Many professors maintain their own sets of working examples. Outside of that, the Motorola documentation is freely available and serves as the primary reference. The HC11 and HC12 reference manuals are the definitive sources, and the application notes like AN1570 and AN1818 walk through common peripheral configurations with simulation-compatible examples. CodeWarrior's help system also includes example projects for most peripherals, though older versions may not be readily installable on modern systems. One practical note about the simulator itself. Most of these tools have a maximum simulation speed. For timing-critical code, running at full speed bypasses the real timing behavior because the simulator may not process intermediate register states correctly. Drop the simulation clock to a manageable rate, single-step through the critical sections, and only run at high speed for non-timing code. This habit alone cuts debugging time significantly. The main limitation of these simulations is that they don't capture everything about the hardware. Power supply noise, signal integrity issues, and certain edge cases in interrupt handling simply don't appear in a software simulation. If your course requires hardware validation alongside simulation, treat the simulation results as a necessary but insufficient verification step. The simulator tells you whether your logic is sound. It doesn't tell you whether your hardware design is robust.

If your course uses a different microcontroller instead, the concepts transfer directly. ARM Cortex-M simulation with STM32CubeIDE or Atmel Studio follows the same pattern: configure registers, set breakpoints, watch values change, compare against the reference manual. The 6811/6812 is just the academic entry point for learning that pattern.