Das FBK-Projekt: Robotics

FBK ist der Förderverein für besonders begabte Kinder im Kanton Bern. Auf privater Basis bietet der FBK ab Frühjahr dieses Jahres (2005) Kurse an für besonders begabte Schüler (in der Regel 1.-6.Klasse). Das Vorgehen orientiert sich am beendeten, kantonalbernischen Schulversuch I: anstelle des Regelunterrichtes besuchen die Schüler einen Vormittag lang den Sonderunterricht. Ihre Begabung wird vorher professionell getestet. Ich gebe dort unter dem Motto 'Robotics' einen Kurs, in dem Schüler der 4.-6.Klasse kleine Kontroller-Platinen zusammenlöten, die sie dann über Laptop/PC programmieren können. Ich habe ab Spätsommer 2000 im kantonalbernischen Schulversuch I insgesamt 4 Semester unterrichtet, ein weiterse dann im Schulversuch II (Brunnmattschulhaus, Bern). Drei der Kurse waren unter dem Titel 'Bit & Byte' demselben Robotics-Thema gewidmet -allerdings wurde da mit fertig bestückten Platinen gearbeit -diese stammten vom Schrott (also mal von Autelca/Gümligen) und haben ursprünglich in den öffentlichen Telefonkabinen die Münz- Gesprächs-& Verbindungskontrolle gesteuert. Nach etwas Umbau, Anbringen einer kleinen Tastatur (16 Tasten) sowie einem LCD-Display (2 x 16 Zeichen) und mit Bestückung eines batteriegestützten 8K-NV-Rams konnten die Platinen über den Parallelport eines PC's programmiert werden. Nun, die Platinen sind an sich super: 8085 mit 32K ROM/RAM, UART, ca. 60 (!) gepufferte Aus- & Eingänge und mehr. Brauchen aber im Ruhezustand bereits ca. 3 Watt und sind in allen Ehren halt doch etwas obsolet. Obwohl - ein 8085 war meines Wissens auch massgebend im Rover beteiligt, dem Fahrzeug, das vielleicht noch jetzt auf dem Mars umherkraxelt.

Der aktuelle Ersatz ist eine kleine, selbst entworfen und verarbeitete Platine (siehe Printherstellung) mit einem Microcontroller der 8051-er Familie: AT89S52 (zugegebenermassen etwa gleichermassen obsolet) aber dennoch: Ruheleistungsverbrauch etwa 30 mal weniger. ROM: 8k flash, ISP. RAM: unsägliche 256 Bytes (wovon nur etwa die Hälfte frei nutzbar) und siehe da: es reicht zumeist. UART (19'200 Baud), 3 Timer, etwa 6 Interrupts usf. Zusätzlich auf der Platine: I2C-Bus zu 8K serial EEROM für Daten sowie Batteriegepufferter Uhr/Kalender mit auch noch etwas Speicher. LCD-Display mit 2 Zeilen à 24 Zeichen. 8 Ausgänge, die bis 500 mA Strom aushalten und 8 Eingänge (auch als Ausgänge nutzbar). Dazu sind noch 2 Interrupteingänge frei sowie ein programmierbarer Taktausgang. Auchder Sklave ist noch als Wachhund oder Coprozessor ausbaubar. Die Struktur sollte jedenfalls für kleine Steueraufgaben eigentlich sehr wohl ausreichen und hat sich bereits bei vielen Anwendungen bestens bewährt. Die Platine hat einen Spannungsregler und kann mit 7 - 15 Volt betrieben werden. Sie kann aber auch ohne Spannungsregler ab Batterie betireben werden und dann reichen so 4.5 Volt.

Eine Bemerkung sei noch erlaubt und schreckt hoffentlich niemanden davon ab, weiterzulesen: das ganze System läuft unter DOS (oder auch im DOS-fenster einer Windows-98SE-Version oder tiefer - hier kommt es etwas auf das Terminalprogramm an, das man benutzt - das schlanke freeware-programm UniCom funzt bestens). Mit Win NT/2000/xp ist rein nichts zu machen (und leider auch nichts mit Linux / MacOS u.a.) - zumindest nicht von meiner Seite her. Der Grund hierzu ist, dass die Hilfsprogramme auf dem PC, welche den Master programmieren und auf das serielle EEROM zugreifen können, in purem x86-Assembler geschrieben sind (!) und direkt auf die Register des UART-Chips im PC zugreifen. Davon will halt Win NT/2000/XP rein gar nichts mehr wissen und auch Linux findet das eine intolerable Frechheit, so ganz ohne zu Fragen einfach die Hardware anzusprechen... Aber warum in aller Welt schreibe ich denn überhaupt in Assembler ?? weil ich seit 1980 in Assembler programmiere und im Laufe der Zeit viele Programmfragmente für viele Aufgaben habe, die sehr schnell miteinander kombiniert und ergänzt werden können. Das gibt dann auch superschnelle und superkleine Programme und man weiss sehr genau, was man macht. Ich schreibe eigentlich seit jeher nur Programme, die auch direkt auf die Hardware zugreifen, denn nur so kann man über den Druckerport den Drehbank steuern, über die serielle Schnittstelle die Pflanzen giessen und über den Joystickanschluss die Fische und die Katze füttern. Cplusplus und Java in allen Ehren (über Pascal resp. Delphi schweige ich mich lieber aus), aber für genau diese Anwendungen sind auch Hochsprachen sehr ungeeignet. Bei Ihnen geht es ja um eine maximale Portabilität und genau das steht in krassem Widerspruch zur lokalen Hardware - deshalb wird dieses Problem mehr oder weniger elegant umschifft, indem man diese Sequenzen dann trotzdem in Assembler einflechten muss - und dann ist man gleichweit und die Portabilität ist genauso futsch. Zudem ist DOS ein durchaus brauchbares System und verfügt innerhalb über recht mächtige Software-interrupts, die einem das Assembler-programmieren sehr erleichtern. Genau für solche Projekte wie hier jedenfalls ist DOS hervorragend geeignet. Man kriegt nämlich noch relativ schnell mal einen kleinen, alten Laptop, der mit seinem 486er oder höher und vielleicht 4M Speicher scheinbar ausgedient hat - hier findet er ausgezeichnet Verwendung. Alles Andere ist eh der totale Overkill und quasi mit Atombomben auf Bazillen geschossen. Aber Bitte, wer gerne in Hochsprachen programmiert, kann sich unter Linux, XP oder was auch immer selbst ein einfaches Programm erstellen: alles, was es können muss, ist die serielle Schnittstelle konfigurieren und darüber Daten ausgeben und einlesen. Die Datenflusskontrolle wird einzig von der 8051-Platine her gesteuert und das nur über die CTS-Leitung. Im weiteren braucht es nur eine 3-buchstabige Befehls-sequenz in ASCII und danach die entsprechenden Programm-Daten im IntelHex-Forma, schön portionenweise. Die Daten werden verifiziert. Details stehen gerne zur Verfügung. Eine andere & m.E. bessere Möglichkeit wäre dann noch, den Sklaven so zu programmieren, dass er mit einem standardisierten Protokoll wie Xmodem umgehen könnte. Dann wäre das Ding wirklich Plattformunabhängig!
Beim Einschalten testet der Sklave zuerst, ob überhaupt ein Master vorhanden und ob dieser ev. gelöscht sei. Falls OK meldet er den Status der lock-bits und übergibt dem Master die Kontrolle. Dieser meldet sich auch sogleich mit der aktuellen Zeit, führt sein eigentliches Programm aus und kann jetzt (interruptgesteuert) Befehle entgegennehmen oder Statusmeldungen ausgeben. Natürlich funktioniert die Platine auch völlig autonom und ist eigentlich so gedacht - die Verbindung zum PC ist lediglich in der Entwicklungsphase äusserst hilfreich - vor allem beim debuggen!.
Und etwa so sieht das dann am Bildschirm aus (hier unter UniCom):

Doch nun mal das Block-Schaltbild der Platine:

Das System wurde speziell für Entwicklungs- & Experimentieranwendungen entworfen und ist daher für besonders leichte Handhabung ausgelegt. ISP (in system programmable) tönt ja immer echt gut, hat aber genau betrachtet ein paar tüchtige Haken: Es braucht min.5 Leitungen, die zumeist nicht länger als 20 cm sein dürfen. Die beteiligten Anschlüsse MOSI, MISO und SCLK gehen quasi verloren (oder sind höchstens noch als unschuldige Eingänge einsetzbar). Während der gesamten Programmierdauer (10 - 20 Sekunden) ist der Kontroller im Reset-Zustand, d.h. alle Ports sind 'H' - dies ist bei den beteiligten Bauteilen zu berücksichtigen (sonst spielt nämlich der angeschlossene Kran während der Neuprogrammierung verrückt...)! Eine oft benutzte Verbindung zum Programmiercomputer ist dabei meist der Parallelanschlusss. So braucht man denn einen 25pol-D-sub-Stecker mit entsprechendem Kabel. Und dies zusätzlich zur eh geplanten RS232-Verbindung (schliesslich will man ja kommunizieren) -> alles mühsam & umständlich. Sicher: mit ein paar Nachteilen muss man immer leben (z. Bsp. mit dem Resetzustand während der Programmierung), anderes hingegen kann man eleganter lösen: so kam die Idee, den Microcontroller doch auch gerade über dieselbe serielle Verbindung zu Programmieren. Leider geht das nicht ganz auf Anhieb (falsche Pegel, zuwenig Leitungen, mangelnde zeitliche Kontrolle usf.), also, es braucht dazu einen Sklaven: ein weiterer Kontroller derselben Familie (AT89C4051) auf derselben Platine übernimmt nun die Programmierung des Meisters AT89S52 ! (Und dies ist umso erfreulicher, da der hochkomplexe Chip tatsächlich billiger ist als das blöde, mechanische Teil von D-sub Stecker allein - über Entwicklungsarbeit reden wir ja jetzt eh nicht eigentlich). Beide Prozessoren benutzen also ein und dieselben Kommunikationsleitungen. Erhält der Meister-Prozessor den Befehl zur Neuprogrammierung (über serielle Kommunikation oder über manuellen Taster), so übergibt er im geeigneten Moment die Steuerung dem Sklaven-Prozessor. Alle weiteren Daten auf der Leitung dienen nun der Neuprogrammierung des Meisters. Ist dies vollendet, so übernimmt der Meister wieder die Kontrolle und der arme Sklave hat nichts anderes zu tun, als alle Kommunikationsdaten weiterzuleiten und auf einen weiteren Programmiereinsatz zu warten.... Der Programmiervorgang dauert (bei 19'200 baud) so um die 10 - 20 Sekunden und laut ATMEL kann der Flash-Speicher min. 1'000 mal überschrieben werden.

Auf gleichem seriellen Weg kann so auch der Inhalt des 8K - I2C - SEEROM beschrieben oder ausgelesen werden - diese Arbeit übernimmt nun aber der Meister selbst... Da nun einerseits die serielle Verbindung relativ schnell, die Flash-Programmierung hingegen relativ langsam ist und kaum nennenswerter Pufferspeicher zur Verfügung steht, ist ein hardware-handshake unerlässlich. Dieses wird wie gewohnt mit RTS/CTS realisiert. Nun, 'wie gewoht' ist etwas hoch gegriffen, die RTS-Leitung vom PC zur S52-Platine ist zwar verdrahtet (und über diese Leitung würde eine Sendewunsch angemeldet - (RTS = request to send), wird aber softwaremässig noch nicht benutzt. Der Datenfluss kann völlig ausreichend gesteuert werden mit dem CTS-signal allein (CTS = clear to send). Damit signalisieren Sklave oder Meister ihre Empfangsbereitschaft für neue Daten und der PC muss gegebenenfalls entsprechend warten mit der Datenübertragung. Konkret sieht das so aus:

Nun also noch zur Resetschaltung: Der Sklave wird über einen üblichen Resettaster zurückgesetzt. Dabei löst er über eine Portleitung auch ein Reset des Meisters aus. Während dessen Reset sind alle seine Portleitungen brav logisch 'H'. Leider würde das aber nun für das angeschlossenes LCD-Display bedeuten, dass der Prozessor von ihm Daten lesen will und es wird ebenso brav etliche, meist unvorhersehbare Datenleitungen auf logisch 'L' ziehen. Da zusätzlich das Speichersignal des Portspeichers x573 auch logisch 'H' ist, wird er (da jetzt transparent) diese undefinierten Signale sogleich an die an den Ports angeschlossene Elektronik weitergeben und das selbstzerstörerische Desaster kann seinen freien Lauf nehmen... Wäre dieser Zustand nur während der wenigen Millisekunden eines normalen Resets vorhanden und würden dann als Erstes alle Portleitungen ordnungsgemäss initialisiert, so wäre das weiter nicht schlimm -der Resetzustand herrscht aber während der gesamten Dauer der ISP-Programmierung und in einer halben Minute kann etliches geschehen! Deshalb wird hier das Enable-signal des LCD-Displays invertiert. So wird es während der Resetphase nicht angesprochen und alle Portleitungen sind definiert 'H', dementsprechend alle Pegel an den ULN2803-Ausgängen 'L'. Danach hat sich die angeschlossene Elektronik zu richten - nämlich dass bei diesen Pegeln nichts Unvorgesehenes abgeht....!

Die Softwareumgebung:

Ich schreibe in Assembler. Hierzu benutze ich irgend ein praktisches Textverarbeitungsprogramm (das natürlich keine Textformatierungen abspeichern darf) und den bewährten Freeware- asem-51 Macroassembler. Dieser erzeugt Intel-Hex-dateien, die dann sogleich mit dem selbstgeschriebenen DOS-Programm dem Sklaven zur Programmierung des Masters gesendet werden Für den ja immer wieder zu wiederholenden Ablauf : korrigieren - assemblieren - programmieren gibt's natürlich ein batch-file. Falls man auf einem reinen DOS-rechner arbeitet, so empfehle ich den DosNavigator als perfekten Freeware-Ersatz für den doch sehr praktischen Norton Commander - da ist sogar ein fixfertiges Terminalprogramm dabei! Ansonsten, wenn man am selben Projekt mal rein unter DOS, mal unter Windows schreibt (etwa mit Ultraedit und das Assemblieren & Senden in DOS-Fenstern vollzieht), muss man achtgeben, dass sich die Unterschiedlichen Zeichensätze von Windows (ANSI) und DOS (OEM) nicht vermischen. Das gibt sonst Ärger mit den Umlauten und anderen Zeichen.

Wer an diesem Projekt interessiert ist, kann mir ein email schicken und kriegt die entsprechenden Programme incl. Sourcecode. Es gibt auch ein detailliertes Schema und ein Platinenlayout für einseitige Platinen, die man recht einfach selbst herstellen kann. Selbstverständlich sind auch gute Ideen willkommen...