A Very Low Cost 8051 Development Route

In an ideal world, any serious 8051 project would have an in-circuit emulator as the main development tool. Certainly, for high level language software debugging, a state-of-the-art machine like the Hitex MX51 can drastically reduce development time and increase software confidence. Unfortunately, for many small companies or self-employed engineers/consultants, the cost of such a device at £2500-£5000 is prohibitive. Even the rental option at say £120 per week is too expensive and almost certainly represents a loss of funds, unless of course, you are already established and making profits! In this case the Inland Revenue will reduce your taxable profits by the amount paid in rental.....

The problem is compounded for the small designer - to get programming time down, the use of C is a good route. However, with the direct relationship between source line and machine code now muddied by the compiler, the debugging phase is further complicated.

A typical low cost project might proceed thus:

(i) Build a simple board with an 8031, and eprom socket (and possibly a RAM position), a crystal and voltage regulator chip.

(ii) Write some simple code in assembler, just to get the processor running. Maybe just waving a port pin up and down and
observing with a 'scope.

(iii) After editing, compiling and linking, an eprom is blown on a PC driven programmer and fitted to the 8031 board.

(iv) Power is applied to the board and you prod around with a scope, trying to locate the port pin that your program is driving.

(v) If nothing is seen, a little head scratching goes on and maybe the PSU and clock are checked. Finding no hardware problems,
the program code is examined for possible errors. After 20 minutes, the error is located and the compile,link,eprom blow path
is repeated. All this goes on until the port pin is finally toggling.

(vi) After gaining a little confidence, if C is to be used, you now start to write some of the infrastructure of the program. Possibly
the part which initialises the interrupt system or accesses the serial port.

A common route is to use the serial port as a sort of debugging port through which program data is cyclically transmitted to a terminal device.

As the program complexity increases, the possible sources of error also increase. It has to be said, however, that properly used, the compiler can remove many of the normal problems such as data overwrites, handling interrupts etc.

The program flow debugging now becomes a real problem - that is the actual program operation in relation to what was intended. Having no debugging aids, the program can only be tested by running the target at full speed. With such "blind" methods, a huge amount of time can be wasted by blowing eproms with code with very silly errors like greater than signs interchanged, + instead of -, things which would be obvious if you could simply single step the code.

In fact in a trial program development the author observed the following:

Time spent by blowing eproms with essentially typing mistakes:	-  22
Logical errors in program due to poor algorithm or faulty
implementation:										-  32
Program errors due to lack of familiarity with C
(using "=" instead of "==" in if(a==b) statements etc.):		-  12
Existing modules that appeared correct actually being wrong:	-  15
Waiting for eproms to erase (three chips used):				-  10
Time spent fitting and extracting eproms:					-   3
Time spent writing eprom labels:							-   3
Unaccounted time spent compiling and linking:				-   3
Time Spent actually advancing the program development			-  35

	Total Sampled Time									- 135 mins

The smaller items may appear to be slightly frivolous but when actually examined, they are significant!

It is fairly obvious from the above that even a simple debug aid would considerably reduce the first two items, the major sources of wasted effort.

To put this into financial perspective, at a £50/hour charge out rate, approx. £70.00 was wasted in this £112.50 project. Taken over a more realistic 100 hour project, some £3733 would be simply wasted out of total bill of £5000. To be fair, most of the time wasted will actually be concentrated at the beginning of the project when the learning curve is still steep. Even allowing for a 100% error, about £1800 is likely to be lost without trace.....

As a final point, the author is used to working with a top-end in-circuit emulator. As such, returning to the old Eprom method was excruciatingly slow and very disconcerting.

Some engineers have chosen the FORTH approach to speed development. Here, the program is developed and partly debugged on a PC. The program is then downloaded to an 8051 system via a serial link, where is executed. Generally, with FORTH, if it compiles correctly on the PC, it will run in the 8031. However, there are some serious drawbacks:

- the PC code will be 16 bit orientated. The 8031 is strictly 8 bit machine and code produced thus will tend to be inefficient.

- the nature of FORTH is that all the library "WORDS" are present within the 8031 system even at runtime. thus a lot of ROM space is wasted.

- FORTH is rather out of the mainstream and is not a commonplace language.

For C/assembly language projects with a very restricted budget, there is now a workable alternative that at first sight bears some similarity to the FORTH approach. This new low cost route is possible by use of some new tools from Keil and Hitex (UK).

DScope51 is an 8051 cpu simulator, running on a PC. This tool is the programmer's first line of defence against bugs. By loading the absolute 8051 file into DScope rather than blowing an Eprom, the new program can actually be single-stepped and generally examined at close quarters before being run at full speed. The new version 4 gives true C source level debugging and is mouse-driven.

An in-circuit emulator look-a-like user interface is provided which displays the basic 8051 register set, a code disassembly or code+C or C source only. The program can now be single stepped, registers traced and free run.

Breakpoints can be set on data read/write into memory or ports plus opcode fetch. To simulate data on the 8051 ports, watchpoint macros are defined so that when the program accesses a port, the macro inserts a predefined value and the program continues. The results of this new value on program operation can then be observed.

A good example is the simulation of say the A/D converter on the 80C552 - by setting the convert bit a macro is invoked which clears the bit, so allowing the program to continue. Subsequently another macro spots that the AD result register is being accessed and drops a preset AD reading in for the program to pick up. Thus the test program believes it has read a real A/D.

By the use of the simulator, a great many of the basic errors can be spotted immediately. As the edit-compile-link-test cycle time no longer includes an eprom blowing, it is much reduced.

As before, the part debugged code is finally blown into an eprom. However now, the chances of the logic of the program being right is considerably increased!

Unfortunately, the big drawback of the simulator is the lack of real time operation and real peripherals cannot be used. The eprom programming time is still a factor, although not nearly as much as before.

The latter can be eliminated by using an eprom emulator.

Provided that some of the target system's RAM and ROM is unused, a monitor program such as MON51 (also Keil) can be installed in eprom form. This is a traditional monitor which uses a PC as a terminal connected to the serial port, or alternatively, it can talk to a modified version of DScope51 (MonScope51).

With this, the system's registers, data memory and IO ports can be examined and modified; the program single stepped and traced or run in real time with breakpoints set. Finally, new program code can be downloaded from the PC, cutting out the Eprom stage all together.

Thus with this approach using MonScope51, the familiar DScope51 user interface is used but with a real 8051 cpu doing the work in real time.
There are, however, some catches, as with any low cost solution. Firstly, the 8051 serial port becomes tied up by the PC MonScope program and 8K of code and 512bytes of RAM are lost. Also, the 8051 has to be run in single plane mode whereby code and data reside in the same physical device; ie a RAM chip.

The first of the problems can be overcome by using a new chip from Siemens, the 80C537. This expanded chip has two 8051 compatible serial ports in addition to 4 extra IO ports. Thus, to develop basic 8051 cpu programs, the second serial port is reserved for the debugger, leaving the normal one available for the application.

Indeed this chip is used as the basis for a small host board for 8051 development, the MCB517. This carries an 80C537 with 12MHz clock, 32K of RAM and 16K of eprom (holding the monitor) plus two RS232 chips with 9 pin D-type connectors. In addition, a wirewrap area is made available for adding user hardware.

With this hardware, 8051 program development can be started very early on for major projects or used as the basis for an entire 8051 application for smaller undertakings. The RAM size of 32KB does limit the total program code and external data size somewhat.

A further use is as a sort of simple 8051 emulator: if the 80C537's port pins are taken off the MCB517 onto a 40 pin dil connector via some suitable ribbon cable, this can then be fitted to the processor socket in an existing 8051 system. Thus the debugger resides on the MCB517 board and the target simply becomes an IO card, its ROM/RAM unused.

For ROMmed 8051 development, the extra ports 5 and 6 can be used instead of the unavailable dual function ports 0 and 2 - these are used for the address/data bus on the 80C537.

So, by using the simulator, logical errors are removed. In fact the use of this tool alone can be sufficient to get an 8051 project really moving. Downloading to an MCB517 allows the program to be exercised in real hardware so that the use of ports etc. can be checked by single stepping. Finally, the program can be run at full speed in its target environment and if OK an eprom blown.

Although not a perfect debugging system, what has been outlined is an order of magnitude better than working "blind" simply with Eproms. Ultimately, there will probably come a point at which a proper in-circuit emulator is necessary to eliminate certain bugs. If this is the case, such a device can usually be short-term rented until the problem is resolved.