SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

Electronic cam significantly eases development of microcontroller code

Scott Rosenthal
September, 1991

Once I discover something that works for me, I stick with it until something clearly superior comes along. For years I used the venerable 8085 microprocessor for instrumentation designs because the instruction set held no surprises, costs were low, and as time went on the speed increased while power requirements decreased. Did it really matter what was under the hood as long as it ran and ran economically? About four years ago, though, the growing popularity of C and skeptical customers (not to mention skeptical employees) concerned about bits and megahertz pushed me into looking for another processor. In my mind that next device had to be revolutionary, not evolutionary. I wanted something that would carry me forward for the next ten years just as the 8085 had done for the previous decade. The processor, or more formally the microcontroller, I found was Intel's 80C196KC. This device is designed for control applications requiring high-level language support, quick reaction to external or internal events and offloading to hardware of some of the repetitive operations that are the heart of many embedded designs.

The 80C196KC is an outgrowth of the 8096 Intel developed for the auto industry in the mid ‘80s. As the chip evolved, each generation has maintained software compatibility with previous versions while adding new features. Examples of improvements include new instructions, more I/O and additional interrupts. Some generations of the chip are even pin compatible. In addition, the device fulfills my requirement for a revolutionary processor with features that are truly amazing for a single-chip microcontroller. It incorporates a UART with three modes of operation; three pulse-width modulated outputs; two timers; 28 interrupt sources; a watchdog circuit; parallel I/O with built-in FIFO; 232 8-bit registers; a content-addressable memory (CAM); and an 8-channel 10-bit A/D converter. Other interesting features include a dynamically configurable bus that can change between 8- and 16- width on each instruction, opcodes optimized for the C language, and low-power operating modes. (For a full discussion of these features, get Intel's handbook titled "16-Bit Embedded Controllers," order number 270646-003.)

What's a CAM?

In my mind, the neatest feature of this microcontroller is the CAM. To understand how this mechanism works, start with a model that you might be more familiar with---mechanical cam logic. It's what causes an auto's valves to open and close synchronously with piston position; designers previously used it to control dishwashers and traffic lights. Basically, a mechanical cam consists of a shaft with a series of actuators spaced at predetermined locations. As the shaft turns, the actuators cause events to occur by closing switches or moving linkages at predetermined shaft positions.

The CAM unit in the 80C196KC operates in an analogous manner (Fig 1). Each of the CAM's eight slots is composed of a time and an action. As a given timer increments, logic in the chip compares its current value to all slots in the CAM. If any slot's time matches the current timer value, the chip performs the specified action. Possible actions would be to assert an internal interrupt, reset the clock, or trigger an external event using one of the chip's High Speed Outputs (HSOs). In addition, when a CAM slot matches the timer, you decide whether the CAM slot becomes available for a different action or if the action is locked in the CAM slot. The greatest feature of the CAM, however, is that it continues operating even if the microcontroller crashes!

To understand how you might use that feature, consider the following simple application. I once designed an instrument that had to blink an LED with very high drive currents. The pulse rate and duty cycle were programmable, but if the LED stayed on too long it would blow out. Even with carefully written software, there was always a chance that during emulation the program would stop at a breakpoint with the LED on and cause it to fail. Unfortunately, the requirement for a programmable duty cycle ruled out a one-shot and would've required a fairly complex fail-safe circuit. However, the 80C196KC makes this problem easy to solve. Fig 2 shows the code and a simplified schematic of how to approach the problem using three CAM slots. The first sets the blink's period by resetting the timer, in this case Timer2, to zero when it reaches this time. The second slot sets HSO0, high, and the third slot sets HSO0 low; together these two slots set the duty cycle. The CAM repeatedly pulses HSO0, enabling and disabling the LED driver circuit without any software intervention.

The CAM unit can also repeatedly acquire data from many different sources at specific time periods. In addition, using data structures allows you to reuse program code so you'll end up with very little code doing a lot of work.

I've only found two problems with the CAM unit. First, CAM-generated software timer interrupts are level sensitive instead of being edge triggered. In simple terms this limitation means that if an ISR executes in less than a clock tick, the CAM generates additional interrupts until the clock changes its value. Typically Timer1 isn't a problem because it consists of the system clock divided by 16. However, Timer2 comes from an external source and can run at any speed. The other problem is with myself---I've found so many uses for the CAM that I’m constantly filling it up. If only it had more slots then I could... Well, I guess I'll have to wait for the next generation.

Reconfigurable bus width

The dynamically configurable bus is also exciting. It allows any bus-width combinations of memory or I/O. In one of my applications the boot code resides in an 8-bit ROM. When the controller starts running, it gets a new program downloaded serially and loads it into a 16-bit RAM. Once the controller downloads the program, it shifts execution to the RAM. Due to this trick I was able to avoid the expense of a 16-bit ROM for the bootstrap but get full speed during normal operation. Here's something I learned about 16-bit memories---don't write a word to an odd address and keep your stack off odd addresses. The problem is that the processor assumes even-byte word boundaries, and attempting to use odd addresses results in unpredictable operation.

Now that I've convinced you to incorporate this device into a design, what about support tools? I’m aware of at least four firms that market emulators for the 80C196KC---Annapolis Micro Systems (Annapolis, MD (301)269-8096, Huntsville Microsystems (Huntsville, AL (205)881-6005), Softaid (Columbia, MD (410)290-7760) and Intel (Hillsboro, OR (800)468-3548.

I don't have any experiences with emulators from the first three companies, but I've used the Intel tool a great deal and find it less than ideal. I use the PC version, which is more of a software development system than a true emulator. Hence most serious software errors cause the emulator to lose all trace data. In addition, even when it's available, trace data doesn't actually show what the emulator read at an address. It only records the addresses accessed and during a listing goes out to the memory and gets the data. With unknown hardware, this shortcut renders the trace function useless for debugging. In fact, it masks problems. The other difficulty with the PC version of the Intel emulator is that you must purchase a new model for each generation, whereas some other tools seem to work with each new generation. PE&IN



About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.