Student im Urlaub ☕

Ich hatte mir dieses Jahr eigentlich vorgenommen, zu Weihnachten als Geschenk eine selbstgebaute “Pulsanzeige” zu bauen, deren Schaltung dann noch in einem dekorativen Gehäuse verbaut werden sollte.  Das “Praktikum Elektrotechnik 2″, an dem ich dieses Semester  teilnehme, befasst sich im vierten Versuch mit Funktionsgeneratoren auf Basis von Operationsverstärkern und Grundschaltungen derselbigen. Jedenfalls brachte mich die letzte Aufgabenstellung der Versuchsdurchführung, nämlich das Verstärken des Pulssignals aus einer Fingerklammer, auf die Idee so etwas mal zuhause nachzubauen und es dann noch “Benutzerkompatibel” für die erwähnte Geschenkidee zu machen. Der Benutzer sollte dann einen Finger in eine Klammer stecken, die seinen Puls über das optische Verfahren abnimmt und die Operationsverstärkerschaltung betreibt dann eine dekorative Lampe die so synchron mit seinem Puls aufleuchtet.

Leider hat es mit der Zeit nicht mehr hingehauen, die Schaltung verschenkfertig zu machen. Es gab ein paar batteriespezifische Probleme und so weiter, von daher habe ich mich nach einem Alternativgeschenk umgesehen.

Bei der Suche bin ich auf eine Reihe Klein-Bastelprojekte gestoßen, die aufeinander aufbauen und sich auf interessantem Wege jeweils verbessern:

Phototransistorschaltung von www.evilmadscientist.com (Bild stammt von dort)

Zunächst ist auf www.evilmadscientist.com eine Bastelei aufgetaucht, die auf sehr minimalistischem Wege LEDs nur in dunkler Umgebung leuchten lässt (Link zum Artikel). Ein anderer Bastler hat auf www.instructables.com veröffentlicht, wie er eine kleine LED-Schaltung insofern mit einem Mikrocontroller erweitert hat, dass sie danach flackert wie eine Kerze (Link zur Anleitung).

Ein weiterer Hobbybastler hat dann auf www.hackaday.com veröffentlicht, wie er diese beiden Ideen kombiniert hat, um LEDs nur im Dunklen flackern zu lassen (Link zum Artikel). Die Schaltung bietet auf diesem Stand einen Mikrocontroller, der sich um das Flackern kümmert und einen Fototransistor, der den kompletten Mikrocontroller abschaltet, wenn das Umgebungslicht zu hell ist.

Fototransistor mit Mikrocontroller verschaltet auf www.spritesmod.com (Bild stammt von dort)

Diese Schaltung wiederum hat der Webmaster von www.spritesmods.com aufgegriffen (Link zum Artikel), weil ihm aufgefallen ist, dass die Schaltung auch mit viel weniger Bauteilen funktioniert, wenn man ein interessantes Detail von LEDs ausnutzt:

Wenn man Licht auf eine LED scheinen lässt, dann produziert sie eine Spannung an ihrer Sperrschicht, die in Sperrichtung abfällt. In diesem Moment kann man die LED wie eine kleine Stromquelle, parallel zu einem Kondensator geschaltet, betrachten.
Der Mikrocontroller nutzt diese Tatsache folgendermaßen aus: Er schaltet in gewissen Zeitintervallen die Beleuchtung ab, beschaltet eine LED hochohmig, damit sich eine Spannung anlegen kann, misst sie und entscheidet dann, ob die Lichter danach weiter leuchten sollen oder nicht. Ferner wird der Mikrocontroller nun nicht mehr ausgeschaltet, sondern legt sich einfach “schlafen” und wacht später für die nächste Messung wieder auf. Das ist immer noch extrem sparsam.

Vereinfachte Schaltung von www.spritesmod.com (Bild stammt von dort)

Alex von www.tinkerlog.com hat diese Idee wiederum aufgegriffen und ihr mit einer künstlerisch anmutenden Freiform-Verlötung der Bauteile einen wundervollen Hauch von Eleganz und Ästhetik verpasst. (Link zum Artikel).

Weil mir die Idee so gut gefallen hat, habe ich mich schnell dazu entschieden, sie nachzubauen, zumal man sowas schön verschenken kann.

Allerdings bot die spritesmod.com-Version der Schaltung und Mikrocontroller-Software eine Möglichkeit, die Schwellhelligkeit, bei der die LEDs noch flackern sollen, einzustellen/zu kalibrieren. Die tinkerlog-Version hat darauf verzichtet, um Platz für ein anderes nettes Feature zu bieten: Wenn man den Mikrocontroller resettet, dann leuchtet jeweils eine andere Anzahl an LEDs, was wiederum sehr passend für die verschiedenen Adventswochen ist.

Die Version die ich nachgebaut habe, bot letzteres Feature nicht, zumal die Adventwochen sowieso schon vorbei waren und ich diese Kalibrierung nicht auslassen wollte, zumal der Benutzer meiner Ansicht nach entscheiden sollte, bei welcher Helligkeit er den Kranz schimmern sehen will.

Jedenfalls habe ich mich heute noch einmal hinter den Sourcecode geklemmt, um Helligkeitskalibrierung und Adventskerzenfunktion zu haben.

Das Flackern der Lichter wird  realisiert, indem einfach verschiedene LED-Helligkeiten die in einem Array gespeichert sind, schnell nacheinander auf den LEDs dargestellt werden. Die Werte sind allesamt möglichst zufällig gewählt, um sich dem praktisch zufälligen Flackern einer Kerzenflamme in den ebenso praktisch zufälligen Luftzügen, die man zuhause so hat, anzunähern.

Im Endeffekt lief es darauf hinaus, dass ich so viele Zufallszahlen aus dem Zufallszahlen-Array herausgelöscht habe, dass beide Features auf den Chip passen. Außerdem habe ich die im EEPROM gespeicherten Werte (Kerzen-Anzahl und gespeicherte Schwell-Helligkeit) in eine .eep Datei ausgelagert, die getrennt auf den Chip geflasht werden kann.

Ein Video zeigt ganz gut, dass es keinen deutlichen Unterschied macht, ob es ~150 oder ~250 Zufallswerte sind, die das Flackern erzeugen. Zwei Abschnitte des folgenden Videos sind mit zwei verschieden großen Zufallszahlen-Arrays gemacht. Um ehrlich zu sein, weiß ich selbst nicht mehr, welcher Abschnitt mit welcher Einstellung arbeitet:

Nun ja, besonders verwunderlich ist das nicht, zumal das Kerzenflackern ja schon mit zwei NE556-Bausteinen gut klappt.

Den Sourcecode inklusive dem angepassen Makefile gibt es hier: Download

Video vom fertigen Aufbau:

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:

Spätestens einen Monat vor Weihnachten war klar: Ich brauche ein Geschenk für meine Freundin.

Es lag sofort nahe, dass ich eins basteln könnte. Basteln ist günstig und macht Spaß. Abgesehen davon ist das Produkt dann ein sehr individuelles Geschenk.

Die eigentliche Idee habe ich zwar irgendwann in der Vergangenheit schon einmal im Internet gesehen, aber ich habe das alles trotzdem einfach mal ohne Pläne von anderen aufgebaut, weil es dann auch lehrreicher für mich war.

Nun, zur Idee: Ich plante, ihr eine Laufschrift, die von LED-Punktmatrix-Elementen dargestellt wird, zu schenken, die in ein leicht milchiges Gefäß von der Größe eines Teelichts eingebaut ist. Oben sollten dann dekorativ kleine Pflänzchen herausstehen.

Also bestellte ich mal los: Die Schaltung selbst würde eigentlich nur aus folgenden Teilen bestehen:

• Europlatine
• Mikrocontroller (AVR ATMEGA8 ist hier völlig ausreichen)
• Zwei 5*7 Pixel LED-Matrizen
• Verbindungsdraht zum Verlöten, da ich darauf verzichtete, die Platine zu ätzen
• Entsprechende Vorwiderstände für die LED-Matrizen

Die Verdrahtung sollte dann recht simpel sein. Zwei nebeneinander gesetzte 5*7-Pixel-Matrizen ergeben eine 10*7-Pixel-Matrix. Wenn man sie “multiplext”, dann braucht man 10 +7 Pins am Mikrocontroller, um sie anzusteuern. Das sind dann also 10 Pins jeweils pro Spalte und 7 Pins jeweils pro Zeile. Laut Datenblatt brauchen die Matrizen (Bezeichnung: Kingbright TA07-11HWA) 2Volt Spannung und 25mA Strom pro LED-Einheit.

Die Betriebsspannung des Mikrocontrollers war dann so ein Problem: Einerseits sollte alles schön klein sein, andererseits bräuchte ich alleine drei Mignon-Zellen für nur 4,5Volt. Das wäre nicht mehr so optimal dimensioniert für ein Teelicht-großes Geschenk. Tests mit einem kleinen Prototypen der Schaltung ergaben, dass der Mikrocontroller bei 3V Spannung noch problemlos arbeitet! Also habe ich mich dazu entschlossen, einfach mit zwei Mignonzellen zu arbeiten und fertig. Bei höheren Arbeitstakten des Mikroprozessors wäre das wohl problematisch, aber bei 1MHz ist das in Ordnung.

Da die Schaltung nicht wirklich kompliziert ist, habe ich sie direkt auf Platine gebannt, um die Software direkt los schreiben zu können, ohne das später noch Hardware-Änderungen aufgrund von Umständen, die ich vorher eventuell nicht bedacht habe, auftauchen. Software-Entwicklung macht viel mehr Spaß, wenn sich nicht ständig etwas ändert…

Der fertige Aufbau:

Kein Inbegriff von Ordnung

Für die nächste Schaltung werde ich ganz sicher bunte Drähte benutzen.

Als nächstes sollte die Software folgen. Da das Display 7 Pixel hoch ist, erdachte ich mir einen Zeichensatz (mit Alphabet und ein paar Sonderzeichen), in dem alle Buchstaben 7 Pixel hoch und vier Pixel breit sind, so dass man einfach ein C-Character-Array (8 Bit sind eins zu viel – egal, also verschenkt!) anlegt, das 4*Anzahl_der_Zeichen Felder lang ist.

In einem anderen Array sollten dann später die Buchstabenfolgen stehen, die auf dem Display tatsächlich angezeigt werden. {1, 2, 3} wäre demnach “ABC”.

Notation folgt der Abbildung der Matrix-Verdrahtung

Die Anschlüsse des Displays auf der Platine sind fast wirr über die Ports auf dem Mikrocontroller verteilt, obwohl ich mich bemüht habe, sie an möglichst wenige Ports zu verbinden, um möglichst wenig Bitshifterei zu haben.

Die Spalten sollen HIGH-Pegel bekommen, die Zeilen LOW-Pegel. Das Programm schaltet zunächst alle Spalten auf LOW, steuert die Spalten bitmustergerecht an und gibt der entsprechenden Spalte dann HIGH-Pegel.

In festen Zeitintervallen wird die ganz rechte Spalte in die Spalte links daneben kopiert und aus dem Zeichensatz-Array das passende nächste Bitmuster wieder in die Spalte ganz rechts gesetzt, was prinzipiell wie ein Schieberegister funktioniert. Die Prozesse der Anzeige und der Zusammensetzung der darzustellenden Pixel finden getrennt statt, wodurch man Bildaufbaurate und die Geschwindigkeit der Laufschrift problemlos unabhängig voneinander einstellen kann.

Ab dem Punkt, ab dem alles funktionierte, konnte ja mit dem Einbau in den dekorativeren Teil des Geschenks begonnen werden, was eigentlich auch einfach nur mittels Heißkleber und Origami-Anleitungen geschah :

Den C-Sourcecode gibt es hier zum Download.

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.