Tutorium Arbeiten mit dem M Dongle V8 2eitidaten.fh-pforzheim.de/daten/labore/mec_bc/mclt/pdf/... · 2020-01-22 · Mikrocontroller Labor: Tutorium V9.0 - 6 - 3.2 Die Entwicklungssoftware

Tutorium Arbeiten mit dem M_Dongle

Labor Mikrocontroller mit NUC130

Prof. Dr.-Ing. F. Kesel Dipl.-Ing. (FH) J. Hampel Dipl.-Ing. (FH) A. Reber

22.01.2020 Version 9.0 uVision5

__________________________________________________________________________________________ Mikrocontroller Labor: Tutorium V9.0 - 1 -

Inhalt

1 Das M_Dongle .................................................................................................................. 2

2 Funktionen des M_Dongles .............................................................................................. 2

2.1 Standard-Schnittstellen ............................................................................................. 3

2.2 LC-Anzeige ............................................................................................................... 3

2.3 Analog-Eingang ........................................................................................................ 3

2.4 Weitere Funktionen ................................................................................................... 3

3 Die Laborumgebung ......................................................................................................... 4

3.1 Installation der Entwicklungssoftware zu Hause ........................................................ 4

3.2 Die Entwicklungssoftware Keil uVision ...................................................................... 6

3.2.1 Die Ordnerstruktur ............................................................................................................ 6

3.3 Keil µVision mit Blinky testen .................................................................................... 7

4 Neues Projekt anlegen ..................................................................................................... 8

5 Projekt erstellen .............................................................................................................. 12

5.1 Einstellungen der Entwicklungsumgebung anpassen .............................................. 12

5.2 Einstellungen für das Zielssystem ........................................................................... 13

5.3 Projektdatei übersetzen .......................................................................................... 14

5.4 Projekt zusammenfügen ......................................................................................... 15

5.5 Einstellungen fürs Zielsystem (Target) vornehmen ................................................. 16

5.6 Programm auf das Zielsystem übertragen und starten ............................................ 17

5.7 Übung: Mein_Blinky ................................................................................................ 17

5.8 Projekt säubern ....................................................................................................... 18

6 Hinweise zum Simulator und Debugger .......................................................................... 19

6.1 Simulator einrichten ................................................................................................ 20

6.2 Der M_Dongle_Simulator ........................................................................................ 20

6.3 Debugger/Simulator bedienen ................................................................................. 21

6.3.1 Memory Fenster öffnen .................................................................................................. 22 6.3.2 Variablen während des Debuggens ändern ................................................................... 23 6.3.3 Variablen-Inhalt dauerhaft sehen ................................................................................... 23 6.3.4 Übung: Syntax und Logik- Fehler finden ........................................................................ 24 6.3.5 Debug-Übung ................................................................................................................. 24

7 Anhang ........................................................................................................................... 25

7.1 Einrückungsstil (indent style) Allman / BSD / „East Coast“ ...................................... 25

7.2 Datentypen ............................................................................................................. 25

7.3 Programmablaufplan (PAP) .................................................................................... 25

7.4 Grundlegende Strukturen ........................................................................................ 26

8 Literatur .......................................................................................................................... 26


1 Das M_Dongle

Abbildung1 : Lehr- und Laborplattform auf Basis des NUC130 von Nuvoton mit Cortex-M0

Prozessoren werden nicht nur in PCs, Laptops und Netbooks eingesetzt sondern auch in sehr vielen Geräten und Systemen, deren vordergründige Aufgabe nicht die Verarbeitung von Daten sondern die eigentliche Funktion des Gerätes ist. Prozessoren für diese Art der Anwendung werden Mikrocontrol-ler(uC) genannt. Das zur Funktion nötige System (die Leiterplatte mit den erforderlichen Bauteilen) wird als eigenständiges System betrachtet, dass in ein Gerät integriert (eingebettet) wird. Um die Funktions-weise und die Handhabung eines Mikrocontrollers zu erlernen werden Testumgebungen (Evaluation-boards) verwendet. Beim M_Dongle handelt es sich um eine solche Testumgebung. Die Hardware basiert auf Projektarbeiten von Michael Rothbarth und Benjamin Walz und ist eine kom-plette Eigenentwicklung, die an die Anforderungen der Mikrocontroller-Labore angepasst wurde. Die Hardware stellt die am meisten genutzten Grundelemente wie, z.B. LC-Anzeige, Taster, LEDs und Ana-logwert-Eingabe zur Verfügung. Wie es sich für einen modernen Mikrocontroller „gehört“, ist außerdem eine Vielzahl von Standard-Schnittstellen vorhanden. Der verwendete µC NUC130VE3CN verfügt über einen Cortex-M0-Controllerkern (NUC130) mit 128 KB Flash und 16 KB SRAM. Im Folgenden werden die Funktionen und die Programmierung des M_Dongle erklärt.

2 Funktionen des M_Dongles Das M_Dongle ist ein Mikrocontroller-System mit einem NUC130VE3CN Controller mit Cortex-M0 CPU und einer großen Anzahl von Schnittstellenbausteinen. Neben dem Reset-Taster sind zwei Einzeltaster und ein 5-fach Taster (Joystick) vorhanden. Als Ausgabeeinheit dient eine LED-Leiste. Zur Analog- wertsi-mulation ist ein Potentiometer verbaut und mittels Piezo-Lautsprecher können Töne erzeugt werden. Das enthaltene LCD ist grafikfähig und hat eine Größe von 128 x 64 Pixel. Der Hauptvorteil des M_Dongles ist jedoch die Schnittstellenvielfalt des NUC130. Über Stecker sind die Schnittstellen CAN, UART, USB, I2C, I2S und SPI verfügbar. Weiterhin kann auch ein PWM-Port mit vier Ausgängen genutzt werden. Die Software kann per Download-Adapter über CON2 (NULink notwendig) oder mittels Bootloader und den


USB-Anschluss auf das Board geladen werden. Zur Energieversorgung kann der USB-Port, der Debug-Port oder ein externes 5V-Netzteil verwendet werden.

2.1 Standard-Schnittstellen

Bezeichner Art Beschreibung

CON 3 USB USB 2.0 mit maximal 12 MBaud

CON 4 CAN CAN 2.0B mit maximal 1 MBaud

CON 5 UART UART mit Rxd und Txd bis 300 KBit

BU 1 UART UART mit Rxd, Txd, RTS und CTS, kein Schnittstellentreiber

BU 2 I2C 2-fach I2C mit Interrupt-Möglichkeit

BU 4 SPI SPI mit zwei Slave-Select Signalen

BU 8 SPI SPI mit zwei Slave-Select Signalen

Abbildung 2: Schnittstellen

2.2 LC-Anzeige Das LC-Display hat außer den Zeilen-/Spaltentreibern und einem Bildspeicher keine Intelligenz. Somit muss sich der Anwender um die Erzeugung der Buchstaben kümmern. Dies hat jedoch den Vorteil, dass die Anzeige komplett selber gestaltet werden kann. Die Beleuchtung ist im RGB-Format vorhanden, so dass unterschiedliche Farben erzeugt werden können. Mittels PWM kann die Helligkeit geregelt werden.

2.3 Analog-Eingang Der Analog-Port ADC[2] des NUC130VE3CN wurde mit dem Potentiometer PT1 verbunden.

2.4 Weitere Funktionen Das M_Dongle verfügt zu Lernzwecken über eine Reihe von weiteren Funktionen. Ausführliche Infor-mationen sind im Dokument _Documents\M_Dongle Technical Reference Manual.pdf zu

finden.

8-fach LED-Zeile

Joystick mit fünf Tastern

2 Taster an Portpins

1 x I2S

6 x PWM

2 x Komparator


3 Die Laborumgebung Am Laborarbeitsplatz erwartet Sie ein PC unter Windows und ein M_Dongle, dass per USB mit dem PC verbunden ist.

Zur erfolgreichen Durchführung der Versuche müssen Sie mit der Laborumgebung vertraut sein. Außer-dem ist es möglich, das Programm mit Hilfe des M_Dongle_Simulators und der Simulatoroption der µVis-sion vorab zu testen. Dafür ist das Entwicklungsboard nicht erforderlich.

3.1 Installation der Entwicklungssoftware zu Hause Damit Sie sich auf die Arbeiten im Labor gründlich vorbereiten, sollten Sie Teile von Programmen bereits zu Hause entwickeln und testen. Sie können zur Vorbereitung nach Absprache mit den Laboringenieuren auch das Mikrocontroller-Labor an der Hochschule außerhalb der belegten Termine nutzen. Die Software für das Labor (µVision5, PapDesigner, M_Dongle_Simulator) kann vom Vorlagenverzeich-nis unter MCLT_MEC, MCLT_MED oder MCLT_EIT_TI herunter geladen werden. Nach der Installation von Keil uVision5 müssen noch einige Pakete mit dem „Pack Installer“ nachinstalliert werden.

Abbildung 4: Pack Installer starten

Nach Auswahl der Firma Nuvoton, muss die Gruppe der NUC100 Devices ausgewählt werden. Auf je-den Fall muss das ARM::CMSIS und das Nuvoton::NuMicro_DFP Pack installiert werden. Die anderen Packs sind optional. Ähnliches gilt auch für andere zu verwendenden Mikrocontroller. Falls die benötigten Packs nicht angezeigt werden muss ein Update vorgenommen werden.

Abbildung 5: Pack Installer starten

USB-Kabel

Abbildung 3: Aufbau des Laborarbeitsplatzes (schematisch)

PC

M_Dongle


Abbildung 6: Packs auswählen


3.2 Die Entwicklungssoftware Keil uVision Das Programm kann direkt gestartet werden oder es wird im entsprechenden Ordner ein Doppelklick auf das Projektfile ausgeführt XXName.uvproj .

3.2.1 Die Ordnerstruktur

Abbildung 7: Ordnerstruktur

In einem Ordner M_Dongle befinden sich alle benötigten Ordner und Dateien. Dieser Ordner steht als Download zur Verfügung und sollte im eigenen Anmeldeverzeichnis gespeichert werden (z.B. Lo-gin/MR_Labor/). Da die Datensicherheit für den Laborrechner nicht garantiert werden kann, sollte das Verzeichnis auf einen anderen Datenträger oder den Studenten-Server gesichert werden. Die Inhalte der Ordner, die mit einem_ (Underscore) beginnen sind Systemordner, sie enthalten

Dokumente und vorgegebene Dateien die unbedingt zum Betrieb nötig sind. Sie dürfen nur von den Entwicklern des M_Dongle geändert werden. _Anleitung Hier finden Sie unter anderem dieses Dokument. _Copy Der Ordner _Copy enthält Dateien die nach dem Anlegen in den neuen Projektordner kopiert werden müssen. Die Dateien init.c,init.h und startup_NUC1xx.s können direkt kopiert werden. Nach

dem Kopieren dürfen sie auch verändert werden. Die Datei Projectxy.c sollte beim Kopieren auf den

aktuellen Projektnamen umbenannt werden. Sie enthält die main() Funktion. Wenn nötig kann auch eine entsprechende Headerdatei im Projektordner ergänzt werden. _Documents Alle wichtigen Dokumente sind selbstverständlich auch online verfügbar, hier allerdings befinden sie sich in einem Ordner. Wie sicherlich bekannt ist werden alle Dokumente zum Cortex M0 von ARM veröffent-licht, die Dokumente zu dem verwendeten uC finden sich auf der Homepage des Hersteller nuvoton und die Unterlagen zum M_Dongle auf der Laborseite. _Driver _Module Es wird zwischen Treibern und Modulen unterschieden. Treiber stellen die Funktionalität der benötigten Peripherieeinheiten zur Verfügung wie z.B. Treiber für die SPI-Schnittstelle über die die LC-Anzeige an-geschlossen ist. Darüber hinausgehende Funktionen zur Nutzung der LC-Anzeige befinden sich im ent-sprechenden Modul. Blinky Blinky ist das Hello World der embedded Softwareentwickler. Da nicht immer ein Display zur Ausgabe bereit steht, aber in der Regel immer eine LED auf den Boards verbautist, ist die blinkende LED immer als Beispiel verfügbar. Im Laufe der Zeit wird sich der Ordner M_Dongle mit weiteren Projektordnern füllen.


3.3 Keil µVision mit Blinky testen Im Ordner Blinky befindet sich die Datei Blinky.uvproj nach einem Doppelklick öffnet sich die Entwick-lungsumgebung.

Abbildung 8: Die Entwicklungsumgebung

1 2 3

1. Schritt Translate (Strg+F7) Die aktuelle Datei wird übersetzt (compiliert) und auf Fehler überprüft. Die aktuelle µVision Ver-sion verfügt aber auch über Dynamic Syntax Checking d.h. die Fehler werden bereits beim Ein-geben markiert. Die Markierung verschwindet sobald die Zeile fertig geschrieben oder die Feh-ler korrigiert wurden.

2. Schritt Build (F7) Die zum Projekt gehörenden Dateien werden zu einem auf dem µC ausführbaren Programm zusammengefasst.

3. Schritt Download Das ausführbare Programm wird auf das M_Dongle übertragen und gestartet.


4 Neues Projekt anlegen Im Gegensatz zu anderen Entwicklungsumgebungen legt µVision für ein Projekt nicht automatisch ei-nen neuen Ordner an. Dies muss im Vorfeld „von Hand“ erledigt werden. Hier wurde z.B. der Name Mein_Blinky gewählt.

Abbildung 9: Projektordner neu anlegen

Zum Anlegen eines neuen Projektes findet man unter „Project“ den Eintrag „New uVisionProject ...“, der dann folgende Fenster zur Auswahl des Projektordners öffnet. Der Name des Projektes hat den Namen des Projekt-Ordners, also in diesem Fall „Mein_Blinky“.

Abbildung 10: Projekt neu anlegen

Hier ist es nun wichtig, erst den Projektordner zu wählen, bevor der Projektname eingetragen wird. Hält man sich nicht daran, so wird keine korrekte Projektumgebung erzeugt. Nach Speichern erscheint folgendes Fenster in dem der Hersteller ausgewählt wird:

Abbildung 11: Hersteller Nuvoton auswählen

Nun muss der gewünschte Prozessor NUC130VE3CN ausgewählt werden.


Abbildung 12: Prozessor auswählen

Im Fenster „Manage Run-Time Environment“ werden keine Selektionen vorgenommen! Im Labor stehen alle Treiber in denen zur Verfügung gestellten Dateien bereit.

Abbildung 13: Manage Run-Time Environment


Die IDE erscheint nun mit einem leeren Projektfenster.

Abbildung 14: IDE anpassen

Das Projekt wird nun zur besseren Verwaltung angepasst.

1. Target in NUC130VE3CN umbenennen (Taget1 mit Maus anklicken und F2 drücken) 2. Source Group1 in Aufgabe umbenennen (könnte aber auch ein anderer Name wie Projekt sein) 3. Gruppen Driver und Module ergänzen (Klick mit rechter Maustaste auf NUC130VE3CN)

Die vorgenommen Ergänzungen haben keinen Einfluss auf die Daten auf der Festplatte sondern dienen nur der Übersicht im Projekt. Nun werden alle Dateien aus dem _Copy Ordner in den neuen Projektordner kopiert. Die Datei Projektxy.c wird sinnvoll umbenannt. Damit kenntlich gemacht wird, welche Datei die Hauptdatei des Projektes ist, bekommt sie den des Ordners, hier Mein_Blinky.c.

Abbildung 15: Dateien kopieren und umbenennen


Diese Dateien und benötigte Treiber und Module müssen nun dem Projekt hinzugefügt werden. Nach einem Klick mit der rechten Maustaste öffnet sich das folgende Fenster:

Abbildung 16: Dateien ins Projekt einbinden

Die Dateien müssen aus den entsprechenden Ordnern ausgewählt werden. Auch hier handelt es sich nur um logische Zuordnungen im Projekt. Wenn alles korrekt eingefügt wurde, sieht das Projektfenster wie folgt aus:

Abbildung 17: Das fertige Projekt

Mein_Blinky.c: Projektdatei mit main Funktion und Endlosschleife init.c: Für jedes Eval-Board sind Grundeinstellungen vorzunehmen, diese werden in der Funktion Board_Init() zusammengefasst.

startup_NUC1xx.s: Normaler Startup-Code für den µC. Driver_M_Dongle.c: Dies ist eine der angepassten Bibliotheken mit Funktionen für das M_DONGLE.


5 Projekt erstellen

5.1 Einstellungen der Entwicklungsumgebung anpassen Die IDE bietet Arbeitshilfen an, hierzu gehört Code Completion und Dynamic Syntax Checking. Sollte dies nicht automatisch erfolgen, so muss unter Edit\Configuration… im Reiter Text Completition folgend Einstellung vorgenommen werden:

Abbildung 18: Einstellungen Text Completion

Diese Einstellungen beziehen sich auf den Entwicklungsrechner und müssen beim Wechsel des Rech-ners erneut vorgenommen werden.


5.2 Einstellungen für das Zielssystem Nun müssen bei den Target-Options noch einige Projekteinstellungen vorgenommen werden:

Abbildung 19: Target Options einstellen

Im Reiter C/C++ und Asm müssen „Auto Includes“ ausgeschlossen werden, damit nur die Dateien in dem Projekt verwendet werden, die selbst ausgewählt wurden. Da es verschiedene Versionen des M_Dongle gibt muss die Definition des verwendeten M_Dongle glo-bal in den C/C++ Einstellungen erfolgen.

Abbildung 20: Auto Includes abschalten, Define und Pfad festlegen

Unter “Include Paths” müssen Sie folgendes angeben: .\;..\_Driver\StdDriver\inc\


Abbildung 21: Auto Includes abschalten

5.3 Projektdatei übersetzen Die ausgewählte Datei hier Mein_Blinky.c kann nun übersetzt werden (Translate).

Abbildung 21: Projektdatei übersetzen

Das Output Fenster zeigt nun folgendes an: compiling Mein_Blinky.c...

"Mein_Blinky.c" - 0 Error(s), 0 Warning(s).

Wichtig: Fehler sind zu beheben und Warnungen müssen beachtet werden. Es fällt auf, das keine Header-Files zum Projekt hinzugefügt wurden. Dies ist Absicht, da nur so erkannt werden kann, welche Files von den C-Dateien benutzt werden. Wurde eine Projektdatei einmal übersetzt, können die Header-Files unter den einzelnen C-Files angezeigt werden: NUC1xx.h In diesem HEADER sind die Hardwareabhängigkeiten, also die Registeradressen des Mikrocontrollers angegeben. Nuvoton hat bei allen NUC1xx Derivaten die gleichen Adressen für die Register verwendet. Da das leider nicht immer so ist, muss hier darauf geachtet werden, dass die richtige Datei, passend zum gewünschten Controller, eingebunden wird.


BoardConfig.h Wichtige Defines für das M_Dongle. stdint.h Neue integer Datentypen z.B. int8_t anstelle von char. core_cm0.h CMSIS Cortex-M0 Core Peripheral Access Layer Header File

Abbildung 23: Header Dateien im Projekt

5.4 Projekt zusammenfügen Nun muss das Projekt erstellt werden (Build). Alle Projektdateien werden zu einem binären File zusam-mengefügt, das auf das Zielsystem geladen werden kann.

Abbildung 24: Projekt zusammenfügen

Das Output Fenster zeigt nun folgendes an: Build target 'NUC130VE3CN'

linking...

Program Size: Code=1072 RO-data=224 RW-data=28 ZI-data=1140

".\Mein_Blinky.axf" - 0 Error(s), 0 Warning(s).

Wichtig: Fehler sind zu beheben und Warnungen müssen beachtet werden.


5.5 Einstellungen fürs Zielsystem (Target) vornehmen Als Debugg-Tool muss hier der NULink Debugger verwendet werden.

Abbildung 25: Debugger auswählen

Das Debugg-Tool wird auch als Programmer eingesetzt. Es kann noch eine hilfreiche Einstellung er-gänzt werden, die das Programm nach dem Download automatisch startet.

Abbildung 26: Reset and Run auswählen


5.6 Programm auf das Zielsystem übertragen und starten Mit dem Button kann nun das Projekt aufs Board geladen werden, allerdings hier noch ohne sichtbare Funktion.

Abbildung 27: Programm auf Zielsystem übertragen

Es ist auf den blauen Balken, der den Downloadvorgang anzeigt, zu achten. Nach erfolgreichem Down-load erscheint folgende Meldung im Output-Fenster: Load "C:\\Users\\..\\M_DONGLE_V2\\Mein_Blinky\\Mein_Blinky.axf"

5.7 Übung: Mein_Blinky Bevor die gewünschte Funktionalität realisiert werden kann sind folgende weitere Angaben nötigt:

#define DELAYS 5000

#define DELAYL 8*DELAYS

Das obige Projekt ist zur erstellen und um folgende Funktionalität zu erweitern: while(1)

{

M_GPIO_BIT_CLEAR(BIT_LED0);

M_GPIO_BIT_SET(BIT_LED1);

System_Wait_us(DELAYS);

M_GPIO_BIT_SET(BIT_LED0);

M_GPIO_BIT_CLEAR(BIT_LED1);

System_Wait_us(DELAYL);

}


5.8 Projekt säubern Der Translate und Build Vorgang erzeugt viele Daten. Diese können vor einem Kopiervorgang aus dem Projekt entfernt werden durch den Aufruf von Project\Clean target.

Abbildung 28: Unnötige Dateien aus Projekt entfernen


6 Hinweise zum Simulator und Debugger Die Unterscheidung zwischen Simulator und Debugger, also dem Herunterladen des lauffähigen Pro-gramms auf das Laborboard, ist für den Nutzer nicht ohne weiteres ersichtlich. Die Oberfläche und der Start der Anwendung sind jeweils identisch. Durch die vom Nutzer getroffenen Voreinstellungen entschei-det sich, ob simuliert oder ob das Programm auf das Laborboard geladen wird. Die Defaulteinstellung steht auf Simulator. Über –> Project -> Option für Target oder das entsprechende Icon wird folgender Dialog erreicht: Ist das Feld Use Simulator ausgewählt, muss der Pfad für das Ini-File eingetragen sein, so wird simu-liert. Soll der Debugger verwendet werden, so muss Use NULink Debugger ausgewählt werden.

Abbildung 29: Debug Einstellungen

Der Debug Vorgang wird über ->Debug -> Start oder über das entsprechende Icon begonnen.

Abbildung 30: Debug Session starten

Nach dem Start des Debuggers/Simulators stehen die Funktionen zur Verfügung, die schon aus den Laboren der Informatik bekannt sind. Sind während des Debuggens Breakpoints im Code verankert worden, darf die Hardware nicht einfach mit dem Reset-Taster zurückgesetzt werden, sondern nur über den Button „Start/Stopp“.


6.1 Simulator einrichten Steht keine Hardware zur Verfügung, so kann auch der Simulator zur Fehlersuche verwendet werden. Allerdings muss der Simulator vor der Benutzung entsprechend initialisiert werden, zu diesem Zweck wird die Datei debug.ini aus dem Ordner _copy in den aktuellen Projektordner kopiert. In einem letzten

Schritt wird die Datei debug.ini als Initialisation File eingetragen. Nun kann der Simulator

verwendet werden. Der in der µVision integrierte Simulator ermöglicht eine Simulation auf Register- und Speicherebene. Das bedeutet, dass für ein Programm mit LCD-Nutzung die benutzte Peripherieeinheit (SPI) angeschaut wer-den muss. Die über SPI transportierten Daten ergeben dann das Bild auf dem LCD. Da dies ein sehr mühsamer weg ist, gibt es eine Lösung:

6.2 Der M_Dongle_Simulator Diese Projektarbeit von Danny Bogner ermöglicht es, Aufgaben mit Hilfe des Simulators zu testen, ohne die Hardware zu benutzen. Der M_Dongle_Simulator visualisiert die Daten des µVision-Simulators und kann über Bedienelemente mit ihm kommunizieren, ohne das der Benutzer die Register und Speicher kennen muss.

Abbildung 31: M_Dongle_Simulator

Abbildung 32: Simulator ini Datei und DLL eintragen


Installationsanleitung ist im „M_Dongle_Simulator.pdf“ zu finden.

6.3 Debugger/Simulator bedienen

Abbildung 33: Bedienelemente

Es stehen die üblichen Bedienelemente zur Verfügung: 1. Reset

2. Run (bis zum nächsten Breakpoint), 3. Stopp, 4. verschieden Step Funktionen.

Unter Register werden diejenigen Register blau hinterlegt, die aktuell verwendet werden. Änderungen von Registerinhalten während des Simulierens werden ebenfalls mittels Farbwechsel angezeigt. Ausgaben auf LED, LCD werden auf die Anzeigenelemente des M_Dongle_Simulators umgelenkt. Die Eingaben für die Taster bzw. des Joysticks werden in den Keil-Simulator zurück transportiert, damit er die Aktionen bearbeiten kann. Werden im Simulator die Felder für den Joystick oder die Taster benutzt, so muss je nach Leis-tung des PCs das Feld etwas länger mit dem Mauszeiger angewählt und der rechten Maustaste aktiviert werden. Wird nur kurz innerhalb der roten Boundingbox geklickt, kann dies unter Umständen nicht vom PC erkannt werden.

1

1 2

1 3

1 4

1


6.3.1 Memory Fenster öffnen

Abbildung 34: Memory Fenster öffnen

Im ersten Fenster kann die Adresse 0x50004100 eingetragen werden und alle Register von Port E kön-nen beobachtet oder manipuliert werden.

Abbildung 35: Memory Fenster 1 0x50004100

Abbildung 36: Seite 181 NUC130/NUC140 Technical Reference Manuel

Im zweiten Fenster kann die Adresse 0x50004300 eingetragen werden und alle Pin Data Register von Port E können beobachtet oder manipuliert werden.

Abbildung 37: Memory Fenster 2 0x50004300

Abbildung 38: Seite 183 NUC130/NUC140 Technical Reference Manuel


6.3.2 Variablen während des Debuggens ändern Oft ist es notwendig, bei der Fehlersuche die Inhalte von Variablen nicht nur zu kontrollieren, sondern auch ändern zu können. Diese Möglichkeit ist über das Fenster „Call Stack + Locals“ (unten rechts) ge-geben.

Nach dem Anklicken der Variablen kann der gewünschte Wert eingetragen werden. Sollen Werte von Variablen in Funktionen geändert werden, muss sie erst aufgerufen werden, bevor die entsprechenden Variablen sichtbar werden.

6.3.3 Variablen-Inhalt dauerhaft sehen Das Problem des Call Stack Fensters ist, das dort nur der aktuelle Scope angezeigt wird. Das bedeu-tet, dass beim Aufruf eines Unterprogrammes die Variablen von Main nicht mehr angezeigt werden. Wer bestimmte Variablen immer sehen möchte, kann dies im Watch1 bzw. Watch2 Fenster realisie-ren. Dazu wird im Debugger/Simulator die Variable markiert und mittels rechter Maustaste in ein Menü verzweigt. Dort kann dann unter dem Menüpunkt Add … to diese Variable einem der beiden Watchs zugeordnet werden. Das gewählte Watchx-Fenster taucht nun ebenfalls unten rechts auf:

Nun kann immer der Wert dort abgelegten Variable nachgeschaut werden. Dies ist besonders für glo-bale Variablen nutzbar, da diese im normalen Call Stack nicht angezeigt werden. Verlässt man den Debugger/Simulator, sind die beiden Watchs beim nächsten Aufruf wieder mit allen Variablen da.


6.3.4 Übung: Syntax und Logik- Fehler finden Zu Testzwecken sollen die LEDs 0-3 nacheinander aufleuchten. LED3 soll 8x so lange leuchten wie die anderen LEDs. In dem vorliegenden Projekt My_Blinky_is_buggy haben sich leider eine ganze Anzahl Fehler einge-schlichen.

• Anpassen des Einrückungsstils

• Anpassen des Variablennamens

• Syntaxfehler korrigieren Nachdem sich das Projekt jetzt erstellen und auf das Board herunterladen lässt, ist die Enttäuschung sicher groß, die gewünschte Funktion ist nicht erkennbar.

• Die logischen Fehler sind mit dem Debugger/Simulator zu suchen und zu beheben.

6.3.5 Debug-Übung Erstellen Sie ein Projekt und fügen Sie folgende Zeilen in das Hauptfile ein: int main (void)

{

uint8_t u8Counter = 0;

DrvSystem_ClkInit(); // Setup clk system

Board_Init(); // Initialisierung der Peripherie des M_Dongles

M_GPIO_BIT_SET(BIT_LED0)

while(1)

{

while(u8Counter < 255)

{

u8Counter ++;

u8Counter &= 0x7F;

}

M_GPIO_BIT_WRITE(BIT_LED0) = ~(M_GPIO_BIT_GET(BIT_LED0));

}

}

Finden Sie den Fehler (LED0 soll blinken).


7 Anhang

7.1 Einrückungsstil (indent style) Allman / BSD / „East Coast“ uint32_t f(uint32_t ui32x, uint32_t ui32y, uint32_t ui32z)

{

uint32_t ui32qux;

if (ui32x < foo(ui32y, ui32z))

{

ui32qux = 0;

}

else

{

while (ui32z > 0)

{

ui32qux += foo(ui32z, ui32z);

ui32z--;

}

}

return ui32qux;

}

Quelle: http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil

7.2 Datentypen Datentyp Kennung Größe Beschreibung

char c 1 Byte Zeichen

int8_t i8 1 Byte Zahlenwerte -128 bis 127

uint8_t ui8 1 Byte Zahlenwerte 0 bis 255

int16_t i16 2 Byte -32768 bis 32767

uint16_t ui16 2 Byte 0 bis 65535

int32_t i32 4 Byte -2^31 bis 2^31-1

uint32_t ui32 4 Byte 0 bis 2^32-1

float f 4Byte Kommazahlen sehr rechenintensiv

double d 8 Byte Kommazahlen extrem rechenintensiv

7.3 Programmablaufplan (PAP)

Quelle: Formelsammlung, Berufliches Gymnasium (TG), 1.5.2 Informationstechnik, Stand 2008

http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil


7.4 Grundlegende Strukturen Folgende Grundelemente sind im Labor zu benutzen.

8 Literatur

[1] M_Dongle, Dokumentation [2] µVision User's Guide http://www.keil.com/

[3] C_Programmierung_mit_dem_M_Dongle

[4] Quelle: http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil

http://www.keil.com/