Creat: An Embedded Systems Project
Having produced a requirements spec, it was quite obvious I would not have time to write all of the necessary code and design the hardware from scratch. The normal scenario would be to obtain a loan (or course development grant), hire staff and have them reinvent the wheel by building yet-another-microcontroller-kit, then persuade the University to try and market it. Of course, this would have produced all the usual arguments against releasing the software source, and the cost would not be much less than $100,000 US by the time everything had been shaken down, even for a simple system. The openness of the project would be compromised; distribution, maintenance and servicing issues would arise.
Fortunately, as a long-time Linux user in an EE department, I had already come across Thomas Nau's PCB program. (Source code is available from ftp://ftp.uni-ulmde/pub/pcb/, also available as a Red Hat RPM or as a Debian package. See the README file for more details.)
PCB is a drawing package, with many useful debugging aids including net list import and export, but no auto route or schematic capture capability. It is ideal for students intricately hand-drafting a single-sided PCB—a skill not yet superseded by at least the majority of commercial packages. Maintenance of the package has been taken over by Harry Eaton, who looks after such features as Gerber output (the file format popular amongst PCB manufacturers). Figure 1 shows this program in action displaying part of the Creat CPU board. The really good thing about PCB is that it comes with a microcontroller circuit layout as a demonstration file. This is one of Thomas's projects, and I couldn't believe my luck, because it had all the attributes I needed for Creat. In fact, because Thomas's board was a full-blown stand-alone application, it was rather too complex for the tasks we needed, so I set about hacking it down to size.
The second stroke of luck came when I received an e-mail from Jerome Debard, a graduate of Toulouse. His degree was in Engineering, he wanted to gain some work experience and language skills by working in England, and was prepared to do so for free! He took the idea of reducing Thomas's board, and in a few weeks of frenzied activity, got it working, including writing a run-time library for it. (He also did the cooking at the Annual Communications Group Rooftop Barbecue, which is the first time that occasion has ever benefitted from having a French chef.)
Aside from getting the circuit mis au point, the hardware was basically wrapped up. Figure 2 shows the bare board after commercial manufacture: its actual size is about 3.5 inches square with all the components added. To make the board work, you have to solder up the components labeled in plain text. If you want it to work without a regulated bench supply, you will need the components labeled in parentheses too. This gives you a microcontroller module with 2KB of EEPROM, 256KB of RAM, 28 digital and 8 analogue I/O lines. This is useful for some projects, but not really enough for C. Adding the components labeled in italics gives you up to 128KB of RAM, but leaves only five I/O lines. Fortunately, Motorola makes a rather useful PRU (port replacement unit) which can be hung on the address and data bus, transparently giving you these lines back. Figure 3 shows the memory map of the system with 128KB fitted. (Motorola, Inc. produces a comprehensive reference manual for this processor family, ref. no. MC68HC11RM/AD REV 3: Motorola Literature Distribution, P.O. Box 5405, Denver, Colorado 80217
With essentially reliable hardware, the work now begins on a development system and first of all on the C compiler. Back to the Internet and to the aforementioned Donald Jeff Dionne, in whose public FTP space I found a binary distribution of exactly the compiler I needed. Based on the gcc port by Coactive (http://www.coactive.com/), it was ideal. A common source-code base could be built to run on the Linux boxes and then cross-compiled for the Creat board. The binary was in the old a.out format, and I e-mailed Jeff to find out whether it had been developed.
gcc-hc11 was the C compiler Jerome had looked at, then rushed out a run-time library including memory allocation and rudimentary string I/O routines. At the time, there were two European Community exchange students from Valencia in the department, so based on the availability of a working gcc, we started to cook up something which would be useful and free.
It is often efficient to divide a microcontroller-based project into two, testing the hardware and software independently before using them together. Of course, it is important for the two tasks to advise each other, but if the project is large, it is almost certain a hardware group will be working on the project concurrently with a software group. Creat seeks to make that process as easy as possible through a strict process of hardware abstraction. When somebody builds a piece of hardware which might be of general use, they make a package of it. A package consists of three things: a PCB layout in pcb format with the same form factor as the main CPU board, a set of subroutines (which might be written in C or assembler) with a specific C-language interface, and another set of C subroutines taking the same arguments which compile and run on the workstation.
The key idea is that any program which uses a particular piece of hardware, e.g., a dot-matrix LCD display, can be written using the Creat LCD device interface. This provides two main calls: an initialisation call invoked before the device can be used and another to write a character on the LCD. Creat's make system can be used to build the application for the Linux box by issuing the commands:
make depend; make wkstn
After testing, code can be compiled for the 6811 as well using:
make 6811; make boot