Monthly Archives: October 2011

AT91Boot_DLL-API-Aaaaargh-Anfall

Atmel ist so nett für seine auf ARM basierenden Microcontroller eine Software mitzuliefern, mit der man den Controller sozusagen in Betrieb nehmen und den angeschlossen RAM und Flash testen und bespielen kann, nennt sich SAM-BA. Enthalten ist eine Bibliothek namens AT91Boot_DLL.dll, deren API ganz brauchbar dokumentiert ist. Sucht man noch ein wenig quer, stößt man auch auf AT91-ISP, wo es zwei Beispielprojekte gibt, wie man die Bibliothek in eigenen Projekten nutzen kann. Der Vorteil an der Bibliothek ist, dass man sich um die Verbindung zur ARM-CPU via USB oder serieller Schnittstelle keine Gedanken machen muss, man ruft einfach die Funktion AT91Boot_Scan() auf und lässt die DLL suchen. Das Code-Beispiel aus der Dokumentation sieht so aus:

Beim Betrachten der Funktionsparameter hatte ich bereits letzte Woche den Verdacht, dass das mal krachen könnte, wenn man hier der Bibliothek gar nicht sagen kann, wie lang die Liste jetzt wirklich ist, die man da reinfüttert. Im Beispielprojekt umfasst die übrigens 10 Elemente und das änderte ich Freitag nachmittag noch auf 5. Funktionierte Freitag auch, so weit so schön.

Montag, also heute, stieg die Anwendung dann reproduzierbar mit einer Access Violation in der msvcrt.dll aus beim Aufruf dieser Funktion. Klassisch: »Es geht nicht mehr, ich hab aber nichts geändert.«

Etliche Flüche, Tests, Recherchen und dergleichen später stellte sich raus, dass ich doch was geändert hatte: ich hatte heute noch ein, zwei USB-Geräte mehr an meinen Rechner angeschlossen. Die Bibliothek sucht zuerst nach über USB angeschlossenen ARM-Prozessoren und scheint alle aktiven USB-Geräte durchzugehen, 5 Elemente in der Liste haben dann nicht mehr ausgereicht, flugs im Präprozessor-Makro den Wert erhöht und schon läuft das wieder ohne Absturz.

Den Rumpelstilzchentanz, den ich hier aufgeführt habe, weil die ihre API nicht sauber designen können und einen so zur Suche nach so dämlich subtilen Fehlern zwingen, möge sich bitte jeder selbst vorstellen! *motz*

Microsoft Visual C++ 6 und CMake

Warum man eine steinalte Entwicklungsumgebung mit einem modernen Build-System zusammen benutzen will, lässt sich nicht nur mit »Weil es geht!« begründen, es gibt sogar handfeste Argumente dafür, doch der Reihe nach.

Aus Gründen hab ich hier einige MFC-Projekte vorliegen, die in Visual Studio 6 entwickelt wurden, für das hier auch eine gültige Enterprise-Lizenz existiert. Bekommen habe ich Quellcode eines älteren Projekts ohne die Projektdateien. Neu zu entwickeln ist ein vergleichbares Programm und da Entwicklungsumgebung und KnowHow verfügbar sind, wird das neue Projekt eben auch in Visual Studio 6 entwickelt, die Programme laufen ja trotzdem.

Mit CMake füge ich dem Quellcode jetzt einfach die passenden Dateien mit dem Namen “CMakeList.txt” hinzu und lasse mir von CMake ein Projekt für VS6 erzeugen. Vorteil: ich brauche keine Projektdateien im Versionsverwaltungssystem ablegen, kann mir das auschecken wohin ich will und mein Quellcodebaum enthält nur das nötigste. De facto war ich so sogar in der Lage, das alte Projekt, wo mir die Projektdateien fehlten, mit CMake zu bauen und dem auf die Finger zu gucken. Soviel zum »warum«, es folgt jetzt das »wie« …

Zunächst mal sei gesagt, wenn schon Visual Studio 6, dann auch das letzte Service Pack installieren. Ist ein FAQ1 und das Service Pack gibt’s bei Microsoft.

Da ich hier eine MFC-Anwendung entwickeln will, also ein Tool mit GUI, reicht mir der reine Code nicht aus, sondern ist sind noch ressource files nötig. Bevor ich also später die Projektdateien mit CMake generieren lasse, erzeuge ich mit dem Assistenten von Visual Studio ein neues MFC-Projekt, in meinem Fall »Dialogfeldbasierend«:

MFC-Anwendungs-Assistent Dialogfeldbasierend

Den Rest des Assistenten klickt man nach eigenen Vorstellungen durch und dann kann man Visual Studio erstmal wieder schließen. Man hat jetzt einen Ordner vorliegen, in dem folgende Dateien liegen:

von VS6 erzeugte Dateien für ein neues MFC-Projekt

Davon kopieren wir jetzt den Ordner res und folgende Dateien an einen neuen Ort:

  • foo.aps
  • foo.clw
  • foo.cpp
  • foo.h
  • foo.rc
  • fooDlg.cpp
  • fooDlg.h
  • Resource.h
  • StdAfx.cpp
  • StdAfx.h

Das ist jetzt unser neuer Source-Ordner und dort wird nun eine Datei namens CMakeLists.txt angelegt. Fortgeschrittene CMake-Nutzer können das auch auf getrennte Unterordner für Programmcode, Header und externe Ressourcen aufteilen, spar ich mir hier mal und zeige nur wie das mit einer einzigen CMakeLists.txt aussehen kann:

Zu set(CMAKE_MFC_FLAG 2) bitte nochmal selbständig die Doku lesen und nicht verwirren lassen, die dort gezeigten Code-Abschnitte sind aus älteren Versionen vom Installer von CMake selbst kopiert. Wie eingangs angedeutet, machen wir jetzt einen Build außerhalb des Source-Verzeichnisses und rufen dazu das CMake-GUI auf:

CMake GUI für unser Mini-Projekt

Nach einem Klick auf Configure wird man nach dem Generator gefragt. Dort wählt man Visual Studio 6 aus der Liste und bestätigt. Ein weiterer Klick auf Generate erzeugt dann die Projektdateien im zuvor eingestellten Build-Ordner, alles oben im Screenshot zu sehen. Mit einem Doppelklick auf die Datei foo.dsw öffnet sich dann Visual Studio und man kann sein Projekt bauen. Schick auch, dass es gleich ein Unterprojekt gibt, was einem die Anwendung installiert. Theoretisch gibt’s auch noch CPack, womit man sich dann noch gleich einen Installer backen kann, aber das würde jetzt hier zu weit führen. ;-)

das von CMake erzeugte VC6-Projekt

Wenn das alles soweit schön kompiliert, kann man den Source-Ordner so nehmen wie er ist und in das Versionsverwaltungssystem seiner Wahl packen. Projektdateien für Visual Studio generiert sich dann jeder Entwickler selbst mit CMake. Bisschen umständlich ist das später beim Hinzufügen von neuen Dateien ins Projekt, weil man die CMakeLists.txt parallel pflegen muss, aber das ist es meiner Meinung nach wert.

  1. Visual Studio 6 Compiler : Freezing CMake Configuration []