Grundlagen

Entwicklungsumgebung

Die Entwicklungsumgebung für den im Selfbus Umfeld genannten „ARM“ Mikrocontroller heisst aktuell MCUXpresso IDE. Diese ist von der NXP Homepage hier herunterzuladen.

Diese wird installiert, am besten mit allen Treibern die dabei mit angegeben werden.

Programmiergerät und Debug Schnittstelle

Die beste Art den ARM Controller zu programmieren ist ein JTAG Programmiergerät. Dieses hat zusätzlich die Möglichkeit des On-Chip-Debuggings. Damit lassen sich eventuelle Fehler recht gut und schnell identifizieren und beheben. Zusätzlich hat man die Möglichkeit Variablen auf dem Chip zur Laufzeit zu beobachten. Damit lassen sich oft logische Programmierfehler ausfindig machen.

Es gib mehrere JTAG Programmiergeräte, die von der IDE MCUXpresso unterstützt werden. Diese werden im MCUXpresso IDE - User Guide unter der Überschrift „1.1.2 Supported Debug Probes“ aufgeführt. Die bekanntesten unter Ihnen sind der J-Link von Segger und der LPC-Link von NXP. Ebenso kann man auch unseren eigenen SelfBus DAP Debugger verwenden. Dieser stellt zusätzlich die serielle Schnittstelle vom ARM zur Verfügung.

Programmieren über UART

Der LPC1115 hat einen mitgelieferten UART Bootloader, der es ermöglicht den Controller über diese UART Schnittstelle zu programmieren.

Am PC eignet sich hierzu das Programm Flashmagic, welches die Daten über eine UART Schnittstelle seriell zum Controller überträgt.

Diese serielle Schnittstelle kann mit verschiedenen Tools hergestellt werden:

Selfbus USB Programmer: Es wurde der Selfbus USB Programmer um eine Schnittstelle für den ARM Prozessor erweitert. Die neuen Modelle (ab Version 3.7) haben einen 5x2-poligen ARM JTAG Stecker. Die RM2,00mm Stecker gibt es bei Reichelt. Das Flachbandkabel 30cm im Selfbus Shop.

Die Schnittstelle ist so vorbereitet, dass die Controllerplatinen 1:1 angeschlossen werden können.

Beliebiger USB UART Adapter: Am besten und problemlosesten funktioniert ein Adapter an dem die DTR und RTS Leitungen herausgeführt sind. Damit ist ein problemloses Programmieren möglich.

Es müssen folgende Verbindungen hergestellt werden:

Applikationen, Beispiele und sblib laden

Es müssen 2 Repositories von Github geladen werden, um starten zu können.

Die ARM-Applikationssoftware liegt im Github Repository software-arm-incubation.

Die sblib ist im Github Repository software-arm-lib zu finden. Die sblib ist die grundsätzliche Software, auf der alle Selfbus Projekte aufbauen. Sie kommuniziert mit dem KNX Bussystem und bietet dem Entwickler viele Möglichkeiten.

Diese beiden Repositories können über einen Git Client wie z.B. dem von Github auf den PC geladen werden, oder für den Einsteig und die ersten Schritte ausreichend, per Klick auf den „Clone or Download“ Button im jeweiligen Github Repository.

Diese Daten werden aus der ZIP entpackt und jeweils in einem separaten Ordner an einem beliebigen Speicherort abgelegt.

Einrichtung von MCUXpresso

Die Ersteinrichtung von MCUXpresso sollte sorgfältig durchgeführt werden. Ansonsten hat man die Daten alle nachher in den falschen Ordnern und man muss sie mühselig wieder sortieren.

Beim Start der IDE (Integrated Development Environment, in diesem Fall MCUXpresso) wird nach dem Workspace gefragt. Hier bietet es sich an, einen neuen Ordner zu erstellen und dort den Workspace anzulegen.

In diesen Workspace verlinken wir jetzt die beiden heruntergeladenen Selfbus Repositories software-arm-incubation und software-arm-lib.

Dieses wird über die Schaltfläche „Import project(s) from file system…“ gemacht. Diese Schaltfläche findet man im linken, unteren Bereich „Quickstart“.

In dem sich öffnenden Fenster wird der Button „Browse…“ in dem Bereich „Project directory (unpacked)“ angeklickt.

Hier wählt man zunächst den Pfad des Speicherorts der software-arm-lib Dateien an. Nach dem Betätigen der Schaltfläche „Next“ erscheint eine Übersicht über alle in dem Ordner befindlichen Projekte. Im Falle der software-arm-lib umfasst dieses einige examples und eben auch die sblib. Wichtig ist, dass mindestens die sblib angewählt ist, der Rest kann aber auch sehr hilfreich sein.

Nun ist es noch sehr wichtig, dass der Haken bei „Copy projects into workspace“ entfernt wird!

Dieses führt dazu, dass nur eine Verlinkung hergestellt wird, die Daten aber da bleiben wo sie sind.

Die Prozedur wird mit einem Klick auf die Schaltfläche „Finish“ abgeschlossen.

Nach einem erneuten Klick auf „Import project(s) from file system…“ wird der Ordner der software-arm-incubation Daten ausgewählt. Nach dem Klick auf „Next“ können die Applikationen ausgewählt werden. Für einen ersten Überblick würde ich alle Projekte auswählen. Den Haken bei „Copy projects into workspace“ wieder entfernen und die Prozedur mit einem Klick auf „Finish“ abschließen.

Abschließend benötigen wir noch die CMSIS_CORE library, die wir auf einem ähnlichen Weg importieren. Nach dem Klick auf  „Import project(s) from file system…“ wird dieses Mal die Schaltfläche „Browse“ im Bereich „Project archive (zip)“ betätigt.  Hier sollte die Ordnerauswahl in einem Unterordner der MCUXpresso IDE starten. Dieser Unterordner heißt „Examples“ und beinhaltet unter anderem den Ordner „Legacy“, welcher wiederum den Ordner „CMSIS_CORE“ enthält. In diesem Ordner ist die ZIP CMSIS_CORE_Lastest.zip enthalten. Diese wird ausgewählt und mit einem Klick auf „Next“ bestätigt. Im Auswahlfenster wird nur die CMSIS_CORE_LPC11xx (CMSIS_CORE_LPC11xx/)“ angehakt, alle anderen benötigen wir nicht. In diesem Fall ist auch die Option nicht gegeben die Daten nicht in den Workspace zu kopieren, da es sich bei der Quelle um eine ZIP handelt. Damit wird die CMSIS_CORE in den Workspace kopiert.

Firmware (*.hex) Ausgabeverzeichniss einrichten (optional)

Optional ist es möglich, dass die fertig kompilierten Firmware-Dateien (*.hex) automatisch in einen separaten Ausgabeordner kopiert werden damit man diese nicht immer von Hand erst in den entsprechenden Unterordnern der Applikationen suchen muss. Für diese Funktionen wird u.a. unser post-build-steps Script verwendet, welches die globale MCUXpresso Workspace Build-Variable namens hexDir verwendet. Diese muss zuerst erstellt werden.

Dafür klickt man im Menü auf "Window -> Preferences".

Im sich anschliessend öffnenden Fenster navigiert man zu "C/C++ ->Build -> Build Variables" und klickt rechts auf "Add...".

Die Variable wird unter "Variable name" als hexDir benannt und unter "Value" wird der absolute Pfad zum gewünschten Ausgabeordner eingetragen. Abschliessend klickt man auf "OK".

Zum Abschluss prüfen wir, ob Variable korrekt ist und klicken auf "Apply and Close"

Damit ist die IDE MCUXpresso eingerichtet.

Erste Kompilierung einer Applikation

Für die Kompilierung einer Applikation benötigt man eine zuvor kompilierte sblib. Daher muss diese zuerst ausgewählt werden und für die jeweilige Release/Debug-Version kompiliert werden. Dazu wählt man im Baum links im Reiter „Project Explorer“ den Eintrag „sblib“ an. In der Werkzeugleiste wird der kleine Pfeil neben dem Hammer-Symbol angeklickt und z.B. der Eintrag „Release (Release Build)“ ausgewählt. Dieses startet die Kompilierung der sblib.

Anschließend kann eine Applikation ausgewählt und kompiliert werden. Beispielhaft nehmen wir hier das Projekt „Rauchmelder-bcu1“. Dieses wird durch Anklicken im Baum unter dem „Project Explorer“ ausgewählt und durch einen Klick auf den Pfeil neben dem Hammer-Symbol und der Auswahl des Eintrags „Release (Release build)“ kompiliert.

Sollte dies fehlerfrei durchlaufen, kann die Applikations-Firmware per Programmiergerät/Debugger auf den ARM-Controller übertragen werden.

Debuggen auf dem Controller

Der große Vorteil der JTAG Schnittstelle und der IDE MCUXpresso gegenüber „herkömmlichen“ Mikrocontrollern, wie die bekannten AVRs (z.B. Arduino) ist die Möglichkeit des On-Chip-Debuggings.

Dieses bedeutet, man kann das Programm auf dem Mikrocontroller ausführen, pausieren und stoppen. Zusätzlich hat man die Möglichkeit Breakpoints zu setzten. Damit kann man also die Ausführung des Programms auf dem Controller an einer Stelle unterbrechen, an der man sich gerne die Variablen oder an der Hardware die Pin-Pegel ansehen möchte.

Somit benötigt man nicht an jeder eventuell interessanten Stelle im Code eine serielle Konsolenausgabe. Diese seriellen Ausgaben haben außerdem den Nachteil, dass sie die Programmausführung erheblich verlangsamen.

Um das Debuggen im MCUXpresso zu starten, wird der BLAUE! Käfer im Quickstart Panel unten links im Bildschirm angewählt.

Nun wird der Debugger initialisiert und das Programm auf den Controller übertragen. Anschließend wird das Programm an der ersten auszuführenden Codezeile gestoppt:

Da die sblib die main Funktion beinhaltet, ist dort der Einstiegspunkt in das Programm.

Nun kann man mit den Funktionstasten F5, F6 und F7 durch das Programm durchgehen.

F5: Step Into = jede Zeile Code wird ausgeführt und anschließend gestoppt. Zusätzlich wird in jede Unterfunktion hineingesprungen.

F6: Step Over = Jede Zeile Code wird ausgeführt und scnhließend gestoppt, allerdings wird nicht in die Funktionsaufrufe hineingesprungen

F7: Step Return  = Aus der aktuellen Funktion wird eine Aufrufstufe herausgesprungen. Die aktuelle Funktion wird bis zum Ende ausgeführt und die Programmausführung wird erst in der aufrufenden Funktion gestoppt.

Alternativ zu den Funktionstasten können die Symbole in der Toolbar verwendet werden:

Wenn man nicht die gesamten Schritte durchgehen möchte, bis ein bestimmtes Ereignis auftritt oder eine bestimmte Funktion aufgerufen wird, können Breakpoints gesetzt werden. Diese werden in den Controller übertragen und lassen die Programmausführung stoppen, wenn die Codezeile ausgeführt werden soll.

Dazu wird in der gewünschten Zeile der Codeanzeige links neben den Zeilennummern doppelt geklickt.

Anschließend wird die Codeausführung mit einem Klick auf den grünen Pfeil in der Toolbar gestartet.

Die Codeausführung wird dann gestoppt und mit einem Pfeil neben der Zeilennummer angezeigt.

WICHTIG: Bevor die Debug Funktion erneut ausgeführt wird, unbedingt den roten Stop Button in der Toolbar betätigen. Wenn ohne dieses Vorgehen der blaue Käfer erneut betätigt wird, kommt es zu Fehlermeldungen, da nur ein Debug Kanal zur Verfügung steht und kein erneutes Debugging gestartet werden kann.