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 ]
Pseudo-Static Testing Methods
Sub-routines or even small functional blocks such as a calculation are commonly tested statically; the program may be run to the beginning of the calculation, some input values loaded up, and the program released to run in real time. At the end of the section to be tested, execution is broken and the result(s) extracted and checked for correctness.
This is a perfectly valid method, provided that the input values are totally independent of real world events or time, and that program operation could not possibly be upset by interrupts. Another extension to this problem is that once the program or software is working to a reasonable standard, often the programmer needs to get a feel for what the thing actually does - in simple terms, play around with the software's inputs while the program is running. This often reveals unexpected operation when say an input goes to full scale. Again conventionally, because of the way in which the 8051 and probably most other microcontrollers are constructed, the contents of any RAM locations/variables are totally invisible during program execution. While they can be made visible with some advanced development systems by setting breakpoints on write accesses to certain variables and looking at the data, real time operation is inevitably lost in the very act of extracting the data. Even if the emulator can carry on automatically after the breakpoint, at least several hundred microseconds are lost while the emulator actually retrieves the value.
Many simpler emulators will not even do this basic task. For much of the time with this sort of software development, the programmer has to simply keep going through the listings, doing a "what if" exercise on every variable, possibly extending to a '"what if" variable = such and such, and interrupt occurs at a certain point' etc. All the potential permutations of variable values, program paths and interrupt times makes the testing of this sort of real time software almost impossible.
[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]
© ESAcademy, 2001
All materials
provided 'as is'
see Disclaimer