ARMed

Heute wurde es mal Zeit sich etwas mit der Stromaufnahme des LPC2148 auseinanderzusetzen - da das endgültige Modul später mit einem Akku betrieben werden soll - ein nicht unwesentlicher Punkt. Laut UserManual sollte der Arm ungefähr 1mA pro MHz aufnehmen. Bei dem hier vorgesehen Betrieb mit 60 MHz sollten es also um die 60mA werden bei 3,3V. Erstes Hindernis bei diesem Messunterfangen war die Spannungsregelung des Olimex Boards. Da ich von Spannungsreglern & co. nur marginale Ahnung habe, ist es mir nicht möglich den Spannungsregler aus der Stromaufnahme rauszurechnen. Also bin ich einen anderen Weg gegangen und habe den Spannungregler kurzerhand vom Board gelötet und den Arm direkt mit einem Labornetzteil über den 3,3V Pin versorgt. Dazwischen habe ich noch ein Multimeter gehängt - mit mässigen Erfolg. Da der Innenwiderstand des Multimeters bei einer Messung im mA-Bereich anscheinend zu gross war, wollte der Arm nicht vernünftig starten und eine Messung war nicht möglich. Dank eines fachkundigen Tipps aus der Uni habe ich einfach mal den 10A Eingang anstatt des mA Eingangs des Multimeters versucht und siehe da: funktioniert.
Leider war das Ergebnis der Messung alles andere als befriedigend. Statt der erwarteten 60mA genehmigte sich der ARM satte 110mA, beim Transfer von der SD-Karte sogar 140mA. Bevor ich diesen hohen Werten auf den Grund gehen wollte, standen erstmal noch die Messungen der beiden Energiesparmodi an. Laut Datenblatt sollten es im Powerdown-Modus nahe 0mA sein.
Gemessen habe ich im Powerdown-Modus dann immer noch 50mA und im Idle-Modus 70mA. Woran diese krasse Abweichung vom Datenblatt liegt, konnte ich nicht wirklich ergründen. Ich habe alle IO-Pins (wo möglich) auf Out 0 gestellt, den R232Max runtergelötet und die LEDS ausgeschaltet, ohne wirklich merkbare Änderung. Da auch bei gedrückten Reset-Schalter um die 50mA aufgenommen werden, denke ich trotzdem dass es irgendwie am Olimex Board liegt und nicht am ARM selber. Zieht man diese ominösen 40-50mA von allen gemessenen Werten ab, kommt man den Datenblattwerten schon recht nahe.

Auf wiki.sikken.nl gibt es einen USb-Stack der ohne größere Anpassungen auf dem Olimex-Board lauffähig ist. Die Sourcen sind sehr strukturiert und machen einen ausgereiften Eindruck. Damit konnte ich USB sowohl als virtuellen COM-Port mit allen Datenraten als auch als Massenspeicher (USB-Stick) benutzen. Probleme bereitet mir lediglich die Massenspeicheroption in Verbindung mit den beiden Stromsparmodi des Arms. Ich schaffe es noch nicht beim "Aufwachen" die USB funktionalität widerherzustellen.
Wenn weitere Tests den positiven gesamteindruck bestätigen, werde ich diesen USB-Stack wohl in mein Projekt übernehmen.

Bevor ich hier mit den ersten Schritten und dem HelloWorld() der Microcontroller-Programmierung - nämlich dem LED Blinken - anfange, möchte ich erstmal auf die Einrichtung einer Entwicklungsumgebung (IDE) eingehen.
Als ich das Paket von Olimex zum ersten mal öffnete ging ich noch davon aus, dass eine komplette IDE enthalten ist und ich nach wenigen Klicks loslegen und über JTAG debuggen könen würde. Doch weit gefehlt. Lassen sich die Yagarto Pakete von der CD noch ohne Probleme installieren und so eine IDE auf Basis von Eclipse noch relativ problemlos einrichten, so ist das Einrichten der Debug-Umgebung auf Basis von openOCD umso schwieriger. Das liegt vor allem an dem von Olimex gelieferten Tutorial in Form eines PDFs, welches leider extrem veraltet ist. Eine neuere Version gibt es auf deren Homepage, doch diese Version ist leider für ein DevBoard der Konkurrenz. So weit so schlecht.
Nach zwei Wochen googlen und mailens mit diversen Entwicklern hab ich es bis heute nicht hinbekommen, eine Debugumgebung einzurichten oder über JTAG auch nur zu flashen. Nach anfänglichem Frust und Diskussion an der Uni ein anderes Board (und JTAG Interface) zu nutzen, sind wir allerdings schnell zu dem Schluss gekommen, daß JTAG Debugging kein lebenswichtiges Feature ist und wir wie bisher (Beim MSP430) auch über die serielle Schnittstelle debuggen können. Blieb nur noch die Frage, wie die Software denn nun in den Microcontroller kommt, wenn nicht über JTAG? Hierzu bin ich schnell fündig geworden und nutze mitlerweile seit einigen Wochen das kostenlose Tool Flashmagic, was bisher ohne Probleme funktioniert. Nachdem dies nun geklärt ist bleibt immer noch die Frage nach den ersten Schritten. Ich könnte hier jetzt einiges über Makefiles und Linkerscripte schreiben, will mir dies an dieser Stelle jedoch erstmal verkneifen und lieber direkt loslegen. Dazu wird in Eclipse ein "Managed c Projekt" eingerichtet und ich muss mich so um das Makefile erstmal nicht mehr kümmern, sofern ich einige Grundeinstelungen vornehme.
Diese Grundeinstellungen befinden sich alle unter dem Menüpunkt "Propertys" im Kontextmenü unseres neuangelgten Projektes in der Projektansicht (linke Spalte in Eclipse). Hier interessiert uns erstmal nur der Punkt "c++ Build". An dieser Stelle müssen wir Eclipse mitteilen wie es unsere Binaries zu bauen und zu linken hat. Erstmal tragen wir als "command" unter "GCC C Compiler" "arm-elf-gcc" ein, dessen Binaries sich nach der Yargato Installation ansich im Pfad befinden müssten. Dann tragen wir bei "Other Flags" unter "Micellaneous" noch "-mcpu=arm7tdmi -Os -c " ein. Das "-Os" ist ein optimierungs Level der noch kleineren Code als "-O3" erzeugt.
Nun nehmen wir uns den Linker vor und tragen bei "Command" auch wieder "arm-elf-gcc" ein. Unter "Linker Flags" bei "Miscellaneous" tragen wir "-T ../lpc2148-rom.ld --warn-common" ein. Das Linkerscript "lpc2148-rom.ld" liegt bei mir in der Projektdir. Wenn das bei euch anders ist, muss der Pfad evtl angepasst werden. Das Linkerscript ist ein Standardscript was ich leicht modifiziert habe, damit malloc() ohne weitere Probleme funktioniert - ihr findet es hier in der Codesammlung. Des weiteren muss noch dafür gesorgt werden, dass beim Linken die crt.o zuerst gelinkt wird. Am einfachsten geht das in dem das "Command Line Pattern" folgenermassen umgestaltet wird "${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT} crt.o ${INPUTS}". Nun bleibt nur noch die Frage offen, wo die crt.o denn herzubekommen ist. Diese wird aus der Datei crt.s assembliert wenn als "GCC Assembler" "arm-elf-as" eingetragen wird und als "Assembler Flags" "-ahls -Wa -mapcs-32" gesetzt werden. Diese Datei befindet sich ebenfalls in der Codesammlung.
Als letzte Hürde ist jetzt noch zu nehmen, dass mit diesen EInstellungen ein .elf binary generiert wird - Flashmagic aber gerne ein .hex Binary hätte. Nichts leichter als das: Unter "Build-Steps" wird als "post build" command einfach "arm-elf-objcopy -O ihex Arm.elf Arm.hex" eingetragen und fertig ist's.
Wenn das Linkerscript und die crt.s im Projektverzeichnis liegen, kann nun direkt mit dem ersten kleinen Programm angefangen werden.
Doch dazu mehr im nächsten Teil.

Da ich mich im Zuge meiner Diplomarbeit intensiv mit dem LPC2148 von NXP beschäftigen werde und mich in diese Thematik (ARM) komplett neu einarbeiten muss, habe ich mal dieses Blog eingerichtet. Hier werde ich in unregelmäßigen Abständen meine Erfahrungen und Codebeispiele präsentieren. Nach einer kurzen Erkundungsphase der Hardware soll eine SD-Karte angesprochen werden und das FAT-Filesystem implementiert werden. Später kommt noch ein Funkchip (CC1100) dazu welcher über ein DSR Derivat (hab ich die letzten Semester noch für einen MSP430 entwickelt) mit anderen Nodes kommunizieren soll. Das ganze soll über USB den Inhalt der SD-Karte auch als Massenspeicher zur Verfügung stellen und neue Firmwares auf diesem Wege annehmen.
Wie ich mich kenne werden aber im Laufe der Zeit aber auch das ein oder andere Hardwareexperiment oder Zweckentfremdung hier landen.
In den ersten Wochen wird noch das Evalboard von Olimex hier eingesetzt, später dann eine eigene Platine.