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.

 

Zurück zur Übersicht