Home ==> Mikrobeginner ==> Fazit
ATtiny24

Fazit aus den hier dargestellten Lektionen


Prozessorhardware

Die AVR bieten eine Menge eingebauter Hardware zur Nutzung an. Die kann mit ein paar wenigen Konfigurationsbits in den richtigen Ports mühelos zur Mitarbeit bewegt werden. Das Einschalten ist mit ein paar SBI- oder CBI-Instruktionen auf die richtigen Portbits einfach zu bewerkstelligen. Wer einmal kapiert hat, wie der Timer funktioniert und welche Bits sein Verhalten wie beeinflussen, braucht sich nicht mehr mit den Eigenheiten einer rudimentären Hochsprache wie Basic herumschlagen. Die ganze Welt des Timers steht dann offen und nicht nur das, was der Basic-Compiler gerade so anzubieten geruhen will. Man kann erstaunlich viel mit so einem Timer anfangen, wenn man sich nur traut, wie die entsprechenden Lektionen demonstriert haben. Und die paar SBI und CBI sind nicht gerade ganz große Programmierkunst oder undurchschaubares Hexenwerk.

Nur ein paar wenige Hardware-Features sind in den 14 Lektionen bislang nicht vorgekommen, was aber zu verschmerzen sein wird. Zum Einen ist das assynchrone (z. B. UART) und synchrone (z. B. I2C) Übetragungshardware. Wer zu Hause was Funktionierendes basteln will, braucht diesen Quatsch aber meistens auch gar nicht, es sein denn er möchte unbedingt eine ganze Farm von Prozessoren miteinander verkabeln (wie das Autohersteller oder voll ausgeflippte Informatiker gerne tun) oder man möchte Messwerte gerne dem PC mitteilen. Braucht also kaum ein Mensch, der eine maßgeschneiderte Lösung für sein Hardwareproblem haben will.

Selbige Klientel verwenden auch sehr gerne ein weiteres Hardware-Feature, das hier aber voll zu kurz kommt: den Bootmodus. Wer viele Tausend AVR immer mit den neuesten Ergüssen seiner Programmierkünste versehen möchte, braucht das unbedingt. Heute dies, morgen das, und übermorgen wieder alles anders. Das macht die Unausgereiftheit des Erdachten zum Konzept, wie das heute bei der Herstellung von Software so Sitte und ganz üblich ist. An so was kann nur jemand Freude haben, der sich unbedingt mehr Probleme wünscht als er lösen kann, um so mehr Daseinsberechtigung zu erringen. Natürlich braucht man das unbedingt, wenn man mehrere Millionen Dieselautos von Betrugssoftware in den Ehrlich-Modus zurückstellen muss. Normale Menschen brauchen das aber nicht, weil sie nie auf die Idee kämen, Betrugssoftware zu schreiben.

Externe Hardware

Das ist ein Punkt, der dem Programmierer immer Kopfzerbrechen machen sollte. Eine fehlerhaft konzipierte externe Hardware ist immer von Übel. Sie macht naheliegende Softwarekonzepte zunichte und zwingt im ungünstigen Fall zu immer neuen Kompromissen in Bezug auf die Funktionssicherheit. Wer das Prellen von Schaltern und Tasten vergessen hat, wird mit seiner Software nicht sehr glücklich werden. Meine HighTech-ATmega-Weckuhr zwingt mich morgens dazu, den WeckAus-Taster drei bis vier Mal zu drücken, bis der Alarm endlich aus ist. Das Prellen hat der Taster erst nach zwei Jahren Betrieb angefangen, wahrscheinlich hat sich die Korrosion Zeit gelassen, daher fiel das noch nicht beim Design der Software auf.

Da das Design der externen Hardware immer auch Konsequenzen für die Typauswahl und das Programm haben, können sich geänderte externe Beschaltungen bis hin zu einer völligen Neukonzeption des Assemblerprogramms auswirken. Hier frühzeitig Grips zu investieren, ist reiner Selbstschutz.

Da zu behaupten, man sei halt mit Elefantendesign auf der sicheren Seite, ist reine Theorie. Wozu soll man in einem Modellflugzeug 96-polige Chips einsetzen, von denen man aber nur ganze sechs Pins tatsächlich braucht (einen als Impulseingang, einen als PWM-Ausgang für die Motorleistung und je zwei für Richtung und Intensität für Höhen- und Seitenruder)? Es scheint, die Arduino-sozialisierten Programmierer hatten noch nie wirkliche Probleme zu lösen, deshalb konnten sie sich lange in ihrem selbsterrichteten Arduino-Elfenbeinturm einmauern und können sich eine Problemlösungswelt ohne USB-Schnittstelle schon mal gar nicht vorstellen. Sie kennen den Wert einer LED fürs Debugging überhaupt nicht, weil sie schon immer viel mächtigere Werkzeuge ihr Eigen nennen. Die aber halt bei einer Rudermaschine mit einem putzig kleinen ATtiny10 aber rein gar nix bringen, weil in den allenfalls Bruchteile ihrer Megabibliothek reinpassen und kein Platz mehr ist für echten Code.

Selbstbeschränkung bleibt Selbstbeschränkung, auch wenn sie sich mit modernen Schlagworten ein knallbuntes Mäntelchen überstreift.

Programmdesign

Besonders für Anfänger im Mikroprozessor-Programmiergeschäft dürfte dieser Punkt der abschreckendste sein. Die elendig langen Listings, die spätestens mit Lektion 6 hier Einzug hielten, dürften den Eindruck erwecken, als sei das alles viel zu kompliziert um es zu kapieren. Deshalb hier folgende Ratschläge als Lese-, Analyse- und Verständnishilfe:
  1. Interruptgesteuerte Programme haben immer diesselbe Grundstruktur, denselben Aufbau. Finde heraus, was die einzelnen Interrupts tun und welche Flaggen diese unter welchen Bedingungen setzen. Das ist schon die halbe Miete beim Verständnis der Abläufe.
  2. Die Pozessorhardware wird immer zuerst initialisiert. Welche interne Hardware wird hier für welche Zwecke wie eingeschaltet? In welchen Modi laufen Timer, ADCs und andere interne Hardware?
  3. Versuche aus der Dokumentation auf Standardabläufe zu schließen. Eine Multiplikationsroutine sieht immer gleich aus, die 18 bis 20 Instruktionen dafür gehören zusammen, ein genaues Verständnis jeder einzelnen Codezeile ist dann überflüssig, wenn der Sinn und Zweck dieses Codepackens klar ist.
  4. Versuche die Ablaufalgorithmen aufzumalen und die entsprechenden Bedingungen zu klären.
Die Grundentscheidung, ob für die Lösung eines Problems bestehende und verfügbare Softwareschnipsel geeignet sind oder ob deren Anpassung an den geänderten Bedarf mehr Aufwand erfordert als das Neudesign dürfte für den Anfänger sehr schwer zu entscheiden sein. Mit zunehmender Erfahrung in Design und Programmierung dürfte das Neudesign zunehmend die Oberhand gewinnen. ©2016 by http://www.gsc-elektronic.net