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 ]

• Well known and established architecture
• It's around since more then 15 years
• It will be around for at least another 15 years
• Excellent tools available from Assembler to Compiler to Simulator/Debugger and In-Circuit Emulator
• Assemblers, Compilers and Simulator Debuggers from Keil, Raisonance and others
• A free C compiler version limited to 4k of code is available from Raisonance: www.51xa-tools.com
• Wide variety of In-Circuit Emulators from entry-level to high-end
• Parts available from many different vendors
• 8051 derivatives are manufactured by about 20 different semiconductor companies
• "Standard" 8051 derivatives are pin-compatible in-between different vendors
• Wide variety of derivatives available
• Philips Semiconductors offers the broadest range of 8051 derivatives from very small, affordable 20-pin (or smaller) devices to complex parts with many I/O points and peripheral features
• Upgrade paths available
• Most 8051 chip manufacturers work on "faster" 8051 devices - either by just increasing speed or by decreasing the number of machine cycles required by one instruction cycle (standard is 12)
• Philips Semiconductors announced the 51MX with an extended address range of 8MB
• The Philips XA architecture is a 16-bit upgrade of the 8051. The Raisonance compiler mentioned above, is a compiler for both the 8051 and the Philips XA

Many applications only require a few IO ports and some memory for the program. The code is either stored on-chip in a masked ROM, OTP or Flash - or externally in a Flash or EPROM. The typical application is invariably real-time in nature. This means that software run times are bound by the necessity to process input data derived from real world events - calculations based on values read from on-chip timers is an obvious example; processing data received from a serial port is another.

Generally, devices like the 8051 have an OTP or Flash containing the code and possibly an external RAM, although this is often not the case - frequently, just the 128 or 256 bytes on the internal chip are available. OTP is normally used for cost reasons; masked ROMs are relatively uncommon because of the masking cost and engineers' reluctance to cast their software in concrete! Flash gives the option to change software after release if bugs are discovered or a change in specification is required.

8051's are also commonly used as communications controllers, either via on chip I2C/serial interfaces, CAN or external UART devices. With a fairly decent output compare/input capture system on variants like the 8xC552 and 8xC554, programs are often making timing measurements between events, using, in the case of these devices 16-bit timer 2. Calculations based on the time between captures typically follow in the course of frequency/speed measurements etc..Any impact on the processor operation caused by debugging, for instance, is going to render the results invalid.

With any real time system, whether it is during the development phase when the software is first being coded up, or in any final pre-release software quality assessment phase, the system can only properly be tested dynamically in real time.

Overall, the fact that these systems' inputs are dependent on real world events or real interrupts means that any testing or debugging which prejudices the system behavior must, by definition, invalidate any data. In addition, the loss of real time execution inevitably alters the interaction between say, interrupt and background routines so that critical regions may never be found. This is really all part of the more fundamental debate as to whether static analysis of real time systems is actually a valid thing to do at all. Certainly to date, this has been the conventional approach but recent defense standard requirements for software production do actually require some sort of dynamic testing.

The Increasing Sophistication Of Microcontroller Software

Traditionally, program development in the particular case of the 8051 processor, has been done in assembler and so complicated calculations have tended to be excluded. This is because firstly, the 8051 is not a particularly good number-cruncher, and secondly, the amount of work involved in coding up maths routines in assembler. However, with the increasing use of C, the relatively simple 8051 instruction set becomes rather remote to the programmer and the tendency is to do more complicated things, simply because C makes it so painless to do it. For instance, a 32 by 16 divide in assembler is a very major piece of software, whereas in C it would constitute maybe just one source line.

Naturally, programmers get easily carried away with this and produce more complicated code than before. Most significantly, from the debugging/testing point of view, real time programs can now be viewed as a series of readable C statements, where the logic and function of the program are the main issues, rather than how the instruction set has been coerced into carrying out the program's specification.

Of course, when it comes to testing and debugging, the engineers producing these programs will tend to think only in terms of C statements and real program variables, unlike the assembler programmer, who being so close to the machine, will treat variables as the inhabitants of esoteric and largely anonymous registers.

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

© ESAcademy, 2001

www.esacademy.com
info@esacademy.com