TU Wien:Mikrocomputer für Informatiker innen LU (Hauer)

Aus VoWi
Zur Navigation springen Zur Suche springen
Ähnlich benannte LVAs (Materialien):

Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Friedrich BauerDaniel HauerThomas Leopold
ECTS 2
Alias Mikrocomputer für Informatiker_innen (en)
Letzte Abhaltung 2023SS
Sprache Deutsch
Mattermost mikrocomputer-fuer-informatiker-innenRegisterMattermost-Infos
Links tiss:384174
Zuordnungen
175FW Wahlmodul Freie Wahlfächer
880FW Wahlmodul Freie Wahlfächer
Bachelorstudium Technische Informatik Pflichtmodul Mikrocomputer
Masterstudium Data Science Wahlmodul Freie Wahlfächer


Inhalt[Bearbeiten | Quelltext bearbeiten]

Lösen einer praktischen Aufgabe. Das heißt Ansteuerung von (meist spielerische) elektromechanischen Hardware-Aufbauten, z.B. einen Aufzug ansteuern oder eine Kugel auf einer Platte mittig balancieren lassen. Dazu wird ein STM32 Microcontroller programmiert. Erklärt wird der Controller und seine Peripherie-Einheiten in der vorausgehenden LVA TU Wien:Mikrocomputer für Informatiker innen VU (Hauer).

Ablauf[Bearbeiten | Quelltext bearbeiten]

Die Übung selbst ist auf drei aufeinander folgende Tage (ganztägig, 09:00 - 17:00 glaube ich) geblockt und man arbeitet in 2er Teams. Man meldet sich mit einem Kollegen/einer Kollegin für einen Slot an der zwischen März und Juni stattfinden wird (Termine werden in TUWEL nach der Vorbesprechung freigeschaltet). Man kann daher auch schon im März mit der ganzen LVA fertig sein, wenn man einen der ersten Slots nimmt.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

Die LVA TU Wien:Mikrocomputer für Informatiker innen VU (Hauer) ist sehr hilfreich, da hier die Programmierung des STM32 und seiner Peripherie (ADCs, USART, SPI, I2C,...) grundlegend und gut verständlich erklärt werden. Wenn man in der HTL oder anders wo schon mal mit Mikrocontrollern zu tun hatte, wird es sicher leichter fallen.

Vortrag[Bearbeiten | Quelltext bearbeiten]

Nix da, Laborübung

Übungen[Bearbeiten | Quelltext bearbeiten]

Der Ablauf ist so, dass man eine Station/Aufgabe zugelost bekommt auf die man sich dann (gemeinsam) eine Woche lang vorbereiten kann. Die Aufgabe ist von minimal Anforderungen (Genügend) bis hin zu Bonustasks (Sehr Gut) aufgebaut und wird auch so beurteilt und muss dann innerhalb der drei Tage eures Slots gelöst werden. In der Praxis sieht das so aus, dass man drei Tage zu zweit vor einem Rechner sitzt und coded. Dafür steht die Hardware und Computer vor Ort zur Verfügung. TutorInnen sind immer vor Ort und helfen euch wenn ihr mal fest steckt. Wenn ihr schnell seid, könnt ihr auch schon am zweiten Tag fertig sein und müsst nicht mehr kommen.

Generell herscht eine entspannte Stimmung. Auch die drei Tage reichen (meist) aus um die Aufgabe entspannt auf Sehr Gut zu lösen. Generell gilt, je mehr vorbereitet wird desto schneller kann man sicher der eigentlichen Programmierung/Testen der Hardware widmen.

Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]

Die Note für das Labor setzt sich aus dem Abgabegespräch sowie den Funktionalitäten, die man implementiert hat, zusammen. Im Folgenden befindet sich ein Richtwert, welche Funktionalitäten zum Erreichen einer bestimmten Note erfolgreich implementiert werden müssen (siehe unten). Dabei ist die Erfüllung aller Minimalanforderungen für die 'schlechteren' Noten die Voraussetzung für eine 'bessere' Note. Die Gesamtnote hängt jedoch zusätzlich von dem Abgabegespräch ab, d.h. wie gut man den Code erklären kann. Die Aufgabe ist von minimal Anforderungen (Genügend) bis hin zu Bonustasks (Sehr Gut) aufgebaut. Dabei ist die Erfüllung aller Minimalanforderungen für die 'schlechteren' Noten die Voraussetzung für eine 'bessere' Note. Die Gesamtnote hängt jedoch zusätzlich von dem Abgabegespräch ab, d.h. wie gut man den Code erklären kann. Hier ein Auszug aus der Angabe der Station Trinity, das war so ein rotierendes "Display" mit Spiegeln:

Genügend: Die Motorgeschwindigkeit und die verschiedenen Demo-Modi können eingestellt und die LEDs können gezielt angesteuert werden (z.B. ein einfarbiges Lauflicht bei stehendem Motor).

Befriedigend: Zusätzlich kann das Potentiometer ausgelesen und damit eine Animation bei stehendem Motor beeinflusst werden (z.B. Geschwindigkeit des Lauflichts).

Gut: Einzelne einfarbige Pixel können bei laufendem Motor ein Standbild erzeugen (z.B. stehende Linie oder stehendes Lauflicht bei laufendem Motor).

Sehr gut: Es können gezielt mehrfarbige stehende Pixel bzw. ein ganzes Bild durch die Überlagerung der drei Grundfarben (RGB) erzeugt werden.

Die Noten dienen auch meist der Orientierung wo man am besten mit der Implementierung beginnt.

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

Am Ende des Semsters gesammelt, wenn alle die Aufgaben/ihren Slot absolviert haben.

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

Drei Tage hintereinander geblockt mit Anwesenheitspflicht. Evtl. Vorbereitungszeit im Vorfeld.

Unterlagen[Bearbeiten | Quelltext bearbeiten]

noch offen

Tipps[Bearbeiten | Quelltext bearbeiten]

Die Vorbereitungszeit nutzen und die Konfiguration des Controllers schon vorab machen. Dafür ist die zu programmierende Hardware nicht nötig. So bleibt mehr Zeit in den eigentlichen drei Tagen.

Einige Dinge können nicht vorbereitet werden, da dafür die Hardware nötig wäre (z.B. Sensoren lesen oder Motoren steuern).

Ich habe vorab zu Hause die UART-Schnittstelle implementiert. Das kann besonders am Anfang helfen, wenn sich noch nicht viel bewegt um ein Live-Feedback vom Controller zu bekommen. Wir haben beispielsweise die Werte des Potentiometers (ADC) ausgeben lassen.

Highlights / Lob[Bearbeiten | Quelltext bearbeiten]

noch offen

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

noch offen