#format rst #language de

Erfahrungen aus dem vierten Praktikum am 7.11 (Gruppe 2, V2):

Erinnerung an Umgebungsvariable
- CUBE_HOME Man muss die Umgebungsvariable CUBE_HOME auf das Libs Verzeichnis setzen, das in es2home drin ist.
  
  Beispiel: export CUBE_HOME=/home/user/es2home/Libs
- PATH Pfade aufnehmen für arm-gcc, openocd, Logic, …
Wenn man diese Variablen per Kommandos auf der Shell setzt, dann wirken sie nur in dieser Shell! Damit sie in jedem geöffneten Terminalfenster gesetzt sind, muss man die Kommandos in ~/.bashrc schreiben.
Erinnerung an ~/.tmux.conf:

Der Terminal Multiplexer tmux benötigt eine Konfigurationsdatei .tmux.conf im Home-Verzeichnis. Diese befindet sich im Quelltextbaum der ESIDE an der Stelle eside/etc/_tmux.conf-2.1+ (für tmux Version 2.1 und grösser) oder an der Stelle eside/etc/_tmux.conf-1.x-2.0 (für tmux Versionen 1.x und 2.0). Ich nehme an, dass alle eine Version 2.1+ haben. Man kopiert einfach die gewünschte Datei in das Homeverzeichnis:
```
cp _tmux.conf-1.x-2.0 ~/.tmux.conf
```
Nur wenn es die Konfigurationsdatei gibt, kann man in tmux mit der Maus den Fokus auf ein Fenster setzen oder mit der Maus die Fenstertrennlinien verschieben.
Wer das grafische Frontend „gdbgui“ (https://gdbgui.com) für den GDB verwenden möchte, der installiert es mit pip install gdbgui. Danach fügt man in das Makefile noch folgendes Target ein:
```
gdbgui:
     gdbgui -g $(GDB) --gdb-args "-silent -x .eside/gdbinit -iex \"set auto-load safe-path /\""
```
Nach make gdbgui startet der Debugger im Webbrowser.
Wenn man in einer virtuellen Maschine arbeitet, dann ist die erreichbare USB Datenrate für den Saleae Logikanalysator zu niedrig. Deswegen sollte die „Logic“ Software dann auf dem Hostbetriebssystem (Windows, Linux, Mac) installiert werden.

Erfahrungen aus dem zweiten Praktikum am 24.10 (Gruppe 2, V1):

Das „starter“ Beispiel sollte bei allen funktionieren. Man holt es mit:
```
git clone https://r-n-d.informatik.hs-augsburg.de:8080/es2-nucl476/starter
```
Das Kommando es --ide sollte alle benötigten Fenster öffnen. Bitte auch den gdb Debugger testen, wie lange die Zeit dauert um mit dem step Kommando (kurz s) das Programm zeilenweise auszuführen.

Mit es -c findet man heraus, was bei der Installation noch fehlt. Sollten die udev Regeln fehlen, dann dies hier ausfuehren:
```
# Udev Regel installieren
sudo cp `es -p`/etc/49-stlinkv2-1.rules /etc/udev/rules.d/
sudo cp `es -p`/etc/99-openocd.rules /etc/udev/rules.d/
sudo cp `es -p`/etc/100-saleae-logic.rules /etc/udev/rules.d/
```
Es kann sein, dass auf Linux kein C Compiler installiert ist. Das löst man, indem man das Paket build-essential installiert.
Kann Probleme beim Kompilieren von openocd machen: Im virtuellen Linux, das Herr Schäferling für TI zusammengestellt hat, ist bereits der GCC für ARM vorinstalliert. Diesen Compiler nicht verwenden. Das Paket heisst gcc-arm-none-eabi, man löscht es mit apt remove gcc-arm-none-ebi. Wir verwenden statt dessen den gcc-arm von Launchpad, den man unter /opt installieren soll. Genaueres unter http://hhoegl.informatik.hs-augsburg.de/es2/eside/eside.html#id5.
Das Setzen der PATH Umgebungsvariable sollten sich manche nochmal anschauen:

https://linuxwiki.de/UmgebungsVariable
Die ESIDE beendet man mit dem Kommando es -k, das man in einem der tmux Fenster eingibt.
Siehe den neuen Abschnitt GDB Befehle.

Erfahrungen, die wir beim ersten Praktikum am 17.10. (Gruppe 1, V1) gemacht haben:

Wo ist eigentlich der Versuch 1? Man holt ihn zunächst mit „git clone“:

git clone https://r-n-d.informatik.hs-augsburg.de:8080/EmbSys2/v1

Der Aufgabentext ist in v1/doc/v1.rst.
Klonen in gitlab geht bei manchen nicht, obwohl der oeffentliche ssh Schluessel richtig in gitlab abgelegt wurde. Es hilft, wenn man einfach das Kommando ssh-add eingibt.
Die Werkzeuge funktionieren auch auf einem virtuellen Linux, das auf einem Windows 10 oder auf einem Linux als Host-Betriebssystem laeuft. Die beiden getesteten Rechner hatten USB3 Ports. Man muss in Virtualbox die Ports auf USB3 stellen, damit das Debuggen ueber USB schnell geht. Wie schnell der USB Zugriff ueber USB2 Ports geht, wurde nicht getestet.
Im Aufgabentext und in den Quelltexten von Versuch 1 waren die Angaben der Seitenzahlen in denManuals meist um ein paar Seiten falsch. Das habe ich korrigiert. Die Referenzen haben nun die Versionsnummer der Dokumente eingebaut, z.B. [RM0351R6] (= Rev. 6). Bitte mit git pull die Aenderungen holen.
Wo sind eigentlich die Dokumente zu den Angaben im Aufgabentext und in den Quelltexten, z.B. [RM0351R6]? Die Dokumente sind im Ordner es2home/Texte/. In ``es2home/index.html findet man Links auf die Dokumente.
Keim Kompilieren von OpenOCD 0.10.0 muss man bei manchen Linuxen vorher noch das Paket pkg-config installieren.
Das Paket openocd, das es in den meisten Linux Distributionen gibt, soll nicht installiert werden. Es hat meist die Version 0.9.0. Bei dieser Version wird nicht das L476-Nucleo Board unterstuetzt. Es bleibt also nur, die Version 0.10.0 selber zu kompilieren und zu installieren.
Wer Vim kennenlernen moechte, der sollte das Kommando vimtutor starten. Wenn Vim noch gar nicht installiert ist, sollte man ihn zunaechst installieren mit: sudo apt install vim.
Fuer den Editor kate gibt es ein ctags Plugin:

https://docs.kde.org/trunk5/en/applications/kate/kate-application-plugin-ctags.html

1.2 Organisatorisches ¶

Ablauf

Die Veranstaltung Embedded System II findet wöchentlich am Mittwoch Nachmittag ab 14 Uhr statt. Am Anfang ist eine 90-minütige Vorlesung, danach finden zwei Blöcke Praktikum statt.

Wöchentliches Praktikum

Für das Praktikum werden die TeilnehmerInnen der Veranstaltung in zwei Gruppen G1 und G2 geteilt, die im wöchentlichen Wechsel im Praktikum sein werden. In jeder Gruppe werden Teams gebildet mit zwei bis drei TeilnehmerInnen.

Die Aufgaben sollen in der zweiwöchigen Vorbereitungszeit gründlich vorbereitet werden, so dass beim Praktikumstermin die Aufgaben fertiggestellt und abgenommen werden können. In der zweiwöchigen Nachbereitungszeit soll der Bericht aktualisiert werden.

Die Bewertung der Aufgaben erfolgt nach den Ampelfarben: Grün steht für die erfolgreiche Abgabe, gelb steht für Nacharbeit und rot gibt es für fehlende Abgaben. Das Praktikum ist nicht bestanden bei zwei oder mehr roten Abgaben. Zwei mal gelb steht für einmal rot.

Im Praktikum herrscht Anwesenheitspflicht!

Bericht

Jedes Team schreibt von Anfang an einen Bericht über das Praktikum. Der Bericht liegt als git Repository auf gitlab und wird fortlaufend aktualisiert. Bei jedem Praktikumstermin wird der Fortschritt des Berichtes kontrolliert. Am Ende der Veranstaltung (siehe Zeitplan) wird der aktuelle Stand des Berichtes bewertet. Damit eine individuelle Notenvergabe erfolgen kann, müssen die von den jeweiligen Teammitgliedern geschriebenen Abschnitte im Bericht kenntlich gemacht werden.

Es gibt ein Gerüst für den Bericht im Format Restructured Text bzw. Sphinx:

http://hhoegl.informatik.hs-augsburg.de/dva/sphinxbericht

Der Bericht soll ein einheitliches Deckblatt für alle Projektgruppen haben.

Für das Fritzing Werkzeug (http://fritzing.org) habe ich das STM32 Nucleo Board und ein kleines Steckbrett nebeneinander platziert:

Fritzing Datei (.fzz): http://hhoegl.informatik.hs-augsburg.de/es2/img/es2-template.fzz
PNG Bild: http://hhoegl.informatik.hs-augsburg.de/es2/img/es2-template_bb.png

Diese Vorlage dürfen Sie gerne in Ihrem Bericht verwenden.

Klausur

Die erfolgreiche Teilnahme am Praktikum ist die Bedingung für die Teilnahme an der Klausur. Vergangene Klausuren finden Sie unter

http://hhoegl.informatik.hs-augsburg.de/es2/Klausuren

1.3 Zeitplan ¶

1.3.1 10.10.2018 ¶

Vorlesung: Motivation, Einführung

Vorfuehrung: Demo-Programm „starter“, nur unter Verwendung von freien Kommandozeilenwerkzeugen in mehreren Terminal-Fenstern.

Praktikum: Es gibt eine Einführung in die Linux Kommandozeile mit git, sphinx, tmux, picocom. Findet nur an diesem Tag auch im M1.02 statt!

1.3.2 17.10.2018 ¶

Vorlesung: Organisation des Hauptspeichers, „Sections“, Abbildung der Bestandteile eines C Programmes auf die Sections, Debuggen mit GDB, häufig verwendete Funktionsbloecke im STM32L4.

Vorführung des Beispielprogrammes „starter“: https://r-n-d.informatik.hs-augsburg.de:8080/es2-nucl476/starter

Hausaufgabe: Lacamera, Kap. 1 und 2 (insgesamt 49 Seiten)

Praktikum: Gruppe 1 beginnt mit Versuch 1 im G2.16.

1.3.3 24.10.2018 ¶

Vorlesung: Gegenüberstellung „bare metal“ und Programmierung mit CubeL4 + libc. Aufbau der Cube Bibliothek (HAL, LL, BSP, Beispiele, CMSIS). Tags erzeugen von allen Quelltexten mit es -t (Konfiguration in .eside/tagsconf.py). Standard C Bibliothek benötigt syscalls.c, da kein Betriebssystem-Kernel vorhanden ist. Projekte in es2-nucl476/cube_demos in Vim betrachtet. Navigation mit tags. Startup-Code in Assembler startup_stm32l476xx.s (von CMSIS), Interrupt-Handler stm32l4xx_it.c, System-Initialisierung in system_stm32l4xx.c.

Hausaufgabe: Yiu, Kap. 1, 2, 17

Praktikum: Gruppe 2 beginnt mit Versuch 1

1.3.4 31.10.2018 ¶

Vorlesung: Es geht haupsächlich um die Funktionsblöcke im Mikrocontroller, die wichtig bei der Initialisierung sind: RCC, PWR, GPIO/Alternate Functions. Zusätzlich bei Interrupts: NVIC, SCB, SYSCFG, EXTI.

Praktikum: Gruppe 1 gibt Versuch 1 ab und beginnt mit Versuch 2.

1.3.5 7.11.2018 ¶

Vorlesung: Kommentar zum bisherigen Stand der Praktikumsberichte; Demonstration des Beispielprojektes gpio-intr-cmsis: Praktisches Beispiel zu den eher theoretischen Erläuterungen von der letzten Veranstaltung. Das Programm ist auf der CMSIS Abstraktionsebene geschrieben. Es erzeugt einen Interrupt beim Drücken der User-Taste. Der Interrupt führt zum Umschalten der grünen LED.

https://r-n-d.informatik.hs-augsburg.de:8080/es2-nucl476/gpio-intr-cmsis

Praktikum: Gruppe 2 gibt Versuch 1 ab und beginnt mit Versuch 2.

1.3.6 14.11.2018 ¶

Im letzten Jahr (2017) hatten wir an dieser Stelle System handler, SysTick, bus fault, usage fault, hard fault, integer division by zero, FPU division by zero interrupt, SVC handler. Der Quelltext dazu ist in syshandler-cmsis

In 2018 habe ich die Einführung in RTOS und Tasks vorgezogen, da die FreeRTOS Versuche im Praktikum darauf aufbauen. Die Quelltexte sind hier:

Praktikum: Gruppe 1 gibt Versuch 2 ab und beginnt mit Versuch 3.

1.3.7 21.11.2018 ¶

Rückmeldung zu den Berichten, Gruppe 2. Lesestoff bis nächste Woche zum Low-Power Schwerpunkt: Yiu Kap. 9, Artikel von Keil, Buch von White, ST Appnotes. Fragen und Antworten zu RTOS, Low-Power, IoT.

Praktikum: Gruppe 2 gibt Versuch 2 ab und beginnt mit Versuch 3.

1.3.8 28.11.2018 ¶

Vorlesung: Low-power

Beispielprogramm: https://r-n-d.informatik.hs-augsburg.de:8080/es2-nucl476/cube-demos/tree/master/PWR_ModesSelection

Lit.:

http://hhoegl.informatik.hs-augsburg.de/es2/prog/keil_grobe_energyeff.pdf (S. 1-9)
Elecia white, Making Embedded Systems, chap. 10 „Reducing Power Consumption“ (siehe Lit. in Skript)
STM32L4 ultra-low-power features overview (AN4621), 2017
STM32L4 Reference Manual, chap. 5.3 „Low-power modes“

Praktikum: Gruppe 1 gibt Versuch 3 ab.

git bzw. gitlab, sphinx, tmux, picocom
Editieren in Linux: vim, emacs, gedit, atom, sublime, …
GNU Tools
Tipps zur Linux Administration, z.B. lsusb, udev Regeln und weitere
Vorbereiten des Hostrechners
Installation der „eside“

1.4.2 Versuch 1 ¶

„Bare metal“ Programmierung des STM32L476. Fragen zum Nucleo Board, zur GCC Toolchain, zum Startup Code, zur seriellen Schnittstelle. Das Git Repository zum Versuch 2 ist hier:

https://r-n-d.informatik.hs-augsburg.de:8080/EmbSys2/v1

Video „Getting started with STM32L4“: https://youtu.be/myx_UKe0SSU (ca. 1:20)