8051 Coding and Debugging

by Olaf Pfeiffer, ESAcademy
based on the article "Real-Time 8051 Systems - An Overview", by Mike Beach, Hitex UK

Using assembly and sporadic status messages sent to the serial port to develop and debug an 8051 based application is not exactly "state-of-the-art". This article shows some of the benefits engineers get by using the right tools.

[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]

A Simple Example

The value of this technique is best illustrated by the following real-time testing example:

The speed of a rotating shaft is to be measured in real time as a scaled value between 0 and 10000 rpm and from this a variety of other calculations performed. The problem here is a typical 8051 task; an interrupt is generated by an input capture pin every 180 degrees of shaft rotation. Every time a negative transition occurs on the capture input 0, the TIMER2 counter value is latched into an input capture register. This is done every 180 degrees.

The input capture service routine picks up this value, subtracts it from the last value and works out the time in TIMER2 counts between successive interrupts or 180 degree markers on the shaft. Knowing the time between interrupts, it is possible to work out the rotational speed.

The calculation to be performed in the service routine every 180 degrees of shaft rotation is:

time_for_180 = abs(time_this_180 - time_last_180) ;

speed = 382500 / (time_for_180) ;

Where 0 to 255 represents 0 to 10000 rpm and the numerator is a constant that assumes a 2us clock period.
With the emulator configured correctly, the values of time_for_180 and speed are displayed on the screen with the program running in real time. Clearly, with the input values being dependent on real time events, any interference would cause an error in the measure times. By the same token, any corruption of the result by other interrupt routines will now be obvious - the result on the screen will be wrong. Now, with the interrupt rate constant, the output from the calculation will be constant. The calculation can now be checked from the screen values by using a pocket calculator...

Conventionally, this calculation could only be tested statically - influence from other interrupts could only be done by a "what if" exercise on the source listings and logical bugs might ultimately only show up as faulty operation at a port pin.

In addition, being able to see the results of the C calculation change in real time as, in this case, the output of a signal generator is altered, is very reassuring to the programmer.

Having verified the correct operation of the function, it can now be recompiled using the small model. Assuming that the compiler produces functionally identical code regardless of model, the function can be considered debugged.

Another problem which can be partially solved by this method is, for instance, buffering timer values and incoming serial port buffer contents into a visible external RAM location. Thus the mystery of a timer's value on entry to an interrupt routine can now be solved.

Some Points of Limitation

The following points should be noted:

For situations where the emulator supplies the external RAM chip, it should be noted that port 0 and 2 are needed as address and data bus, also #RD and #WR must be reserved. None of them can be used as IO port pins.
If the output data being observed changes too quickly for a satisfactory display on the emulator's host PC screen, it could be channeled into the trace buffer for later examination. Real time operation is again not prejudiced.
There is only one drawback with this method - in very high speed, very time critical systems, the extra runtime caused by using external variables might prevent the required operating speed from being reached. A partial solution to this is to compile using the final SMALL model but force only specific variables into the accessible external RAM by declaring them as XDATA. Here they can be observed for out of range values etc. during real time operation.

Summary

To summarize: with the need to test real time systems in real time to get valid results, program variables will have to be made visible so that they can be checked. Being pragmatic about the side effects of this, unless the silicon manufacturer allows the internal memory/register file to be accessed, there is always going to be some overhead involved in retrieving program data on the fly. However, the method outlined goes as far towards the goal of real time dynamic software testing as is likely to be achieved for 8051 family microcontrollers.

[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]

All materials
provided 'as is'
see Disclaimer