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 ]
The Link Between Hardware And Coding Approach
With applications coded in assembler, the memory model that is used is really very much embedded into the software and reflects fully the physical memory configuration of the hardware. For instance, if the programmer is going to use an external RAM chip, a conscious effort must be made to use MOVX @DPTR instructions when moving data around. If the program is written using solely the internal memory, to convert it to use external RAM (should more space be required) would be a very major undertaking - all the move indirect/direct instructions would have to be converted to include the loading of DPTR and the use of MOVX @DPTR.
Such an exercise is almost impossible given a program of any size, or at the very least extremely laborious. Really in this sense, the software is as rigid and inflexible as the hardware design. If the software is designed to use only internal RAM, it is almost as difficult to convert it to use external RAM as it is to change the PCB design to add the RAM chip to the hardware in the first place.
Coding For A Variety Of Memory Models
A new possibility has been opened up in this area for engineers using C compilers such as the ones from Keil or Raisonance. These compilers will support many different memory models - the memory model being determined by just a software switch at the compilation stage. It now becomes extremely simple to change the memory model assumed by the software during development. The memory model used is no longer implicit in the nature of the program instructions used by the programmer.
An example of how this memory model switch works is as follows: if the SMALL model is selected, the compiler will assume that no external RAM exists and all function parameters, variables etc. will be located within the internal directly or indirectly addressable RAM segments of the microcontroller's memory. The large model, if selected as a global model, will cause all variables and parameter passing areas to be forced into external RAM, where they will be addressed by the MOVX @DPTR instruction.
The stack, as has to be the case with the 8051, always remains in internal memory. Typically in expanded 8051 systems, the external RAM will be used for parameter passing and variables, constituting the LARGE model for the C compiler. The stack now has a free run of the internal memory. There is, unfortunately, a penalty in going to the large model, as within the basic 8031 there is only one DPTR that can be used for moving data in and out of external memory devices, so any addressing of an external variable will require the loading of the DPTR and then the moving of the data to the target location, via the accumulator. There is a COMPACT model which will actually allow paged memory to be used. This is actually slightly better in that external memory movements are made with respect to one of the eight general purpose R0 - R7 registers. This, in actual fact, does not require the constant loading and unloading of the DPTR and so probably represents the best way of using external RAM.
Variable Characteristics In Assembler And C Programs
The upshot of all this is that a program which is initially written for the SMALL memory model can at the flick of a software switch be recompiled to produce a totally different set of 8051 instructions that can now make use of external RAM. This, as has been said, has not been possible with assembler - assembler programs carry their memory model with them at all times and it cannot change. With the C compiler route, the memory model may be changed at will. This ease of conversion opens up an interesting new debugging/ testing possibility that has been well explored by the authors.
[ Introduction | Testing Methods | Memory Models | Testing LARGE | Example ]
© ESAcademy, 2001
All materials
provided 'as is'
see Disclaimer