Das BakUBoot

 

	2. Warum tat das Not?
	Seit den frühesten Anfangszeiten meiner AVR-Bastelei begleitet mich mein Programmieradapter, mit dem ich mittels des kostenlosen Programms PonyProg meine Programme in meine AVRs brennen konnte. Das geht bis heute noch, auch das fette Mopped 2560 kann ich damit brennen.  Will ich aber garnicht mehr!!!  Das ist so Kacke! Hat man schon beim ATMega8 manchmal sehnlichst auf den Fortschrittsbalken gestarrt, während das neueste Programm geladen wurde, das nun endlich mal laufen würde...  Bei 8k Flash. Und nun das ganze bei 256k! Das war ja noch nicht mal das Programmieren, das ging rechtschaffen schnell. Chip Erase und alles neu flashen, Ratz-Fatz!  Doch dann kam der Verify.  Um mir nach 2Minuten, 40 Sekunden seine MessageBox ansehen zu müssen: "Write failed" Und man kann das 'Verify' nicht abschalten. Man kann das 'Verify' natürlich auch vorher abbrechen, denn egal, ob das Brennen geklappt hat oder nicht: Da steht immer 'Write failed'. Und warum das Brennen meistens geht, und trotzdem die Fehlermeldung erscheint, man weiß es einfach nicht... Natürlich gibt es auch andere Programmiersoftware, z.B. AVRDude. Aber als ich einen Blick in dessen .cfg-File warf, dachte ich nur: Ach du Scheiße! Mit solchen behinderten Deppen hast du es schon den ganzen Tag zu tun. Da wirst du aber dafür bezahlt! Nee, hatte ich echt keinen Bock drauf. Ist auch ein reines Kommandozeilenprogramm, das dann irgendwas ganz unten am Paralleport rumfrunselt... Dazu muß man aber unter XP vorher 'giveio' installiert haben, na Mahlzeit!  Bis das rundläuft, ist Weihnachten!  Und ja, das war der wahre Grund, das BakUBoot und den BakuLoader zu schreiben:  Die Weihnachtsferien stehen bevor! Das wird eine schöne Zeit, in der ich endlich mal nicht nur zum Basteln kommen werde, sondern auch den Kindern und allen anderen Lieben Aufmerksamkeit schenken und mich auch mal ein wenig um den Haushalt, den Keller und alles andere kümmern werde. Und eben auch viel Basteln! Solche Zeiten sind ja sehr spärlich gesät und allemal viel zu schade, um sie mit dem Blick auf minutenlange Fortschrittsbalken und 'Verify failed'-Dialogboxen zu schauen. Und das beste: Man kann zwar beim Fortschrittsbalken 'Verify..' auf 'Cancel' klicken, das wird aber mit 2 Dialogboxen bestraft: 'Verify failed' und 'Program failed', obwohl das meistens garnicht wahr ist.  Und dieser Irrsinn: Es wird das gesamte Flash verifiziert, welches insbesondere wenn man zu Anfang noch kleine Testprogrämmchen laufen läßt, nur in den allerersten Pages überhaupt etwas enthält. Und auch später: Wenn in irgendwelchen Sektoren schon irgendwas steht, was interessiert mich das? Mein Programm greift nur auf Speicherstellen zu, die es kennt. Und das steht alles im .hex-File drin. Das soll in die Sektoren, wo es hingehört. RAM muß man sowieso initialisieren und ungeflashtes ROM interessiert kein Schwein. Und wenn meine Software einen Fehler hat und sich trotzdem daran vergreift, dann ist es sowas von völlig Wumpe, ob da 0xFF oder 0x41 drinsteht! Und denn noch bei einer Harvard-Maschine... Ein richtig guter Programmer müßte einfach nur: Das frisch erzeugte Compilat auf den Compi laden...  aaarrgghhh... Also: Programm schreiben, compilieren, starten. Daß es dazu zunächst einmal in das Flash der Zielmaschine geschrieben werden muß, ist ja im Grunde nicht mein Problem. Ich mein, ich weiß das ja. Auch, daß das ein wenig dauert. Abschweifung: Als ich noch jung war, wurden die Programme noch in EPROMs gebrannt. (Ich hatte als erstes einen 2708, der -5V, Masse, +5V und +12V zur Versorgung brauchte, aber schon für die damalige Zeit immense Mengen an Daten aufnehmen konnte, später kam dann der nur ein wenig mehr als doppelt so teure 2716 auf den Markt, der doppelt soviele Daten speichern konnte und nur noch GND und +5V brauchte! Wie jubelten damals die Bastlerherzen in aller Welt, als es den endlich bei HW-Elektronik in der Eimsbütteler Chaussee gab!)  Wir verwendeten damals in Italien schon 27256. Das Gute an EPROMs ist ja, daß sie sich löschen lassen. (Die Generation der Vorgänger habe ich ja aktiv nicht miterlebt. Zum Glück wohl... Damals gab es PROMs, die man einmal brennen konnte. Davor aber schon ROMs aus handgelöteten Diodenmatritzen oder Ringkernen.) Zum Löschen hatten die ja extra ein Fenster obendrauf, damit man mittels hartem UV-Lichtes die eingesperrten Elektronen aus den Floating Gates prügeln konnte. Die Techniker in Italien hatten auch alle (bis auf den alten Nisio) eine Technikerausbildung und wußten, was da so abgeht mit Mikroprozessoren. Ich hab denn da mit meinem hp64000-Entwicklungssytem und dem Emulator im Testgerät die Programme hingedengelt, und dann sollte das ganze in EPROMs gebrannt und ins Zielsystem eingebaut werden. Da wurde der alte Nisio plötzlich ganz nervös! Er kam aus seiner Ecke und plapperte ziemlich wild. Da habe ich damals eines meiner ersten italienischen Wörter gelernt: 'brusciare'. Er uns also die ganze Zeit nicht von der Seite gewichen, selbst als Feierabend, den er sonst mehr als peinlich genau einhält, längst vorbei war.  brusciare! brusciare!  Wir dann also das EPROM in den Programmer gesteckt, die Daten draufgeladen und auf 'PROG' gedrückt. Als eine Minute später alle mit dem Ergebnis zufrieden waren, war nur der alte Nisio sehr enttäuscht. Er hatte die ganze Zeit durchs Fenster gestarrt, und da war nix zu sehen! Niente! Ho visto niente! Solche Enttäuschung habe ich selten wieder gesehen... Also, das war damals. Aber man sollte draus gelernt haben. Das muß ZACK-ZACK gehen! Damals wäre das ohne Emulator garnicht gegangen, weil vor jedem Test erst ein EPROM hätte gebrannt werden müssen.  Heutzutage könnte man z.B. nur die Pages programmieren, die nicht stimmen. Und auch nur diese verifizieren, weil die anderen ohnehin nicht interessieren.  Und noch besser: man könnte sich merken, was bereits erfolgreich geflasht wurde, und nur die Änderungen neu programmieren. Das würde schon mal viel Zeit sparen. Und denn natürlich die Daten da mit 250kbps rüberrotzen, oder zumindest 230,4, was mehr Standard ist. Seriell muß sein, weil selbst der kleine Mega8 einen UART an Bord hat. Einfach nur 3 Pins an den Käfer anschließen: GND, RxD, TxD. Mit TTL-Pegel. Wenig Drahtgelöte, keine exotischen Interfacechips und kein Kilobyte an Software. Und nicht 299€ für irgendwas, das nachher doch nicht tut, was man will. Dafür bastelt man ja, daß man auch mal Dinge machen kann, die nur man selbst geil finden muß!

	3. Let there be BakUBoot
	Gedacht, getan: Und siehe da! Kaum war das BaUBoot am laufen, dauerte es kaum noch 30 Minuten, bis das Projekt Gestalt annahm, und das BakUBoot die erste Bewährungsprobe überstanden hatte: JO,MAN! Den Riesenfont runterladen! 3 Verschiedene ausprobiert! Einfach mal so, bis das passt. BakUBoot ist echt hurtig! Natürlich erst, nachdem ich auf 1MBit umgestellt habe mit einem 'virtuellen Com-Port' von FTDI. Den hatte ich noch von einem gescheitertem Projekt liegen und habe ihn in ein kleines Plastikgehäuse eingebaut. Verbindung zum Zielsystem über drei dünne Drähte, die ich mal von Ron geschenkt bekommen habe. Geht auch geil und läßt sich auch auf 1000000bps programmieren.  Ging aber rein subjektiv nicht schneller, als mit 115200. Ich dann mein Zweikanalscope an Rx und Tx gehängt, und siehe da: Der olle Mikroprozessor antwortet binnen Mikrosekunden, und der Gigahertzcomputer braucht Äonen....  Ich hab dann die USB-Latenz runtergestellt: BM Einstellungen ist das Stichwort: Hier bei Wartezeit(ms) 1 eingeben. 0 wäre zwar besser, aber man kann nur vorgegebene Werte einstellen.  Dann löppt dat, und die olle XP-Hure ist fast genau so schnell wie ihr Vetter aus reinem Silizium! Plöck! ist das Programm drauf, samt den ganzen großen Fonts! Das ist geil geworden!

	4. Closed Source
	Das Gute an dieser ganzen Maschine ist ja, daß ich sie gut finde. Weil sie genau das macht, was ich will.  Und sieht auch cool aus. Wenn sie mal nicht macht, was ich will, dann habe ich was falsch gemacht. Dann muß ich das ändern.  Deswegen gibt das hier auch keine Quelltexte, Schaltpläne oder Dokumentationen. Wenn jemand Interesse daran hat, kann ich ihm gerne alles mailen. Muß er aber selber mit klarkommen. Kann natürlich fragen, ich werde bestimmt jeden unterstützen, der sich auch so einen geilen Bootloader basteln will.  Aber zum download anbieten, mit GPL oder PPL oder was haste nicht gesehen für einer Lizenz? Nö. Von der Arbeit mal abgesehen, die es macht, eine Dokumentation, die mir persönlich völlig ausreicht, so aufzuarbeiten, daß sie jeden Hamster zum Nachbau befähigt, kenne ich ja die Spackos dieser Welt: Dann baut einer (ach, wenn es bei einem bliebe...), der kaum weiß, wo beim Lötkloben das heiße Ende ist, den Scheiß nach, und dann geht das nicht. Und der meint dann, ich hätte die Verpflichtung, ihm bei seinem Scheiß zu helfen, nur weil es kostenlos im Internet zum runterladen war... Mit solchen Wichteln habe ich den ganzen Tag bei der Arbeit zu tun, aber da werde ich dafür bezahlt. Zuhause ist BASTELN! So!

	5. Wie man auf 0 geht
	Noch mehr Klugscheiße: Bevor ich mich an diese Seiten machte, mußte ein letztes Problem gelöst werden. Ich hatte davon schon gehört und es mir auch gedacht, daß das notwendig sei und deswegen auch ganz sicher existiert: Nachdem die Vektoren wieder richtig hingebogen sind, springe auf 0. Wie beim Reset.  Ach nee, beim Reset wird ja momentan der Bootloader angesprungen, und die Vektoren sind verbogen... Aber irgendwie muß es gehen... Ich hab da ja auch was im Internet gefunden:  /* vim:fdm=marker ts=4 et ai * {{{ * * (c) by Alexander Neumann <alexander@bumpern.de> * Lars Noschinski <lars@public.noschinski.de> * * Idea and implementation for char startup mode by * Scott Torborg - storborg@mit.edu - August 2006 ...................................... /* prototypes */ void (*jump_to_application)(void) = (void *)0x0000; ...................................... /** move interrupt vectors to application section and jump to main program */ static noinline void start_application(void) /* {{{ */ { /* reset input pin */ BOOTLOADER_PORT &= BOOTLOADER_MASK; /* move interrupt vectors to application section and jump to main program */ _IVREG = _BV(IVCE); _IVREG = 0; jump_to_application(); } /* }}} */ Das funktionierte natürlich mit meinem Compiler nicht, deswegen habe ich es mal einkondensiert: /* move interrupt vectors to application section and jump to application program */ MCUCR = (1<<IVCE);    // Enable Vector change MCUCR = 0;            // Vectors back to normal... asm volatile("jmp 0");  Und das funktioniert. Ich mein, was gibt es an 'JMP 0' nicht zu verstehen? Abstraktion? Das heißt doch nur, die Sicht der Dinge auf ein Maß zu reduzieren, das auch der Dümmste noch verstehen kann oder zumindest verstehen können sollte. Damit auch ja nichts passieren tun kann. Oder den ganzen Quelltext mit Sonderzeichen (:* {{{ */ {) zurotzen, damit Doxygen aus dem blöden Geschwafel automatisch eine Dokumentation generieren kann, denn wir sind modern! Da muß keine Sau mehr das Zeichenrumgerotze verstehen, die Maschine wirds schon richten, wenn wir bloß alle Verfahrensanweisungen, Prozeßdefinitionen und 'Best Practices' anwenden, dann wird alles gut! Hallelujah!

<< zurück

Zur Übersicht

weiter >>