Vorab ist zu bemerken, dass sich das myAVR C++ Framework derzeit in der Entwicklung befindet. Somit ist es gut möglich, dass sich die eine oder andere hier vorgestellte Klasse noch etwas verändert. Es werden auf jeden Fall neue leistungsfähige Klassen im Laufe der Zeit hinzukommen und was für Sie wichtig ist, Sie können jetzt noch Einfluss auf die Entwicklung über Diskussionen und Rückmeldungen nehmen.

Sie werden vorübersetzte (precompiled) Bibliotheken des myAVR C++ Framework für das Tutorial benutzen. Für die verschiedenen Controllerklassen sind entsprechende Bibliotheken und die zur Nutzung nötigen Includes innerhalb der Entwicklungsumgebung SiSy automatisch verfügbar. Im Folgenden sollen für das Tutorial wichtige Ausschnitte zur Struktur des Framworks, bezogen auf das myAVR Board MK2, vereinfacht dargestellt werden. Alle Klassen, die hier aufgezeigt werden, sind in der vorliegenden Version des Framework für Sie verfügbar. Verschaffen Sie sich einen kurzen Überblick zu den Klassen. Die Anwendung und genauere Auseinandersetzung mit diesen erfolgt im Tutorial.

Der Ausgangspunkt für die folgenden Betrachtungen des Frameworks ist das myAVR Board MK2. Es kann natürlich auch das myAVR Board light dafür herangezogen werden.

Das Board verfügt über einen ATmega8 mit 3,6864 Mhz und über folgende für die Programmierung relevante externe Bausteine:

• 1 USB-UART Bridge
• 2 Taster
• 2 Potentiometer
• 1 Lichtsensor
• 1 Speaker
• 3 LEDs

Für den Anfang sind noch folgende interne Bausteine relevant:

• 3 digitale Ports, PORTB, PORTC, PORTD
• 3 Timer
• 1 ADC
• 1 USART

Von der Gegenständlichkeit loslösen heißt, den Dingen Namen zu geben. In den folgenden Übersichten orientieren wir uns an dem Darstellungsstandard der UML. Das ist weniger schwierig, als es klingt. Wer ein Viereck zeichnen kann, kann auch UML. Die Dinge sind Vierecke und die Beziehungen zwischen den Dingen werden als Verbindungen gezeichnet. Die Namen, welche wir den Dingen geben, schreiben wir in das betreffende Viereck. Wohin sonst? Damit bestimmte Verbindungen dem Betrachter verständlicher werden, erlaubt, ja bittet die UML, diese zu beschriften.

Im Zentrum unserer Betrachtung steht der Controller. OK, da ist er. Ein Rechteck mit dem Namen Controller. Ganz nebenbei wissen wir, dass auf unserem Board ein ATmega8 verbaut wurde. Der Controller ist also ein ATmega8.

Betriebssystem ist natürlich übertrieben, aber das Framework verfügt bereits über wichtige Laufzeitstrukturen, die faktisch immer wieder gebraucht werden. Diese sind in der Klasse AppKernel zusammengefasst. Dazu gehört natürlich die Kontrolle über die Startsequenz und über die MainLoop. Beides kennen wir aus der klassischen Mikrocontrollerprogrammierung. Wir geben jetzt die Kontrolle über diese beiden wesentlichen Strukturelemente einer Mikrocontrolleranwendung zur Verwaltung an das Framework ab. Keine Panik, so ungewöhnlich ist das nicht und es macht vieles einfacher.

Von besonderem Interesse sind für uns die Operationen onStart und onWork. Der UML Spezialist erkennt scharfen Auges an der kursiven Schrift der beiden Operationen sofort, dass diese virtuell sind, also vom Anwendungsentwickler (das sind Sie) überschrieben werden können. Das bedeutet nichts weiter, als dass Sie diese beiden Operationen in ihrer Applikation selbst noch mal hinschreiben können und das Framework diese automatisch zum richtigen Zeitpunkt aufruft. Das sind sogenannte Ereignishandler. Davon werden wir noch einige sehen. Wie wir diese richtig nutzen, wird im Tutorial beschrieben. Um diesen Aspekt noch etwas näher zu beleuchten, schauen wir uns noch an wie es möglich ist, dass bestimmte Bausteine selbstständig (parallel) ihre Aufgaben erfüllen können. Selbstständig arbeitende Bausteine sind von der Klasse AppModul abgeleitet und der AppKernel verteilt die betreffenden Ereignisse automatisch an die Bausteine vom Typ AppModul. Jedes AppModul meldet sich auch automatisch beim AppKernel an und wird dort in einer Liste geführt.

Auffällig ist hier zum einen, dass der Controller jetzt einen Timer hat und zum anderen die widerum virtuellen Operationen onTimer10ms, onTimer100ms, onTimer1s. An diese können wir uns als Programmierer sozusagen dranhängen. Den Timer braucht der Controller, um als AppKernel Zeitereignisse auszulösen. Wir sehen, dass auch die AppModule über diese Operationen verfügen. Das ist für uns jetzt weniger interessant, da wir noch keine eigenen AppModule entwickeln wollen.

Das Framework bietet dem Programmierer hoch entwickelte Klassen, deren Nutzung die Entwicklungszeit enorm verkürzen. Für das Tutorial sind folgende Klassen von besonderem Interesse:

Der DigitalPort oder besser GPIO-Port ist eigentlich keine Klasse sondern eine Strukturdefinition (Bitfeld). Das bedeutet, dass diese keine Operationen anbietet, sondern nur öffentliche Attribute enthält. Der Zugriff erfolgt über den Punkt-Operator. Der DigitalPort kann für elementare Ein- und Ausgabefunktionen genutzt werden.

Die Klasse Button ist spezialisiert auf das Handling von Tastern. Eine Benutzerinteraktion über Taster kann effizient und vielfältig geführt werden. Dabei ist die Klasse in der Lage zwischen kurzem Klicken und halten der Taste zu unterscheiden. Die entsprechenden Ereignisse werden an die Applikation gesendet (onEvent).

Die Klasse Led ist für typische Anwendungen einfacher LEDs konzipiert. Dabei können diese nicht nur ein-, aus- und umgeschaltet werden, sondern vom Programmierer den „Auftrag“ bekommen nur kurz aufzublitzen, zu blinken oder sogar eine komplexe Blinkfolge auszusenden.

Zur Klasse Uart ist eigentlich nicht viel zu sagen. Diese bietet neben der üblichen Funktionalität zusätzlich die Möglichkeit SRAM-schonend konstante Zeichenketten aus dem FLASH zu senden. Außerdem auch kleinere Konvertierungsfunktionen, bei denen beim Senden von numerischen Werten diese in ASCII-Codes umgesetzt werden.

Eine besondere Erleichterung im Umgang mit Zeichenketten stellt die Klasse String dar. Diese erlaubt einen modernen Umgang mit Zeichenketten. Der Komfort ist jedoch nicht umsonst zu haben. Diese Klasse benötigt natürlich auch entsprechenden Programmspeicher für die gebotene Funktionalität.

Für die einfache Erfassung von analogen Daten sind aus dem Framework für das Tutorial die Klassen AnalogDevice und Potentiometer interessant. Beide Klassen laufen im Free-Run-Modus und können also jederzeit nach dem aktuellen digitalisierten Analogwert gefragt werden. Die Klasse AnalogDevice bietet die Rückgabe von 10bit und 8bit Werten, während die Klasse Potentiometer die Stellung des Abgriffs in Prozent (0 bis 100) liefert.

Für die komfortable Anwendung des Piezoschallwandlers oder mit entsprechender Treiberstufe auch eines Lautsprechers bietet das Framework die Klasse Sound. Von der einfachen Tonausgabe über Tonfolgen bis hin zu kleinen Melodien ist der Programmierer mit dieser Klasse in der Lage die Mensch-Maschine-Schnittstelle mit einer akustischen Ausgabe zu versehen.

Mit der oben vorgestellten Auswahl von Klassen aus dem myAVR C++ Framework kann die Struktur einer Applikation wie nachfolgend aufgebaut werden. Vergleichen Sie diese Darstellung mit den oben gezeigten Experimentierboards.

Damit soll die Kurzvorstellung des Frameworks abgeschlossen werden. Das Tutorial wird auf diesen Klassen aufbauen und deren Anwendung näher erläutern. Um weitere Klassen aus dem Framework kennenzulernen und anzuwenden bieten sich die internen Hilfen in der Entwicklungsumgebung SiSy an. Für diejenigen, welche aufbauend auf dem Framework dieses erweitern und eigene Klassen entwickeln wollen empfehle ich, sich mit der UML in SiSy zu beschäftigen.

Und hier die Hilfedatei zum download

Hardware