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.

FINE–TUNING AN EMBEDDED IDEA

Part 3: Armed and Ready
by Fred Eady

Start ę Retro Rabbit ę Preflight Checklist ę Firmware Developmentę Left Turn, Clyde• Successę Sources and PDF

FIRMWARE DEVELOPMENT

Using the RCM2300 core module made the hardware portion of this upgrade project simple. Fortunately, the Dynamic C software development platform does the same for the working code. I made sure that I wired the upgrade module in such a way to allow for quick removal of the RCM2300 core module from the upgrade motherboard and the ability to plug it into the RCM2300 Development Kit board to verify proper operation of my code and the hardware.

An added plus in selecting the RCM2300 as the upgrade engine is the ease of coding and debugging the upgrade firmware. In Photo 5, you can see the male white-based 2-mm programming header. The programming cable that comes with the RCM2300 Development Kit has an integral RS-232 converter inline with the programming cable itself. This arrangement allows the development platform to be a simple laptop or desktop. No external EPROM or microcontroller programmers or emulators are required to write, debug, and load RCM2300 code. All you need is a serial port and a programming cable.

Because I used the schematic to wire my upgrade module serial ports, I was able to take advantage of the sample code that comes with Dynamic C SE to quickly verify my RS-232 connectivity with the RCM2300 attached to the upgrade module. In fact, I developed 99% of the code with the RCM2300 core module mounted on the upgrade motherboard. I really didnęt miss the coding, erasing, programming, and then testing it loops. I also didnęt miss having to expend funds for external debugging and emulation hardware, either.

Ięm used to writing all of my code from scratch. Using Dynamic C SE was a pleasant experience, in that it is standard C with extensions for the RCM2300. If I had problems with syntax or logic, I simply loaded in one of the sample programs and studied the code. The built-in debugger also came in handy, as I could just stop the code, set my watches, and single step through the problem areas. The Easy Reference poster that comes with the RCM2300 Development Kit also came in handy a few times, as I had to determine how to control the secondary serial port and how to manipulate one of the parallel ports. I was able to figure it out using the reference poster, which saved me the pain of digging through a mass of documentation.

Another advantage to using the RCM2300 and Dynamic C SE is that Dynamic C provides cooperative, time slice, or preemptive multitasking. In addition to controlling the activation of relays, the relay controller also monitors a number of control panel switches. These switches must be monitored at all times and switch activations cannot be missed while the controller is servicing the relays.

I used costatements to solve the switch scanning problem. Each costatement can be equated with a task. For instance, if there were four switches that must be monitored in addition to four relays that must be controlled, the simplest method to provide coverage for all of the devices would be to assign each task to a costatement code segment. Each switch would be interrogated and serviced within its own costatement segment, as would each relay. The costatements have internal structures that keep up with the progress of the task while yielding to other events during nonproductive time. For instance, take a look at Listing 1.

The first costate waits for a switch to close. Assume that all of the switch detect and debounce code is included within the switch_closed function. If the switch_closed function in the first costate segment is not satisfied, the first statement in the second costate segment is executed. The code wonęt hang at the DelaySec(1) statement. Instead, it will jump back to the first unfinished statement within the first costate segment, switch_closed.

Letęs assume the switch never closes in the first costate segment. One second will eventually pass and the next waitfor statement in the second costate segment will execute. The LED will be flashed according to the coding within the flash_LED statement, and the next unfinished statement in the first costate segment (switch_closed) will again be examined. Again, assuming the switch never closes, the first statement in the second costate segment will again begin to run for 1 s.

As you would logically conclude, if the switch closed, the activate_relay1 function would execute, and upon completion, the first costate segment would enter a 60-s delay. The second costate segment would have the opportunity to execute the flash_LED function once per second while the top costate segment 1-min. delay was being observed.

My costate example is simplistic. Depending on what you wanted to accomplish, the costate functionality can be expanded in many other ways. Costates can among other things be named, paused, and aborted. Cofunctions can be intermixed with costatements for additional functionality. Using costatements, I was able to provide multitasking functionality to the upgrade module without the need to do it all from scratch.

PREVIOUS • NEXT