ftCommunity | Wiki | Programmieren des Robo-Interface in C
Wiki
Thema: Programmieren des Robo-Interface in C
Version 1
von: thkais
am: 07.04.2006, 13:33:23 Uhr
Programmieren des Robo-Interface in C
Vorwort
Obwohl die von ft angebotene grafische Programmierumgebung RoboPro durchaus ihren Reiz hat (ich selbst bin nach
anfänglicher Skepsis inzwischen total begeistert davon) gibt es einige Projekte, die die Möglichkeiten von
RoboPro sprengen. Obwohl man diese Aussage relativ sehen muss, denn es ist sogar gelungen, einen "Rubiks Cube"
(Zauberwürfel) mit RoboPro zu lösen - und das ohne PC-Unterstützung im Stand-alone Betrieb.
Wenn man einen Microcontroller (µC) direkt in C programmieren will, muss man sich zunächst über einiges im
Klaren sein: Die Programmierung eines µC unterscheidet sich in vielen Dingen von der Programmierung eines PC.
Zwar können viele Algorithmen übernommen werden, aber der wichtigste Teil eines Interface, nämlich die
Hardware, unterscheidet sich ganz gewaltig. Ausserdem ist das Betriebssystem nicht so absturzsicher, wie das
eines PC.
Ferner gibt es auch Unterschiede zwischen verschiedenen Systemen. Ich möchte hier das weit verbreitete RCX in
Verbindung mit NQC ("Not Quite C") als Vergleich heranziehen. Der größte Unterschied zwischen dem Robo-
Interface und dem RCX besteht darin, dass im Robo-Interface grundsätzlich echter Maschinencode ausgeführt wird
(auch in Verbindung mit RoboPro), während das RCX von Haus aus einen Bytecode ausführt (dies lässt sich mit
anderen Betriebssystemen ändern, allerdings funktioniert dann kein NQC mehr). Dies hat Vor- und Nachteile: Der
Vorteil eines Bytecode-Interpreters ist die Absturzsicherheit, denn der Interpreter überprüft die Plausibilität
von Daten und kann im Notfall korrigierend eingreifen. Der Nachteil: Nur die Funktionen, die in diesem Bytecode
integriert sind, können auch verwendet werden. Dies ist z.B. der Grund, weshalb mit NQC keine
Gleitkommaarithmetik möglich ist. Beim RoboInterface ist dies prinzipiell vom Compiler abhängig, der von ft
unterstützte originale Renesas-Compiler vom Hersteller des im Robo-Interface eingebauten µC ist in der Lage,
Gleitkommaartihmetik zu unterstützen. Ich möchte aber auch nicht den großen Nachteil verschweigen: Dadurch,
dass "echter" Maschinencode ausgeführt wird, können Programmfehler wesentlich dramatischere Auswirkungen haben,
als bei einem Bytecode-Interpreter. Es gibt für das Betriebssystem nur begrenzte Möglichkeiten, hier
einzugreifen.
Aber was heisst eigentlich "Betriebssystem" bei einem µC? Wer sich mit µC auch abseits vom Robo-Interface
beschäftigt, wird sehen, dass üblicherweise kein Betriebssystem in dem Sinne vorhanden ist, wie man es von
einem PC kennt. Eigentlich schreibt man sich das selbst - denn es entspricht dem Anwenderprogramm.
Beim Robo-Interface ist das Betriebssystem eigentlich nur eine Art Bibliothek, die die Verbindung zur Hardware
vereinfacht. So werden die Schnittstellen initialisiert, Timer zur Verfügung gestellt etc., aber mehr auch
nicht. Sobald ein Anwenderprogramm die Kontrolle übernommen hat, ist es verantwortlich für den richtigen Umgang
mit der Hardware.
Deshalb möchte ich auch nochmal die Warnung des Robo-Interface Entwicklers verdeutlichen:
Ein Fehler im Programm kann im ungünstigsten Fall einen Hardwaredefekt hervorrufen. Im günstigsten Fall hängt
sich das Interface einfach nur auf. Fehlermeldungen werden nicht ausgegeben - wo denn auch?
Dies liegt vor allem an den Unzulänglichkeiten von C. Das, was C so schnell macht, ist gleichzeitig das größte
Problem: Es gibt keinerlei Kontrollmechanismen. Variablen mit unterschiedlichen Datentypen können bunt gemischt
werden, mit ungewissem Ausgang, bei Arrays kann ohne weiteres der Index überschritten werden, so dass andere
Variablen oder wichtige Datenbereiche überschrieben werden. Über die Gefahren von Pointern garnicht zu reden.
Also: Wer das Robo-Interface direkt in C programmieren möchte, sollte genau wissen, was er tut. Vor allem
sollte er wissen, was ein C-Compiler mit dem Code macht und notfalls auch mal etwas Assembler-Kenntnisse
mitbringen, um den generierten Code zu überprüfen oder in einem Simulator laufen zu lassen.
Zum Erlernen der Programmiersprache C ist das Robo-Interface definitiv nicht zu empfehlen. Auch Umsteiger von
NQC sollten sich darüber im Klaren sein, dass NQC nur eine Teilmenge von C darstellt und bei weitem nicht so
fehleranfällig ist.
Und zum Schluß noch etwas in eigener Sache:
Die hier von mir vorgestellten Programme wurden getestet und so weit als möglich überprüft. Dennoch muss ich
jegliche Schadenersatzansprüche ablehnen - jeder muss selbst wissen, was er tut. Dies ist definitiv keine
Anleitung für Anfänger in der C-Programmierung.
Wer die Programmierung eines µC in C erlernen will, dem möchte ich eine andere Vorgehensweise empfehlen:
Zunächst C lernen. Es gibt einen kostenlosen C-Compiler von Borland für DOS. Das reicht vollkommen, denn
Windows-Anwendungen laufen auf einem µC sowieso nicht ;).
Dann das Programmieren von einem Atmel-µC. Der kostet ca. 2-5 Euro, ein Programmiergerät nochmal 5 Euro und die
restliche Software (programmiersoftware und C-Compiler) ist ebenfalls kostenlos erhältlich. Auch bei diesen µC
wird man zum fehlerfreien Programmieren "erzogen". Entweder das Programm funktioniert - oder nicht. Wenn
wirklich etwas schief geht, sind die Verluste auch eher zu verschmerzen als die Reparatur am Robo-Interface...
Noch ein Wort zu C++: Die meisten Compiler für µC unterstützen kein C++, da der Funktionsumfang von ANSI-C zur
Programmierung eines µC im allgemeinen vollkommen ausreicht.
Wie beginne ich?
Die vom Entwickler des Robo-Interface mitgelieferte Anleitung zur Installation des Compilers, compilieren
vorhandener Projekte und anlegen neuer Projekte ist vorbildlich. Deshalb werde ich dies auch garnicht weiter
ausführen.
Nur ein paar Tipps zur Einrichtung des Renesas-Compilers:
Wer nicht unbedingt die Projekte auf C:\Workspace speichern will, kann unter Setup -> Options -> Workspace das
Defaultverzeichnis wechseln.
Um mit der Hardware des Robo-Interface in Kontakt zu treten, gibt es die sogenannte "Transfer-Area". Eine
Beschreibung der Transfer-Area befindet sich in der Anleitung von ft.
Namenskonventionen
Um Programme von unterschiedlichen Programmierern verwenden zu können, sollte man sich auf gemeinsame
Richtlinien zur Vergabe von Variablennamen einigen. Zwar unterscheidet sich die vom Robo-Interface Entwickler
verwendete Verfahrensweise auch von meiner eigenen, aber mir erscheint es sinnvoll, diese Namenskonventionen zu
übernehmen, denn dadurch ist es in zukunft einfacher, fremde Programmteile zu integrieren.
Mitgeliefert werden auch Verkürzungen Variablendeklarationen, so wird z.B. anstelle von "unsigned char" "UCHAR"
verwendet. Diese Definitionen befinden sich in der Datei "ke_c.h".
Bei der Vergabe von Variablennamen stehen die ersten zwei Zeichen für den Variablentyp, z.B.:
ucVariable = unsigned char
ulVariable = unsigned long
Erste Programme
Einen guten Ansatz, sich mit der Programmierung des Robo-Interface vertraut zu machen, ist die Analyse der
mitgelieferten Demo-Programme. Sinnvoll für die ersten Schritte: Einen neuen Workspace anlegen, ein vorhandenes
Demo-Programm dort hineinkopieren und dann einzelne, kleinere Änderungen vornehmen oder auch kleinere
Erweiterungen vornehmen. Wie schon erwähnt - Man bekommt keine Fehlermeldungen, wenn etwas schiefgeht.
Um einen Programmteil zu finden, der Ärger macht, gibt es z.B. die Möglichkeit, bestimmte Ausgänge mit LEDs zu
bestücken und diese beim Erreichen bestimmter Programmteile ein- oder auszuschalten.
Da dies nicht gerade sehr Benutzerfreundlich ist, nutze ich inzwischen die Möglichkeit, per serieller
Schnittstelle Nachrichten an den PC zu senden. Hierzu gibts später mehr.
Vereinfachung des I/O-Zugriffs
Berechtigterweise wurde im Forum moniert, dass der Zugriff auf die Ein- und Ausgänge sehr kryptisch ist.
Willkommen bei C! Nein, im Ernst: Es gibt natürlich jederzeit die Möglichkeit, dies mit selbstgeschriebenen
Funktionen zu ändern.
to be continued....
(thkais)
Aktuelle Version von thkais am 09.04.2006, 19:18:49 Uhr
Version 13 von thkais am 09.04.2006, 19:18:02 Uhr
Version 12 von thkais am 08.04.2006, 06:28:09 Uhr
Version 11 von thkais am 07.04.2006, 20:59:11 Uhr
Version 10 von thkais am 07.04.2006, 20:39:51 Uhr
Version 9 von thkais am 07.04.2006, 20:26:22 Uhr
Version 8 von thkais am 07.04.2006, 19:24:51 Uhr
Version 7 von thkais am 07.04.2006, 17:36:55 Uhr
Version 6 von thkais am 07.04.2006, 17:22:51 Uhr
Version 5 von thkais am 07.04.2006, 17:17:21 Uhr
Version 4 von thkais am 07.04.2006, 15:13:21 Uhr
Version 3 von thkais am 07.04.2006, 13:56:52 Uhr
Version 2 von thkais am 07.04.2006, 13:43:00 Uhr
Version 1 von thkais am 07.04.2006, 13:33:23 Uhr
Wenn sie sich einloggen, können Sie dieses Thema bearbeiten.