Es gibt kein Leben ohne Software

"Harte Schale, weicher Kern" trifft auf jedes Microcontroller Projekt zu. Der harten Schale hatte ich mich im letzten Blog gewidmet, also nun zum weichen Kern.

Es gibt zwei generelle Entwurfsstrategien "Top-Dow" und "Bottom-Up". Die heissen auch in Australien so, obwohl sie da ja auf dem Kopf stehen.

Erstere fängt beim Allgemeinen an und verliert sich immer mehr in Details. Letztere macht es umgekehrt.

Bei beiden braucht man eine genaue Vorstellung was man denn Alles so machen will und wie man letztendlich "zusammenfügt was zusammengehört". Es ist gut das vor Beginn gründlich zu durchdenken und aufzuschreiben. Je mehr Erfahrung man hat, desto eher ist man, gerade bei einfachen Projekten an denen man alleine arbeitet, versucht diesen Schritt so nebenher zu machen und auf das Aufschreiben ganz zu verzichten. Das ist falsch. Aber bekanntlich ist der "Geist willig und das Fleisch schwach" .

Ich fange gerne mit den einzelnen Komponenten "down under" an und füge sie zuletzt zu einem "großen Ganzen" zusammen. Im Wesentlichen, weil man die Komponenten isoliert gut testen kann und früh Ergebnisse sieht, was die Motivation aufrecht erhält.

Trotzdem muss man "über dem Ganzen stehen" und schon mal wissen was man braucht.

Es geht mit den 3 invertierten Affen los. Sehen, Hören, Sprechen.

Der Controller soll mit den IR Sensoren sehen wer da kommt.. Hören soll er den Datenstrom auf den Schienen und sprechen soll er mit uns mit Tonausgabe und da ein Bild mehr sagt als tausend Worte auch per Anzeige.

Hören kann er unsere Befehle nicht, und "wer nicht hören kann, muss fühlen". Also soll er fühlen, wenn wir seine Tasten betätigen.

Und damit er weiss, "was die Uhr geschlagen hat", braucht er noch eine Zeitfunktion.

Und weil  heutzutage ja alle im Mittelpunkt stehen wollen, machen sie alle aus ihrem Auftreten einen Event. Und weil es so viele sind, lohnt sich ein Eventmanager. Ein Event von dem niemand weiss ist uninteressant und so muss es noch einen Weg geben, wie man der Welt da draussen von der eigenen Existenz berichten kann. D.h. die Kommunikation über USB gehört auch noch in den Reigen der Eventveranstalter.

Wenn das Alles funktioniert muss man nur noch die Events empfangen und zu einem Rennen ordnen, sich die Zeiten merken und anderen Benutzerinterfacekram erledigen und schon ist man fertig. (Das ist, wie wenn man sagt, "dann muss ich nur noch eine Brücke über den Bosporus bauen", leichter gesagt als getan)

Alle Eventler, selbst die Uhr, werden vom Controller als asynchron behandelt. Das heisst sie sind für den Controller, wie der Besuch der Schwiegermutter, sie haben eine zu geringe Vorwanzeit, lösen Panik aus und man versucht sie so kurz wie möglich zu halten.

Das Hauptprogramm (Benutzerinterface und Rennmanagement) hingegen ist eher gemütlich und arbeitet still vergnügt vor sich hin und fragt den Eventhandler, wenn es denn Zeit hat, ob er was für es hat.

Die erste Funktion, die ich implementiere, ist immer die Kommunikation mit dem Rechner. Man kann dann Testausgaben machen und den Controller ohne  Programmiergerät programmieren. Auch die Kommunikation läuft Eventdriven und über Interrupts. Kommt ein Zeichen an, wird ein Interrupt ausgelöst, es wird ein Event erzeugt, und das Hauptprogramm holt sich den Event ab, wenn es Zeit hat. Das Schreiben erfolgt in bester englischer Manier in eine Queue (Warteschlange) die dann durch einen Interrupt "automatisch" abgearbeitet wird. Das sind Basics, hat aber trotzdem nichts mit Klamotten zu tun.

Das nächste sind Ausgaben, nicht Kosten. Wie erwähnt handelt es sich um einen Graphikbildschirm. Man schafft sich für immer wieder kehrende Aufgaben einen Satz von Routinen. Bereich löschen, Rechteck umranden, Rechteck füllen (horizontale und vertikale Linien sind ganz , ganz dünne Rechtecke), Rechteck invertieren, Bild anzeigen, Text in verschiedenen Schriften anzeigen, sind die auf die ich mich hier beschränkt habe. Ich habe letztendlich drei Fonts eingebunden, einen Led ähnlichen und einen proportionalen Textfont, einmal normal und einmal fett.

Das klingt nach genug Arbeit um die Arbeitslosenquote um 1% zu senken, aber es dauerte im Endeffekt nur etwas über einen Tag, im Wesentlichen weil ich ein Dinosaurier bin, der noch aus der Zeit stammt, als Computer noch mit Dampf betrieben und Graphiken noch aus Textzeichen zusammengesetzt wurden und als es dann "echte" Grafik gab, die Graphiklibraries selbst schreiben musste. Wie man sieht  "ist nicht Alles was alt ist ist auch schlecht". Und es spart  Zeit auf Programme aus früheren Projekten zurückgreifen zu können. Aus dem SlotMini Projekt stammt z.B. ein Programm, das aus einem beliebigen Mac Zeichensatz einen "Microcontroller" geeigneten Zeichensatz macht (Was rechtlich erlaubt ist, da die Bildschirmdarstellung von Zeichensätzen nicht geschützt werden kann ).

Die einzig interessante Entscheidung an der Graphikbibliothek war, dass ich einen Grafikbuffer im Controller verwende, statt direkt auf dem Speicher der LCD zu arbeiten.

Zum einen kann man bei entsprechender Optimierung die Graphikroutinen deutlich schneller bekommen als beim Direktzugriff auf den langsamen Controller und zum anderen hat man automatisch den Effekt, dass man den Bildinhalt mit einem Schlag tauscht und keine "durchlaufenden" Veränderungen hat, was immer irritierend wirkt. "Denken tut bekanntlich weh" und so ist es ein weiterer Vorteil ist, dass man Programme mit  Framebuffer mit weniger Denkaufwand zu programmieren sind.

Kein Vorteil ohne Nachteil. Der Framebuffer verbrät immerhin ein Viertel des verfügbare Hauptspeichers. Das riecht schon ganz schön verbrannt.

Ich merk schon, dass meine Rundenzeiten schlechter werden, ich habe wohl ein wenig Schwung verloren.

Zeit auf zu hören und auf zu tanken. Bis zum nächsten mal, mit noch mehr Software.