## page was renamed from DVA_Praktikum #language de #format rst DVA Praktikum für TI ==================== | Hubert Högl, , http://hhoegl.informatik.hs-augsburg.de | URL: http://elk.informatik.hs-augsburg.de/hhwiki/DVATI_Praktikum .. Ab dem Sommersemester 2010 betreue ich das DVA-Praktikum für die Technischen Informatiker (TI). Willkommen zum *DVA Praktikum für Technische Informatiker*. Die Veranstaltung soll dazu dienen, dass Sie ... * sich mit wichtigen Themen aus der Technischen Informatik vertraut machen. Die technische Schwierigkeit steht dabei nicht im Vordergrund. Die Versuche werden eher leichte bis mittlere Anforderungen stellen, da die Bearbeitungszeit von einer bis zwei Wochen knapp ist. * verständlich über die Themen reden können, daher wird es eine wöchentliche Kommunikation mit dem Betreuer geben. * das, was Sie gelernt haben, auch in einem Bericht niederschreiben. Der prinzipielle Ablauf ist identisch mit dem Ablauf bei den `Informatik-Versuchen `_. Nur die Details ändern sich: * Liste der Versuche: ``_ * Moodle: - https://moodle.hs-augsburg.de/course/view.php?id=2843 (Gruppe 3) - https://moodle.hs-augsburg.de/enrol/index.php?id=2916 (Gruppe 1 und 2) * Gitlab für Gruppe 3: https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws19 (die Anzahl der Gruppen ändert sich noch. Je Gruppe wird ein Student oder eine Studentin als Maintainer eingetragen. Alle weiteren Gruppenmitglieder trägt der Maintainer ein) * Betreuung: Es wird maximal drei Gruppen geben: - Gruppe 1: Montag, 9:50-11:20 Uhr / G2.17 (Schöppler, ). **Achtung:** Dieser Termin ist parallel zum Elektrotechnik-Praktikum. - Gruppe 2: Montag, 11:40-13:10 Uhr / G2.17 (Schöppler) - Gruppe 3: Mittwoch, 8-9:30 Uhr / G2.16 (Högl, Schäferling , max. 16 TeilnehmerInnen) .. _bericht: Anleitung zur Abgabe der DVA Berichte ------------------------------------- 3\. November 2019 1. Alle Gruppen schreiben Ihren Bericht mit "Sphinx". Es gibt einen Demo-Bericht, den Sie hier finden: http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht Diesen sollen Sie lesen und an Ihre Gruppe anpassen, so dass ein leerer initialer Bericht entsteht. #. Diesen Bericht verwalten Sie auf Gitlab in Ihrem Repository für Ihre Gruppe (31, 32, 33, 34, 35, 38). https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws19 Nehmen Sie nur die Quelldateien in das Repository auf, *nicht* das Verzeichnis für die HTML Ausgabe ``_build/html/``! Jedes Repository soll eine Datei ``README.md`` enthalten, ein Muster sieht so aus: .. code-block:: text # DVA Praktikum für Technische Informatiker Hochschule Augsburg \ Fakultät für Informatik \ Wintersemester 2019/2020 \ Prof. Dr. Hubert Högl **Gruppe: 1** 1. Hans Maier, #123456, INF6, 2. Anna Huber, #126987, INF6, 3. Franz Xaver, #349816, INF8, 4. Isolde Weber, #432190, INF8, Das Gitlab Repository dieses Berichts ist unter https://r-n-d.informatik.hs-augsburg.de:8080/dvati/berichte-ws19/XXX/ Der Bericht im HTML Format liegt hier: http://www.hs-augsburg.de/~xxx/xxx. Diese Datei ist in "Markdown" formatiert. Die Dokumentation für diese Formatierungssprache ist hier: https://github.github.com/gfm. Es wird *nur ein* Sphinx-Bericht abgegeben. Jeder Versuch, den Sie durchführen, ist ein Kapitel in diesem Bericht. #. Die HTML Ausgabe (``_build/html/``) soll auf den Webspace des Rechenzentrum hochgeladen werden. Wie das geht, steht im Demo-Bericht auf Kapitel 4.7 (Auf Webspace übertragen). Es genügt, wenn der Bericht in dem Web-Verzeichnis eines einzigen Gruppenmitglieds liegt und dieser URL in die README.md Datei aufgenommen wird. #. Hier ist ein Beispiel aus dem Sommersemester 2019 (DVA für Informatiker): * Gitlab https://r-n-d.informatik.hs-augsburg.de:8080/dva/berichte-2019/1 * RZ Home https://www.hs-augsburg.de/~brobot/dva .. _termine: Termine (nur Mi) ---------------- :: 1. 2.10.19, M1.01, 8:15 Vorbesprechung 2. 9.10.19, G2.16 Besprechung der Vorbereitungsaufgabe Ausgabe Versuch 1 3. 16.10.19, G2.16 4. 23.10.19, G2.16 5. 30.10.19, G2.16 6. 6.11.19, G2.16 7. 13.11.19, G2.16 8. 20.11.19, G2.16 9. 27.11.19, G2.16 10. 4.12.19, G2.16 11. 11.12.19, G2.16 12. 18.12.19, G2.16 .. _besserer-ablauf: Anregungen für einen besseren Ablauf ------------------------------------ H\. Hoegl, 21.11.2019 Planen Sie ihren Versuch so, dass nach einer Woche schon ein Teil des Berichtes in lesbarer Form im Gitlab Repository ist (also bis zum 27.11.). Dadurch kann man am 27.11. über mögliche Probleme beim Versuch reden. Der finale Versuchsbericht soll bereits am 4.12. fertig sein. Damit die Versuche variabler werden, bitte ich Sie, in den aktuellen Versuchen folgende Anregungen aufzunehmen: **GPS** (Team 31) GPS beschreiben, d.h. Funktionsprinzip, Beschreibung der Segmente, zu erreichende Genauigkeit. Auswertung der Rohdaten (NMEA-Sentences) durch Parsen -> Extraktion der Zeit und Position -> Bestimmen der aktuellen Geschwindigkeit   Verwenden einer passenden Python-Bibliothek, die das Parsen schon übernimmt -> aus der gewonnenen Position die Entfernung zu einer nahen und auch einer weit entfernten Position bestimmen. **MBed** (Team 32) Das MBed Board bietet viel mehr Möglichkeiten als lediglich eine Ampelsteuerung mit drei LEDs zu programmieren. Dem Anschlussplan unter https://os.mbed.com/platforms/mbed-LPC1768 können Sie auch Analogeingänge, PWM-Ausgänge, Signale für eine Ethernet-Schnittstelle, eine SPI und eine I2C Schnittstelle entnehmen. Interessante Aufgaben sind z.B. das Ansprechen von Sensoren über I2C (z.B. Temperatursensoren oder WII Nunchuck Fernbedienungen - beide sind im Labor). Über PWM kann man z.B. Servos ansteuern. Die Signale SCL und SDA kann man mit Oszilloskop oder Saleae Logikanalysator ansehen. Man kann die Pull-Ups variieren und die Signalverläufe untersuchen. Welche Auswirkungen ergeben sich? Statt dem Online-Compiler kann man auch die Offline-Toolchain verwenden. Leistungsaufnahme: wie viel Strom benötigt ein das Board (evtl. verschiedene Betriebsmodi?) Wie lange würde Akkubetrieb rechnerisch klappen? **STM32 Nucleo Board** (Team 33) Dieses Board werden Sie auch im 5. Semester in *Embedded Systems II* verwenden. Deshalb ist die Zeit gut investiert, sich schon jetzt damit zu beschäftigen. Besorgen Sie sich von der CPU (STM32L476) das Reference Manual und verschaffen Sie sich einen Überblick über die Funktionsblöcke des Mikrocontrollers. Das STM32 Nucleo Board bietet ähnliche Möglichkeiten wie das MBed Board. Tatsächlich ist das Nucleo Board auch "MBed enabled", so dass man die MBed Programmierumgebung verwenden könnte. Es gibt allerdings noch einige andere Umgebungen, die sie ausprobieren können: * System Workbench for Linux https://www.openstm32.org/HomePage * Atollic Truestudio https://atollic.com/truestudio * Platformio https://docs.platformio.org/en/latest/platforms/ststm32.html * Micropython https://blog.boochow.com/micropython-firmware-for-mbed-boards Anregungen für Experimente sind z.B. das Auslesen des internen Temperatursensors oder das Einlesen von Analogwerten. Auch die Servo-Ansteuerung ist möglich. **RS485** Team 34) Untersuchen der Leitungen (A/B) mittels Oszilloskop. Beschreibung der Vorteile von RS485 gegenüber z.B. RS232.   Ansprechen des seriellen Anschlusses mittels Python-Programm, z.B. Implementierung eines automatisch antwortenden Gegenstelle **RPi-HAT** (Team 35) Mindestens einer der Sensoren des Sense-Hats verwenden (Temperatur/Luftfeuchtigkeit/Luftdruck, IMU/Kompass) um z.B. ein Spiel *selbst zu implementieren* (die Spielidee darf es auch schon mal gegeben haben). Entwicklung eines Erbeben-Detektors mit Hilfe des IMU-Sensors -> kleine Messungenauigkeiten müssen gefiltert werden. Dazu sind kleine Experimente zur Filterung der Daten nötig. Bei einer entsprechenden Erschütterung soll das Display eine Warnung ausgeben. Entwicklung einer Wetterstation - mit Hilfe eines Frameworks oder einer selbst implementierten Lösung sollen Temperatur/Luftfeuchtigkeit/Luftdruck über einen längeren Zeitraum beobachtet werden können. Gerne auch mit Web-Interface oder unter Verwendung von MQTT und (freien) IoT-Diensten. **CAN** (Team 37) * Arbeiten Sie unter Linux mit socketcan. * Verwenden Sie zur Kommunikation mit dem CAN Bus sowohl ein Terminal-Programm als auch Software. Zur Auswahl stehen - Python (entweder https://pypi.org/project/python-can oder https://github.com/fishpepper/pyUSBtin) - Java * Sehen Sie sich die Daten auf dem CAN Bus mit einem Oszilloskop, mit dem Saleae Logikanalysator und mit Wireshark an. * Verwenden Sie den "USBtinViewer" (siehe https://www.fischl.de/usbtin). * Beschreiben Sie die Unterschiede zu RS-232 und RS-485. **Arduino** (Team 38) Messen von Analogwerten (beiliegender Poti). Ansprechen eines Servo-Motors. Entfernungsbestimmung mit Hilfe eines Ultraschall-Sensors. .. vim: et sw=4 ts=4