Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
framework [2019/01/29 15:33] – Externe Bearbeitung 127.0.0.1framework [2019/07/27 16:38] – [Das Betriebssytem] 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.