In der Vergangenheit gab es bekanntermaßen diverse Probleme mit der seriellen Schnittstelle. Um hier beim debuggen nicht immer auf den angeschlossenen Roboter angewiesen zu sein, fiel der Entschluss einen direcs1-Roboter-Simulator zu entwickeln. Ziel sollte es sein eine Software zu haben, die auf dem seriellen Port wie die Software auf dem Atmel Microcontroller Befehle entgegennimmt und genauso "antwortet", also regiert.Gesagt, getan, hier das Zwischenergebnis. Als Name des Simulators wurde direcs-avrsim gewählt.
Vorher noch eine Erklärung, wie das ganze hardwaretechnisch gelöst wurde, denn es müssen ja dann im Betrieb die Daten zwischen zwei seriellen Ports miteinander ausgetauscht werden; also zwischen der direcs-Software und direcs-avrsim. Ganz einfach, man verbindet einfach zwei serielle Ports mit einem seriellen crossover cable, auch Nullmodem-Kabel genannt. Und wenn am Gerät keine seriellen Ports vorhanden sind, jeweils noch über zwei USB-Seriell-Wandler. Und so sieht das Ganze dann aus:
Von Vorteil ist es, wenn USB-Seriell-Wandler mit einem unterschiedlichen Chip verwendet, dann haben die seriellen Ports unterschiedlichere Namen, wie z.B. hier diese drei:
~/develop/direcs% ls /dev/tty*
crw-rw-rw- 1 root wheel 2, 0 17 Jun 19:38 /dev/tty
crw-rw-rw- 1 root wheel 11, 46 19 Jun 16:01 /dev/tty.PL2303-003014FA
crw-rw-rw- 1 root wheel 11, 44 19 Jun 16:02 /dev/tty.SLAB_USBtoUART
crw-rw-rw- 1 root wheel 11, 40 14 Jun 21:29 /dev/tty.USA19Hfa141P1.1
Um die grundsätzliche Funktionalität der Adapter und des Kabels sicherzustellen, bietet es sich an diese mit zwei Terminal-Programmen zu testen. Z.B. auf dem Mac mit goSerial oder in der Shell (Konsole) mit minicom:
Bei jedem Programm muss dann jeweils der passende serielle Port gewählt werden und jeden Befehl, den man auf "der einen Seite" dann eintippt, sollte "auf der anderen Seite" genauso erscheinen.
Hier die nun sehr einfache GUI von direcs-avrsim direkt nach dem Start:
Das abgebildete Relais, das Flashlight und die GUI-LEDs entsprechen Aufbauten auf dem realen Roboter. Als Code der hier zur Verwendung kommt, dient dabei natürlich zu 99% der, der ansonsten auf dem Atmel läuft (main.c). Dieser kann – da es ja Standard-C ist – weiterverwendet werden. Die Atmel-spezifischen Anweisungen (Setzen von Registern, Watchdog etc.) sind natürlich nicht implementiert.
Die GUI wartet nun auf die Entgegennahme von Befehlen auf dem seriellen Port – eben genau so, wie sonst der reale Roboter. Hier sieht man den Status nach Erhalt der ersten Befehle (*re# = Reset, Roboter antwortet mit *ok#):
Hier sieht man unter anderem wie das Flashlight eingeschaltet wurde (Befehl *f0on#, Roboter antwortet ebenfalls mit *f0on#):
Ebenfalls erkennbar ist die Abfrage zweier Sensoren (*s7# und *s8#). Hier antwortet die GUI zurzeit noch mit immer den gleichen Werten. Sie entsprechen den Werten des AD-Wandlers und ergeben umgerechnet dier 12 und 24. Dieses entspricht der Akku-Überwachung mit 12Volt und 24Volt-Akkus.