Student im Urlaub ☕

Atmel kümmert sich mit kostenloser Software zur komfortableren Entwicklung von Software für die hauseigenen Mikrocontroller ganz gut um seine Kunden. Wenn sie Windows benutzen.

AVR Studio (Homepage, für Windows) kann alles, was das Herz begehrt. Es ist eine Programmierumgebung für C- und Assembler-Programmierer, die zusätzlich das Hochladen und Debugging von Programmcode auf den Chip bietet. Außerdem ist ein Simulator mitgeliefert, der die Analyse des Chips mit dem man arbeitet, stark vereinfacht und veranschaulicht.

Abgesehen davon dass man, nach einer kurzen Phase der Enttäuschung darüber dass Kunden mit anderen Lieblingsbetriebssystemen nicht bedient werden, fast Neid empfindet, stellt sich nach etwas Recherche aber dann doch durchaus heraus, dass das kein Grund ist, auf Windows umzusatteln. Jeder Nicht-User von Windows hat schließlich seine guten Gründe.

Also um überhaupt erst einmal AVR-Mikrocontroller zu programmieren, braucht man Compiler, Bibliotheken, Header-Dateien, Assembler und das Tool zum Hochladen des Codes.

Toolchain

Fink-Nutzer mögen einfach die diversen AVR-Pakete installieren, das geht schnell und einfach. (Mit Paketnamen: avr-binutils, avr-gcc, avr-libc, avrdude). Ich gehe hier nicht weiter auf Fink ein, da diejenigen, die jetzt nicht wissen wie das geht oder was Fink überhaupt ist, sowieso ein paar mehr Seiten an Doku lesen müssten und da ich es selbst nicht so gemacht habe (Beispielsweise deswegen weil der Assembler den ich haben wollte meines Wissens nach nicht per Fink zu erhalten ist).

Objective Development hat ein sehr praktisches Paket herausgebracht: Das Crosspack bietet alle Tools die man braucht. Gleichermaßen für Intel-Macs wie PPC-Macs.

Jetzt steht man zwar noch ohne GUI-Tools da, aber per Konsole kann man schon losprogrammieren. Mit dem Lieblingstexteditor programmiert man drauf los, kompiliert mit “avr-gcc” oder assembliert mit “avra”, lädt das Kompilat mit “avrdude” hoch und mit selbigem Tool ändert man auch die FUSE-Werte. Das ist nicht unkomfortabel, wenn man sich mit Shellscripten und einem guten Texteditor ausrüstet. (Empfehlung: VIM – ist bereits vorinstalliert)

Allerdings fehlen noch Syntax-Highlightning, Code-Completion, Upload-Button, FUSE-Editor, Registerbrowser usw.:

Entwicklungsumgebung

Beim Crosspack sind bereits Xcode-Templates mitgeliefert, aber da ich jene nicht benutze, bleibt das nur nebenbei erwähnt.

Ich kann Eclipse wärmstens empfehlen: Es handelt sich um eine Entwicklungsumgebung, die – da Java-basiert – auf jedem Betriebssystem heimisch ist und Plugins für jede Programmiersprache und beinahe jedes Framework liefert. Sich an dieses sehr umfangreiche Programm zu gewöhnen ist eine gute Idee, da man sich damit nicht an ein Betriebssystem oder Framework oder ähnliches bindet. Die neueste Version für OS X hängt auch nicht mehr vom Carbon-Framework ab, sondern baut die Oberfläche endlich auf Cocoa auf, was viele Vorteile gebracht hat.

Um Eclipse den Umgang mit AVRs beizubringen, braucht man das entsprechende Plugin: AVR-Eclipse. Auf die Installation gehe ich nicht weiter ein, da sie nicht kompliziert ist und eine Anleitung bald ohnehin schnell veraltet sein kann. Das Wiki der Projektseite bietet eine gute Anleitung.

Als nächstes bringt Eclipse allgemein natürlich den Syntax-Parser, die Code-Completion, Syntax-Highlightning, eine schöne Organisationsstruktur für Projekte, Debuggingmöglichkeiten, Symbolbrowser und so weiter.

AVR-Plugin-spezifischer sind der praktische Upload-Button, der AVR-Device-Explorer, in dem man alle Register, Ports und Interrupts chipspezifisch einsehen kann, die Programmer-Integration (über die man den Typ des Mikrocontrollers übrigens inklusive Taktung automatisch auslesen kann) und die Möglichkeit, alles projektspezifisch einzustellen.

Bilder sagen mehr als tausend Worte:

Wer die Arbeit mit Eclipse bereits gewohnt ist, der wird dieses Plugin sicher mögen.

Wenn allerdings schnell mal ohne großes Terminal-Bla FUSEs ausgelesen/geändert, Kompilat hochgeladen oder ähnliches getan werden soll, dann ist es übertrieben, extra ein Eclipse-Projekt aufzuziehen.

Das perfekte Tool hierfür heißt AVRFuses.

Es ist in C#.NET programmiert, was wiederum bedeutet, dass es unter Windows, Linux (mit Mono) und OS X lauffähig ist.

Da es eine Vielzahl von AVR-Chips unterstützt und an sich recht spartanisch ausgestattet (Es kann das was man braucht und mehr nicht) ist, nutzt man es am besten um schnell mal ein paar Bits zu setzen, wenn man fremde Programme in den eigenen Mikrocontroller schicken will oder ähnliches.

Die eigentlichen Features:

• Programme hochladen/auslesen
• EEPROM hochladen/auslesen
• Chip löschen
• FUSE-Bits setzen/auslesen

Screenshots:

Im Studiengang “Elektrotechnik / Technische Informatik / Informationstechnik” an der RWTH Aachen hört man im ersten Semester unter anderem “Grundgebiete der Informatik 1″.

Es geht hier nicht darum, programmieren zu lernen, sondern um Algorithmen und Datenstrukturen. Die offizielle Vorlesungsprogrammiersprache ist C.

An der Uni ist man sich der Tatsache bewusst, dass viele noch nie programmiert haben, also werden in der Globalübung und in den Kleingruppenübungen durchaus ein paar Dinge erklärt.

Die meisten Anfänger benutzen Windows – und sie haben das typische Problem, dass ihr Konsolenfenster ( Unter Windows mehr “Eingabeaufforderung” genannt – das entspricht auch dem lächerlichen Funktionsumfang!) sich sofort nach Ablauf des Programms wieder schließt. Das passiert UNIX-Benutzern nicht, denn sie rufen ihr Programm in der Konsole mit “./meinprogramm” auf, sehen die Ausgabe und landen zurück in der Eingabezeile. Das sieht dann so aus:

tfc@photon u2 % ./aufg3_1_b                                                9:13
[Ausgabe des Programms (...)]
tfc@photon u2 %                                                                     9:13

Nichts klappt sich zu. Wozu auch? UNIX hin oder her – unter Windows ist es unüblich, die Konsole dauerhaft offen zu haben (Weil sie dort nichts kann), also besteht dieses Problem für einen Windowsprogrammierer nunmal.

Viele Windowsprogrammierer setzen deshalb vor dem “return 0;” in ihrem Sourcecode ein kurzes “getchar();” ab. Das ist sogar noch in der stdio.h enthalten, weshalb unnötige Includes wegfallen. Diese kleine Funktion lässt die Konsolenanwendung nach Ablauf des eigentlichen Programms auf die Eingabe eines Buchstaben warten. Was für ein Buchstabe das ist, ist ja völlig egal – das Programm blockiert an dieser Stelle und die Konsole geht nicht zu. Das erfüllt seinen Zweck. Abgesehen davon, dass es UNIX-Programmierer total nervt, weil man ständig Enter drücken muss, um zurück zur Konsole zu kommen.

Gestern allerdings war der erste Kleinübungsgruppentermin für Informatik (Erst letzte Woche wurden die Gruppenplätze verteilt). Hier wurde für die Total-Anfänger noch einmal gezeigt, wie man seinen ersten C-Sourcecode schreibt und kompiliert. Mit wxDev-C++ (oder sowas in der Art) unter Windows. Der Tutor erwähnte das “Zuklapp-Problem” mit der Konsole. Sein Lösungsvorschlag:

Man bindet über “#include <stdlib.h>” die stdlib.h ein und verwendet vor dem “return 0;” am Ende des Programms die Funktion system() mit folgendem Aufruf: “system(“PAUSE”);”. Dies hat zur Folge, dass am Ende des Programms das Programm “PAUSE” aufgerufen wird und die Konsolenausgabe so aussieht:

C:\winDOS\> meinprogramm
[Ausgabe (...)]
Bitte drücken Sie eine beliebige Taste, um fortzufahren…

Ja, toll. Den PAUSE-Befehl gibt es unter UNIX nicht. Weil an der Uni so verantwortungsbewusst Systemunabhängig gelehrt wird, darf ich während meinem Studium die Sourcecodes meiner UNIX-fremden Kommilitonen umhacken, damit sie bei mir überhaupt laufen und später schlage ich mich später im Berufsleben mit Arbeitskollegen herum, die kein wirkliches C können, sondern sich Müll zusammenprogrammieren, den sie sich unter Visual Studio oder so angewöhnt haben.

Ich richte einen Appell an alle Windows-Kommilitonen: Bitte, bitte nutzt Präprozessor-Anweisungen! Mit folgendem kurzen Code kann man sein Programm Plattform-Unabhängig machen:

#ifdef WIN32
system(“PAUSE”);
#endif 

Diese Anweisung bewirkt, dass der Compiler diesen “Windows-Behelf” auslässt, wenn man das Programm überhaupt nicht unter Windows kompiliert.

Bei einem einzelnen Entertastendruck ist das ja alles noch nicht soooo schlimm, aber schlimmere Zeiten werden kommen.