Nach dem ich die Application-Notes von Atmel und Erik Buchmanns Seiten zur 89C2051 Programmierung ausführlich gelesen hatte, machte ich mich daran, einen eigenen Programmer zu entwickeln. Da die 89C5x und 89Cx051 in der Programmierung sehr ähnlich sind, entschied ich mich, die 89Cx051-Typen mit einzubeziehen. Alle hierfür nötigen Signale werden für die 89C5x-Programmierung sowieso erzeugt. Der erste Prototyp (s. Bild) war recht schnell erstellt. Inwischen habe ich noch eine Power- und eine Status-LED hinzugefügt, damit man jederzeit sieht, was der Programmer tut. Die folgenden Wochen habe ich dann erstmal damit verbracht, die Fehler in der Schaltung zu beseitigen.

Aus den Datenblättern von Atmel geht hervor, daß man das ALE-Signal abschalten kann, wenn man keinen externen Programmspeicher benutzt (was bei Flashcontrollern selten vorkommen dürfte). Meine Idee war es nun, ALE abzuschalten, sodaß es nur noch bei MOVX-Befehlen aktiv wird. Das Adressenlowbyte und die Daten sollten mit einem MOVX an Port0 ausgegeben werden. Das Adressbyte sollte dabei von einem Latch aufgefangen werden. Dummerweise stellte sich heraus, das ALE dauerhaft high ist, wenn man es abschaltet. Ein 573-Latch schaltet aber bei High ständig die Eingänge auf die Ausgänge durch. Die Adressinformation geht also beim nächsten Befehlszyklus verloren. Für die Programmierung eines zweiten Controllers müßte es aber mehrere Millisekunden anliegen.

Um dieses Problem in den Griff zu bekommen, habe ich den 573 gegen einen 574 ersetzt, der die Daten bei steigender Flanke übernimmt. Man gibt nun also mit MOVX eine beliebige Adresse und als 'Daten' das Adresslowbyte aus, welches beim Ansteigen von WR auf high zwischengespeichert wird. Anschließend gibt man die eigentlichen Daten für die Programmierung auf P0 aus.

Ein zweiter, auswärts geflashter Controller funktionierte dann tatsächlich. Ich mußte 'nur' noch eine Platine für das 'Zielsystem' fräsen, und konnte dann das erste Programm selber flashen. Leider war zu dieser Zeit noch keine Verify-Funktion integriert, so daß man nicht mit Sicherheit sagen konnte, ob alles richtig programmiert worden ist :^(

Inzwischen sind die Arbeiten an der Hardware und erste Tests abgeschlossen, so daß ich die Sourcen zum Download freigeben kann. Vergeßt aber bitte nicht, das der Programmer noch in der Erprobungsphase ist! Die grundlegenden Funktionen sind kompatibel zu Erik Buchmanns 89C2051-Programmern, so daß man seine Software für die Datenübertragung benutzen kann.

Bit-Nr.	Aktion
0	nicht verwendet
1	löschen
2	schreiben
3	verify
4	leertest
5	test1: Gibt empfangenes Byte an P2 aus.
6	test2: Gibt empfangenes Byte an P0 aus.
7	Übertragungstest. Sendet die Zahlen 1-255. Wenn alles richtig empfangen wurde, geht die LED am AT89 an.
5+6+7	Alle Lockbits schreiben

Das 'Format', in dem die PC-Software mit dem AT89-Programmer kommuniziert, ist ganz simpel. Die Daten werden seriell mit 1200 Baud übertragen (1 Start-, 8 Daten- und ein Stopbit, keine Paritätsprüfung). Zuerst werden die beiden Hex-Bytes 'EB' '98' gesendet, um die Übertragung zu beginnnen. Es folgt das Aktionsbyte, in dem die auszuführenden Schritte kodiert sind. Anschließend werden die Datenbytes nacheinander gesendet. Wenn keine Bytes mehr empfangen werden (nach ca. 100ms), wird die Aktion abgeschlossen. Die Bits des Aktionsbytes sind wie nebenstehend definiert.

Das Ganze kann man im Prinzip auch beliebig kombinieren. Das Beschreiben der Lockbits ist in der Firmware bisher nicht enthalten; die Leertest-Funktion prüft nur das erste KB, da ja Bausteine mit verschieden großen Flash-ROMs beschrieben werden können. Die Rückmeldung über Erfolg bzw. Mißerfolg einer Aktion erfolgt nur über die LED am Programmer. Um die Bedienung diesbezüglich zu vereinfachen, und um auch Bausteine wieder auslesen zu können habe ich einige Erweiterungen eingebaut.

Sendet man zu Beginn statt 'EB98' 'AC99', liefert der Programmer die Signature-Bytes des Zielcontrollers zurück. Die PC-Software kann hieraus die Speichergröße des Bausteins ermitteln. Nun wird die Speichergröße gesendet (2 Bytes), so daß z.B. ein Leertest auch wirklich den ganzen Chip testen kann. Anschließend wird das Aktionsbyte übertragen. Hierfür ergibt sich eine z.T. abweichende Belegung: Bit0 muß immer gesetzt werden, Bit5 aktiviert eine Funktion zum Auslesen (auch hierfür ist die Speichergröße von Bedeutung), die Bits 6 und 7 aktivieren die Lockbits 1 bzw. 2; sind beide gesetzt, wird das dritte Lockbit geflasht. Die Lockbitfunktionen sind noch nicht implementiert. Im erweiterten Format sollten die Befehle nicht mehr kombiniert werden. Statt dessen kann man mehrere Aktionen nacheinander ausführen. Erst, wenn keine Befehle mehr empfangen werden, geht der Proggi wieder in den Standby-Modus. Wenn ein Befehl erfolgreich ausgeführt wurde, sendet der AT89 ihn zur Bestätigung zurück. Falls etwas schiefgegangen ist, gibt er stattdessen ein Fehlerbyte zurück (01h = timeout, 02h = Chip nicht leer, 03h = Schreibfehler). Diese erweiterten Funktionen sind in der Firmware bereits enthalten. Erste Tests haben keine Fehler ans Licht gebracht. Nutzbar wird das Ganze natürlich erst mit dem entsprechenden Programm für den PC. Ich wollte hierfü eine eigene Übertragungssoftware schreiben, die dann auch die weitere Funktionen unterstützen soll. Da ich für mein aktuelles Mikrocontroller-Projekt die 89C's doch nicht verwende, wird das wohl noch eine Weile auf sich warten lassen...

Der Programmer ist als In-System-Programmer ausgelegt, das heißt, bei entsprechendem Schaltungsdesign kann ein Baustein programmiert werden, ohne daß er aus der Schaltung entnommen wird. Hierfür müssen natürlich die Pins, die für die Programmierung benötigt werden, über einen 40poligen Pfostenstecker zugänglich sein. Außerdem muß man dafür sorgen, das die Schaltung und der Programmer sich nicht gegenseitig stören. Wenn der Programmer nichts tut, sind alle Ausgänge über die internen Pullups auf Highpegel, und können von der Anwendung 'überschrieben' werden. Einige Signale, vor allem der Pin, der am 89C2051 mit dem Oszillatorkreis verbunden ist, sind über ein Latch getrennt, welches in den Tristate geschaltet wird. Genauso dürfen die Elemente der Anwendungs-Schaltung den Programmiervorgang nicht stören. Was hierbei zu beachten ist, ist in den Application-Notes von Atmel erklärt. Die Programmierung eines 89C2051 klappt leider noch nicht, wie ich kürzlich feststellen mußte. Scheinbar verbirgt sich in der Programmierroutine noch ein Timing(?)-Fehler...

Wem das für den Hausgebrauch zu kompliziert ist, aber trotzdem nicht immer den Chip aus dem Sockel ziehen will, kann natürlich auch folgendes machen: Man benutzt eine Basis-Platine, die den benötigten Pfostenstecker, einen Resettaster und den Quarz beherbergt. Das ist schon ein komplettes Minimalsystem. Die Verbindungen zur 'Außenwelt' stellt man über den Pfostenstecker her, und wenn der Chip neu programmiert werden soll, steckt man einfach das Kabel um. Bleibt nur noch die Frage, warum man ein Programmiergerät baut, für das man erstmal einen programmierten Chip benötigt (die klassische 'Henne-Ei-Frage'). Naja, einen einzelnen Chip kann man auch mal im Elektroladen nebenan oder bei einem Kollegen brennen lassen (was auf Dauer wohl zu lästig und/oder zu teuer wäre). Dafür braucht man sich aber nicht mit Timing-Fragen bei der PC-Programmierung beschäftigen.