Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
framework [2019/01/29 15:33] – Externe Bearbeitung 127.0.0.1framework [2019/07/27 16:38] – [Ausgewählte Bausteine] huwi
Zeile 7: Zeile 7:
 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. 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.
  
-{{:mk2grau.jpg|}}{{:lightgrau.jpg|}}+>{{:mk2grau.jpg|}}{{:lightgrau.jpg|}}
  
 Das Board verfügt über einen ATmega8 mit 3,6864 Mhz und über folgende für die Programmierung relevante externe Bausteine: Das Board verfügt über einen ATmega8 mit 3,6864 Mhz und über folgende für die Programmierung relevante externe Bausteine:
Zeile 25: Zeile 25:
  
 ===== Abstraktion vom myAVR Board MK2 zur Klassenbibliothek ===== ===== Abstraktion vom myAVR Board MK2 zur Klassenbibliothek =====
->>>>>>{{:mk2abstarkt.jpg|}}+>{{:mk2abstarkt.jpg|}}
  
 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. 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.
Zeile 32: Zeile 32:
 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. 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.
  
->>>>>>>>{{:classcontroller.jpg?400|}}+>{{:classcontroller.jpg?400|}}
  
 ==== Das Betriebssytem ==== ==== Das Betriebssytem ====
 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.  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. 
  
->>>>>>>>>>>>>>>>>>>>>{{:betriebssystem1.jpg?350|}}+>{{:betriebssystem1.jpg?350|}}
  
 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. 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.
  
->>>>>>>>>>>{{:controller.jpg?550|}}+>{{:controller.jpg?550|}}
  
 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.  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. 
Zeile 51: Zeile 51:
 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. 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.
  
->>>>>>>>>>>>>>{{:digitalport.jpg?300|}}+>{{:digitalport.jpg?300|}}
  
 === Button === === Button ===
 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 //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).
  
->>>>>{{:button.jpg?650|}}+>{{:button.jpg?650|}}
  
 === Led === === Led ===
 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. 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.
  
->>>>>>>>>>>>>>>{{:led.jpg?300|}}+>{{:led.jpg?300|}}
  
 === Uart === === Uart ===
 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. 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.
  
->>>>>>>>>>>>>{{:uart.jpg?350|}}+>{{:uart.jpg?350|}}
  
 === String === === String ===
 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. 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.
  
->>>>>>>>>>>>>>>{{:string.jpg?300|}}+>{{:string.jpg?300|}}
  
 === AnalogDevice und Potentiometer === === AnalogDevice und Potentiometer ===
 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 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.
  
->>>>>>>>>>>>{{:adc.jpg?400|}}+>{{:adc.jpg?400|}}
  
 === Sound === === Sound ===
 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.  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. 
  
->>>>>>>>>>>>>>>{{:sound.jpg?480|}}+>{{:sound.jpg?480|}}
  
 ==== Die Applikation ==== ==== Die Applikation ====