TU Wien:Microcontroller VU (Függer)
Daten[Bearbeiten | Quelltext bearbeiten]
| Vortragende | Martin Perner, Josef Widder |
|---|---|
| ECTS | 7 |
| Links | tiss:182694 , Homepage |
| Bachelorstudium Software & Information Engineering | |
| Bachelorstudium Technische Informatik |
Mattermost: Channel "microcontroller" • Register • Mattermost-Infos
Inhalt[Bearbeiten | Quelltext bearbeiten]
Interrupts, Timer, ADC, Display Multiplexing, USART, LCD, GLCD, Matrix Keypad, etc...
Ablauf[Bearbeiten | Quelltext bearbeiten]
Die LVA ist in drei Abschnitte geteilt:
- Programmieren in Assembler
- Programmieren in C
- nesC/tinyOS
Jeder Abschnitt endet mit einem Test und in den zwei letzten Abschnitten gibt es je eine Aufgabe, die zuhause oder im Labor programmiert werden muss.
Es gibt außerdem jede Woche Bonus-Tasks, für die man einige Extrapunkte bekommen kann. Sie sollen aber primär helfen, sich zu orienteren, wie weit man mit dem Lernen und Verstehen der Microcontroller-Programmierung sein sollte. Also selbst wenn man nicht hinter den Bonuspunkten her ist, sollte man sich diese Aufgaben ansehen und sie lösen.
Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]
Für die erste Runde sind Assemblerkenntnisse von Vorteil aber nicht notwendig, AVR Assembler ist relativ einfach aufgebaut. Der Micro16-Teil aus Technische Grundlagen der Informatik VU hilft allerdings auf jeden Fall, wenn man nicht Rechnerstrukturen gemacht hat (SE-Studierende, die Microcontroller als Wahlfach belegen z.B.).
Betriebssysteme UE oder sonstige Basiskenntnisse in C helfen bei Runde 2 und 3.
Vortrag[Bearbeiten | Quelltext bearbeiten]
Während der ersten beiden Übungsrunden gibt es einen wöchentlichen Vortrag der besuchenswert ist. Die nötigen Informationen bekommt man allerdings auch aus den Folien die anschließend online zur Verfügung gestellt werden.
Programmierbeispiele[Bearbeiten | Quelltext bearbeiten]
Im Assembler-Abschnitt gibt es kein Programmierbeispiel, aber der Beispielkatalog sollte durchgemacht werden.
Die Programmierbeispiele sind schon in der Spezifikation in mehrere Teile gespalten (mit Angabe, wieviele Punkte man für welchen Teil erhalten kann). Man bekommt Teilpunkte, auch wenn nicht das ganze Programm funktioniert.
Zu jeder Abgabe muss ein ausführliches Protokoll geschrieben werden mit aufgetretenen Fehlern, Stundenliste Erklärung der einzelnen Module. Zusätzlich sind im Protokoll mehrere Theorie Fragen zu beantworten (die meistens relativ heftig sind).
Programmierbeispiel in C[Bearbeiten | Quelltext bearbeiten]
C-Übung in der ein größeres Projekt mit C umgesetzt wird.
- 2012 war das ein Pong-Spiel mit Ausgabe über einen graphischen LCD, MP3 Ausgabe wenn Punkte gemacht werden und Steuerung der Spieler über 2 Wii-Controller (sehr Timing kritisch)
- 2016 war es ein Labyrinth-Spiel, in dem eine Kugel mithilfe einer Wii-Fernbedienung in einem Labyrinth zum Ziel gesteuert werden soll. Die Wii-Fernbedienung wird per Bluetooth angesteuert, im Hintergrund läuft Musik von einer SD-Karte (Klassiker!)
nesC / tinyOS[Bearbeiten | Quelltext bearbeiten]
TinyOS Übung bei der mit der Sprache nesC ein Projekt umgesetzt werden muss.
- 2012 war dies ein NTP Server der die Uhrzeit von einem GPS Empfänger (am Laborrechner simuliert) einlesen muss, die lokale RTC synchronisiert, einen NTP Server im Netzwerk zur Verfügung stellt und ein Touch Interface über den Display anbietet.
- 2016 war es eine Wetterstation, die von zwei Sensoren Wetterdaten (Temperatur, Luftfeuchtigkeit, Helligkeit) lesen und anzeigen musste. Musik soll abgespielt werden können (Sound-Effekte zu verschiedenen Wetterszenarien). Außerdem gab es was im IP-Stack zu tun und Boards sollten auch ihre Daten kommunizieren können.
Tests, Benotung[Bearbeiten | Quelltext bearbeiten]
Es gibt drei Tests, die aus Theorie- und Praxisteil bestehen. Bei jedem Praxistest gibt es zwei Programmierbeispiele mit binärer Bewertung. Für Theorie- und Praxistests gibt es jeweils ein Streichresultat (es zählen also die besten zwei Theorie- und die besten zwei Praxis-Tests separat).
Tests 2017:
- Test: 1. Bsp Pin-Inputs mit Logik-Funktionen verknüpfen und auf LEDs ausgeben, LED-Ports abhängig davon, ob eine weitere Taste gedrückt war oder nicht / 2. Bsp 4 Zustände, in denen unterschiedliche Zahlen auf einem Display ausgegeben werden. Zwischen den Zuständen wurde über einen Button (external interrupt auf PORTE7) gewechselt. Die Übergänge erfolgten alternierend nach einem pressed bzw. released.
Tests 2016:
- Test: 1. Bsp Pin-Inputs mit Logik-Funktionen verknüpfen und auf LEDs ausgeben / 2. Bsp einen Interrupt auf PORTE7 setzen (afaik)
- Test: 1. Bsp C-Code debuggen (nicht-binäre Wertung) / 2. Bsp C-Code selber schreiben (USART, Input Capture)
- Test: 1. Bsp TinyOS Interfaces nach Spezifikation implementieren und wiren / 2. Bsp C-Code schreiben (Watchdog)
Es schadet nicht, sich die Bewertungsgrundlage anzusehen, nachdem diese doch recht unausgewogen erscheint:
- Programmierteil der Tests (26 Punkte; es gibt 2 Programmierbeispiele pro Test, Aufteilung der Punkte variiert)
- Theorieteil der Tests (24 Punkte)
- Erste Programmieraufgabe (25 Punkte)
- Zweiter Programmieraufgabe - mit TinyOS (25 Punkte)
Um eine positive Note zu bekommen muss man auf die zwei besten Praxis-Tests insgesamt 13 Punkte haben und insgesamt (ohne Bonuspunkte) mindestens 55 Punkte.
Der 1. Test scheint zwar immer recht ähnlich zu sein, davon sollte man sich aber nicht zu viel erhoffen. Es gibt eine Vorbereitungszeit von 25 Minuten und eine Arbeitszeit von 50 Minuten, wobei die Beispiele in der Arbeitszeit dem Tutor auch noch vorgezeigt werden müssen, d.h. effektiv sind es ein paar Minuten weniger. Die zwei Assembler-Beispiele des ersten Tests sind prinzipiell nicht schwer, allerdings gibt es einfach sehr viel, das schief gehen kann und sehr wenig Zeit, um zu debuggen. Man muss also wirklich ganz genau wissen, was passiert und was man machen muss. Ein bloßes abstraktes Wissen wie "ich setze Register X und Register Y und dann schaue ich im Manual nach, wie die eine Funktion zum Bitauslesen geheißen hat" führt eher nicht zum Erfolg. Man sollte sich also gezielt auf die Tests vorbereiten (der Mustertest hilft dabei) und auch Abwandlungen durchspielen. Assembler ist eigentlich nicht so schwer, aber um den Test zu bestehen, muss man die Befehle und Muster wie Jumptables, State-Verwaltungen, etc. verinnerlicht haben und ohne groß nachzudenken reproduzieren können. Die von der LVA-Leitung empfohlenen (freiwilligen) Beispiele sollte man also durchmachen auch wenn sie nicht direkt mit dem Test zu tun haben, aber um Erfahrung zu sammeln.
Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]
Abgabe der optionalen Bonusaufgabe 3.Juli. Zeugnis erhalten am 7.Juli.
Zeitaufwand[Bearbeiten | Quelltext bearbeiten]
Der benötigte Zeitaufwand ist sehr stark von Deinem Vorwissen abhängig. Wenn Du schon Erfahrung mit Microcontroller-Programmierung hast, lässt sich jede Runde in 1-2 Wochen lösen, ansonsten kann es durchaus sein, dass Du eine Woche oder länger durchgehend daran sitzt. Vor allem das Beantworten der Fragen in den Protokollen stellt einen erheblichen Aufwand dar.
Weitere Meinung: Der Zeitaufwand der LVA ist sehr hoch und auf keinen Fall zu unterschätzen. Selbst mit Vorkenntnissen wirst du vermutlich mehr Zeit im Labor verbringen, als dir lieb ist.
Unterlagen[Bearbeiten | Quelltext bearbeiten]
Auf der Homepage sind alle benötigten Unterlagen (ATmega16 Manual, Skriptum, Videos, Schematics, ..) verlinkt.
Wenn Du noch nie Microcontroller programmiert hast, kann http://www.mikrocontroller.net/ sehr hilfreich sein. Vorher aber unbedingt die Suche verwenden, da die meisten Anfängerfragen sowieso schon gestellt wurden und die dortige Community sich in Bezug auf Freundlichkeit und Geduld zum Teil stark von anderen Foren unterscheidet.
Seit SS2012 wird das BigAvr Board von Microelektronika mit dem ATmega1280 verwendet. http://www.mikroe.com/bigavr/
Tipps[Bearbeiten | Quelltext bearbeiten]
Für die Protokolle der zu Übungsbeispiele ist eine (ziemlich) genaue Zeitaufschlüsselung anzugeben je Beispiel. Für Gnome gibt es ein das hamster-applet das sehr hilfreich sein kann.
Beim 2. Theorietest kommen nicht nur Fragen zur Hardware (die man in den zur Verfügung gestellten Usermanuals nachlesen kann), sondern auch einige Fragen aus dem Kapitel 4 des Microcontroller-Skriptums (die Hälfte des Kapitels fällt eh weg - der Assembler-Teil wird nicht gefragt da die 2. Beispielrunde ja schon in C zu programmieren ist).
Meine Vorschläge: Am Anfang ordentlich durchbeißen und den Assembler beherrschen. Zum 1. Test gehen (eventuell mit ein, zwei Energy Drinks) und beim Praxis-Teil alle Punkte holen. Denn in meinen Augen war der 2. Test um einiges schwerer und beim 3. Test konnte ich das C-Beispiel auch nicht in der Zeit schaffen. Dann bei C nicht verzagen - meiner Meinung nach ist der TinyOS-Teil einfacher
TinyOS Tipps[Bearbeiten | Quelltext bearbeiten]
- Beim TinyOS-Programmieren musst du darauf achten, Variablen nur am Anfang von Scopes zu deklarieren und nicht mitten drinnen (C89 Standard). Sonst gibt es komische Error Meldungen vom Compiler.
Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]
noch offen