Mikrocontroller.net - Benutzerbeiträge [de]

MMC- und SD-Karten

2011-09-05T21:03:54Z

Niko: Laut http://en.wikipedia.org/wiki/Secure_Digital#Compared_to_other_flash_memory_formats sind alle SD (nicht MMC) Karten SPI kompatibel!

MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell git es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben eine besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD) die zur normalen SD-Card weitgehend kompatibel sind.

Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als SPI-Modi eignen sich somit Mode 0 (CPOL=0, CPHA=0) und Mode 3 (CPOL=1, CPHA=1) (siehe auch [[Serial Peripheral Interface]]). Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor dass der SPI-Modus je nach Karte unterschiedlich gewählt werden muss, oder dass die Karte überhaupt nicht zuverlässig funktioniert (siehe [http://www.mikrocontroller.net/forum/read-1-343528.html Beitrag im Forum]).

== DOs und DON'Ts bei der Ansteuerung ==

* '''Lasst euch nicht verrückt machen''' wenn es einfach nicht funktioniert, sondern probiert zu allererst mal eine SD-Karte eines anderen Herstellers aus. Die MMC-Implementierung für AVR von Elm Chan z. B. funktioniert mit SanDisk problemlos hat aber mit Platinum Karten ein Problem.
* Taktfrequenz bei der Initialisierung nicht höher als 400kHz
* Ein Pullup-Widerstand am Ausgang der MMC/SD Karte (DO) ist für eine saubere Initialisierung per SPI notwendig! [http://www.mikrocontroller.net/topic/112421#1001693 (Thread mit Erklärung dazu)]
* Saubere Versorgung: Kein Dioden-Pfusch, mit dem eine vorhandene 5V Versorgung mittels in Reihe geschalteter Dioden auf irgendwas im Bereich 3V "geregelt" wird. Stattdessen einen guten 3,3V-Regler verwenden. Die Karte mag es nicht, wenn mehr als 60mV Ripple auf Vcc ist. LM317 oder LM1117-ADC/-3.3 mit entspechenden Kondensatoren reicht zumindest bei Basteleien allemal.
* Sauberer Anschluss der Digitalschnittstelle: Spannungsteiler "verschleifen" die Signale bei hohen Frequenzen und die Übertragungsrate muss dann begrenzt werden. Also entweder ein [http://www.mikrocontroller.net/articles/Pegelwandler Pegelwandler] oder gleich an ein 3,3V I/O anschließen.
* Ein Pullup-Widerstand an der Select-Leitung (/CS) schadet nicht und stellt sicher, dass die Karte erst mit Absicht selektiert wird.
* Nachdem die Karte deselektiert wurde (/CS auf high), die Taktleitung noch einige Male pulsen, damit die Karte DO hochohmig/tri-state schaltet (vgl. Chans Erläuterungen).
* Die Karten verfügen weder über einen Reset- noch einen Sleep-Anschluss. Moderne Karten reduzieren bei Nichtbenutzung ihren Stromverbrauch, einen vollständigen Reset kann man jedoch nicht per Software auslösen. Daher sollten die Karten per P-Channel-FET oder Spannungsregler/-wandler mit Enable-Funktion so angeschlossen werden, dass über Versorgung an/aus ein (Power-On-)Reset ausgelöst werden kann. Dabei darauf achten, dass vorhandene Pull-Up-Widerstände bei abgeschalteter Versorgung ebenfalls deaktiviert werden (vgl. z. B. Schaltplan für den Anschluss von SD-Card/MMC per SPI an AVR in Chans Beispielen. Link unten).
* Guter Kontakt im Steckplatz, sehr gut eignen sich mit der Zange verbogene Stiftleisten, oft sieht es aus als ob es "passt", aber es gibt doch keinen Kontakt, daher bei Fehlern: Immer Durchmessen! Auch zu erwähnen wären da alte ISA-Bus Buchsen, die auf jedem alten PC Mainboard drauf sind. Um sicher zu gehen, dass der Kontakt wirklich gut ist, sollte man aber trotzdem SD-Slots benutzen. Diese bekommt man u.a. bei CSD (günstig), Reichelt (teuer) oder aus alten Kartenlesern.
* Guter Kontakt #2: Was sich im übrigen auch sehr gut eignet sind Adapter von MiniSD auf normales SD-Format, um dann MiniSD zu benutzen. Wenn man eine Stiftleiste im 2.54mm-Format oder Lötnägel im selben Format auf der Platine hat, kann man daran wunderbar den SD-Kartenadapter anlöten. Das ist mechanisch recht stabil. Ein kleines Manko ist allerdings, daß dann eine Gold-Lötzinn-Legierung durch die vergoldeten Kontakte entsteht und das soll ja dem Lötzinn langfristig nicht sehr zuträglich sein. Aber für's Hobby funktioniert das wunderbar.

{| border="0"
|-
||[[Bild:SD Steck Stift.jpg]] 
(Liefere Bild in besserer Qualität nach!)
|}

== Bibliotheken zur Ansteuerung ==

* [http://elm-chan.org/fsw/ff/00index_e.html ELM ChaN FatFs] FAT(12,16,32)-Dateisystem. Klein und übersichtlich, hochoptimiert, frei auch für kommerzielle Anwendung. Beispiele für AVR, H8, LPC2k mit MCI u.a. enthalten ("samples"), neuere Versionen mit LFN-Unterstützung. Beispiel für AT91SAM7 inkl. DMA im Projekt [[ARM MP3/AAC Player]]. (siehe auch [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/ M. Thomas' ARM+SD/MMC Seite])

* [http://elm-chan.org/fsw/ff/00index_p.html ELM ChaN Petit FatFS] FAT(12,16,32)-Dateisystem. Sehr klein. Beispiele für AVR.

* [http://sourceforge.net/projects/efsl EFSL] FAT16/32-Dateisystem, unterstützt Partitionen und Superfloppys, Beispielcode für AVR, LPC2000 und AT91SAM7 enthalten (siehe auch [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/ M. Thomas' ARM+SD/MMC Seite])

* [http://www.holger-klabunde.de/avr/avrboard.htm#cf Holger Klabundes FAT16/32] mit Beispielen für AVR MMC/SD und CF, LPC2k mit SPI

* libfat aus dem [http://sourceforge.net/projects/devkitpro devkitpro-Projekt] u.a. LFN-Unterstützung.

* [http://www.mikro-control.de/Joomla/index.php?option=com_content&task=view&id=18&Itemid=30 SD-Logger] - FAT 16, für den privaten Einsatz kostenfrei

* [http://www.mikrocontroller.net/forum/read-4-125350.html MMC-Ansteuerung mit FAT16 von Ulrich Radig]

* [http://www.zws.com/products/dosfs/index.html DOSFS Free FAT12/FAT16/FAT32 Filesystem] "DOSFS is a free FAT-compatible filesystem intended for fairly low-end embedded applications. Intended target systems would be in the ballpark of 1K RAM, 4K ROM or more".

* [http://www.mikrocontroller.net/topic/48481 MMC/SD-Karte mit FAT16 an AVR] von Roland Riegel

* [ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2005/176/Sham176.zip Circuit Cellar FAT16 MMC/SD] mit MMC/SD Hardwaretreiber für MSP430

* [http://www.analog.com "Implementing FAT32 File Systems on ADSP-BF533 Blackfin Processors"] Application Note und Code von ADI

* [http://www.atmel.com/dyn/products/tools.asp?family_id=682 FAT-Code in Atmel's AVR32 UC3 Software-Library]

* [http://www.mikrocontroller.net/articles/FAT32 AVR FAT16/32] Bibliothek mit Wiki. Unterstützt LFN und Ordner Rekursiv löschen. SVN für neuste Version.

* [http://www.embedded-os.de/index.html?pcfat_port.htm pC/FAT driver] "using SPI for sector read/write to MMC/MMCplus/HD-MMC/M-Bridge/SD/SDHC-cards on different platforms"

* [http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html SD Card Interfacing with ATmega8] (FAT32 implementation) by CC Dharmani

* [[AVR FAT32]]

== Allgemeine Informationen ==

* [http://www.digitalspirit.org/file/index.php/obj/docs/sd/ Datenblätter] ( [http://www.digitalspirit.org/file/index.php/obj-download/docs/sd/ProductManualSDCardv2.2final.pdf SD Card Product Manual 2.2] )

* [http://elm-chan.org/docs/mmc/mmc_e.html ELM ChaN - How to Use an MMC]

* [http://elm-chan.org/fsw/ff/00index_e.html ELM ChaN - MMC/SD Benchmarks]

* [http://www.mikrocontroller.net/forum/list-1-1.html?filter=MMC*+SD Beiträge zum Thema MMC/SD im Forum (ca. 200 Threads)]

* [http://www.shop.display3000.com/elektronikmodule/sd-speicherkartenplatine.html Weiter unten im Text (runterscrollen) gibt es interessante Oszi-Bilder zu den oft genannten Spannungsteilern oder Transistorlösungen als Pegelwandler]

* [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784 Microchip Memory Disk Drive System mit FAT32 und SDHC Unterstützung]

* [http://www.ifas.htwk-leipzig.de/easytoweb/download/D&E_11_2006_Anbindung_von_SD-Karten.pdf Gute Beschreibung der SDIO-Architektur und wie man eine SD-Karte mit ARM bzw. AVR benutzt]

== Bauteile ==

* [http://www.instructables.com/id/EZD6Q18LYGES1762SJ/ DIY SD-Card Fassung aus einem alten Floppy Kabel]

* [http://www.watterott.com/index.php?page=search&page_action=query&desc=on&sdesc=on&keywords=multicomp&x=0&y=0 Halter für SD-Karten] (Shop www.watterott.com)

* [http://www.shop.display3000.com/elektronikmodule/sd-speicherkartenplatine.html günstige Komplettlösung mit bidirektionalem Pegelwandler, Spannungsregler, Kartenhalter]

== Projekte ==

* [http://retromaster.wordpress.com/ufe/ Ultimate Floppy Emulator] von Retromaster (PIC32 @ 80 Mhz, 16 Mb SDRAM)

[[Category:Bauteile]]
[[Category:Datenübertragung]]
[[Kategorie:Speicher und Dateisysteme]]

AVR Bootloader in C - eine einfache Anleitung

2011-09-03T11:37:29Z

Niko: /* Schritt 4 - Ausprobieren der Anwendung */

Dieser Artikel soll dazu dienen, das Thema [[Bootloader]] im AVR etwas zu demystifizieren.

Es gibt schon einige Artikel und Codebeispiele für verschiedene Bootloader in Assembler oder C (bzw. gemischt), aber kein Artikel beleuchtet das Thema von einer einfachen Seite aus Anwendungssicht. In diese Lücke zielt dieses Tutorial.
Es soll anhand von Beispielen einen möglichst einfachen, verständlichen und nachvollziehbaren Weg zeigen, sich mit Hilfe der Hochsprache C in das Thema einzuarbeiten (dabei soll weder Assembler noch Inline-Assembler verwendet werden).

Vielleicht werden einige meinen dass es nicht möglich ist das Thema ohne tieferen Einblick in die Hardware und die AVR-Register zu beleuchten, ich möchte es aber trotzdem versuchen.

Der Artikel wird sich auf das notwendige Wissen beschränken, um mit Booloadern arbeiten zu können. Es wird ein genereller Weg gezeigt, der sich leicht auf andere AVR-Devices (mit Bootloader Sektion) übertragen lässt.
Die Codebeispiele wurden für den ATmega88 kompiliert und getestet.

== Einleitung ==

Zu Beginn soll das notwendige Wissen über die Bootloaderunterstützung im AVR vermittelt werden, um eine Arbeitsgrundlage zu schaffen.

Im weiteren Verlauf des Artikels werden insgesamt drei Anwendungen programmiert: Zuerst ein einfacher Bootloader, welcher in der Bootloadersektion des Flashs ausgeführt wird, aber noch keine eigentliche Bootloader-Funktion hat, sozusagen ein "Hallo Welt"-Bootloader. Danach soll eine kleine Applikation programmiert werden, welche der spätere ''echte'' Bootloader ins Flash programmieren soll. Als großes Finale soll dann ein Bootloader entstehen, welcher in der Lage ist, Intel-HEX-Dateien über die serielle Schnittstelle zu laden, ins Flash zu programmieren und zu starten.

Der Leser sollte bereits Erfahrungen im Umgang mit dem AVR Studio und der Programmiersprache C gemacht haben und schon Anwendungen geschrieben haben. Für absolute Einsteiger ist der Artikel ungeeignet.

Den Thread zum Artikel gibt es hier: http://www.mikrocontroller.net/topic/195102

== Software ==

Für den Artikel werden folgende Software-Pakete benötigt:

* aktuelles [http://http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] (hier verwendet: AVR Studio v4.18)
* aktuelles [http://sourceforge.net/projects/winavr/files/ WinAVR] (hier verwendet: WinAVR20100110)
* [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] als serielle Konsole (Version v0.6)

Des weiteren wurde auf der AVR-Seite für die serielle Kommunikation mit dem PC auf die beliebte UART-Library von [http://www.jump.to/fleury Peter Fleury] zurückgegriffen, damit wir uns nicht um die gepufferte UART-Kommunikation kümmern müssen.

== Hardware ==

Für den Artikel wurde eine kleine Hardware bestehend aus einem [http://www.atmel.com/dyn/products/product_card.asp?part_id=3302 Atmega88] und einem [http://www.ftdichip.com/Products/ICs/FT232R.htm FT232] als USB-Seriell-Wandler erstellt. Dies soll als Basis für die Experimente dienen. Der USB-Seriell-Wandler ist nicht zwingend notwendig und kann auch durch den üblichen Pegelwandler vom Typ [http://www.maxim-ic.com/datasheet/index.mvp/id/1798/ln/en MAX232] ersetzt werden, wenn der PC noch eine serielle Schnittstelle besitzt. Entscheidend ist nur die Möglichkeit der seriellen Kommunikation mit dem Rechner.

[[Bild:Schaltplan-ATmega88-USB.png|800px|Schaltplan]]

Für die ISP-Programmierung wurde der [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808 AVRISPmkII-In-System-Programmer] von Atmel verwendet. Es kann natürlich auch ein anderer Programmer (z.B. [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 STK500]) verwendet werden, welcher mit dem AVR Studio zusammenarbeitet. Prinzipiell kann natürlich auch ein selbstgebastelter Parallel-Programmer verwendet werden, dann kann aber nicht via AVR Studio programmiert werden, sondern mit [http://www.nongnu.org/avrdude/ AVRDude] oder [http://www.lancos.com/prog.html PonyProg] o.ä. Der Artikel beschränkt sich auf die Verwendung vom AVR Studio.

Für das Verständis der Hardware und der seriellen Kommunikation sind folgende Artikel empfehlenswert:

* [[AVR-Tutorial: UART]]
* [[RS-232]]

= Grundlagen =

[[Bild:AVR-Memory.png|400px|thumb|Flash Speicher Aufteilung]]

Was ist eigentlich ein Bootloader und was macht er? Wofür sollte ich so etwas brauchen? Ist das nicht viel zu kompliziert? Ich bin eingefleischter AVR Studio-Benutzer, muss ich mich jetzt mit makefiles beschäftigen? Kann man im AVR Studio mit C überhaupt einen Bootloader schreiben? Vielleicht hat sich der eine oder andere schon einmal diese oder ähnliche Fragen gestellt.

Der Programmcode des AVR steht in seinem Flashspeicher und wird von dort ausgeführt. Normalerweise kann während der Ausführung des Programms nicht auf den Flashspeicher geschrieben werden. Dies ist auch einleuchtend da sich das Programm ja sonst selbst überschreiben oder löschen könnte. Das Beschreiben des Flashs erfolgt beim AVR üblicherweise über die ISP-Schnittstelle, dabei befindet sich der Controller im Reset und es wird kein Programm ausgeführt. Dies ist für Prototyping und kleine Anwendungen hinnehmbar. Ist der Controller allerdings in einem größeren System oder in größerer räumlicher Entfernung verbaut und die ISP-Schnittstelle nicht mehr zugänglich, ist ein Update der Firmware nicht mehr ohne Weiteres möglich oder sehr teuer und aufwendig. Hier kann ein Bootloader Abhilfe schaffen, in dem er das Anwendungsprogramm auf einer definierten Schnittstelle entgegennimmt (UART, I2C, Wireless) und ins Flash transferiert. Ein Bootloader ist also in erster Linie ein kleines Programm, welches in einem besonderem Teil des Flash steht - der '''Boot Loader Section'''. Durch die Lokalisierung des Bootloader-Programms in dieser besonderen Sektion des AVR ist es dem Programm möglich, auf Teile des Flashs - der sogenannten '''Application Flash Section''' - zu schreiben. Die eigentliche Anwendung wird ausschließlich in der '''Application Flash Section''' ausgeführt. Wenn man so will, können im Flash des AVR also zwei unabhängige Programme stehen. Der Flash ist in zwei Bereiche mit unterschiedlichen Merkmalen aufgeteilt (siehe Bild). Auf die RWW bzw. NRWW-Sektion möchte ich an dieser Stelle (noch) nicht eingehen.

Wie man unschwer erkennen kann, liegt der Bootloader-Bereich am Ende des Flash-Speichers. Normalerweise startet der Controller die Abarbeitung seiner Programmierung an der Stelle 0x0000. Ein Bootloader soll ja aber '''vor''' der Abarbeitung der eigentlichen Applikation ausgeführt werden. Woher weiß also der AVR-Controller nach dem Reset, dass er nicht von Adresse 0x0000 sondern einer anderen Adresse starten soll? Diese Konfiguration ist wie alle wichtigen und grundlegenden Konfigurationen über die Fuses des AVRs geregelt. Wir beginnen mit der folgende Tabelle, welche die Speicheraufteilung des Programmspeichers veranschaulicht.

{| border="1" class="wikitable"
|+ Boot Size Konfiguration, Tabelle 26-6 im Atmega88-Datenblatt S.280
|-
! BOOTSZ1 || BOOTSZ0 || Boot Size || Pages || Application Flash Section || Boot Loader Flash Section || End Application Section || Boot Reset (Start Boot Loader Section)
|-
| 1 || 1 || 128 words || 4 || 0x000 - 0xF7F || 0xF80 - 0xFFF || 0xF7F || 0xF80
|-
| 1 || 0 || 256 words || 8 || 0x000 - 0xEFF || 0xF00 - 0xFFF || 0xEFF || 0xF00
|-
| 0 || 1 || 512 words || 16 || 0x000 - 0xDFF || 0xE00 - 0xFFF || 0xDFF || 0xE00
|-
| 0 || 0 || 1024 words || 32 || 0x000 - 0xBFF || 0xC00 - 0xFFF || 0xBFF || 0xC00
|}

Um die Tabelle zu verstehen muss man wissen, dass der Flash-Speicher intern in sogenannten ''Pages'' (Seiten) organisiert ist. Die Multiplikation der ''Page''-Größe mit der Anzahl der ''Pages'' ergibt die Speichergröße. Die Größe einer ''Page'' steht im Datenblatt und ist in ''Words'' - also Datenworte - angegeben. Ein Datenwort entspricht zwei Bytes. '''''Hier offenbart sich eine Tücke des Datenblatts: Alle Speicherbezüge und Adressen sind in Datenworten (also immer 2 Bytes) angegeben!'''''
Aus der Tabelle erfahren wir auch, dass man mit den beiden Fuses '''BOOTSZ0''' und '''BOOTSZ1''' die Größe des Bootloaderbereichs einstellen kann. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über die Aufteilung der Pages und die Anzahl der Datenworte einer Page.

{| border="1" class="wikitable"
|+ No.of Words in a Page and No.of Pages in Flash, Tabelle 27-9 im Atmega88-Datenblatt S.288
|-
! Device || Flash Size || Page Size || PCWORD || No. of Pages || PCPAGE || PCMSB
|-
| Atmega88 || 4K words (8 Kbytes) || 32 words || PC[4:0] || 128 || PC[11:5] || 11
|}

Aus der Tabelle ergibt sich, dass die Größe einer ''Page'' des verwendeten Atmega88 32 ''Words'' - also 64 Byte sind. Insgesamt gibt es 128 ''Pages'', damit ergibt sich nach Adam Riese 128 * 64 = 8192 Byte, also 8 Kbytes. In unserem späteren Codebeispiel soll die Größe des Bootloaderbereichs auf 1024 ''words'' - also 2048 Bytes gestellt werden ('''BOOTSZ0=0''' und '''BOOTSZ1=0'''). Nun können wir ausrechnen, in welcher Flash-''Page'' bzw. an welcher Flash-Adresse der Bootloaderbereich beginnt: Er beginnt in der 96 ''Page'' (128 - 32) an ''Word''-Adresse 0xC00, also Byteadresse 0xC00 * 2 = 0x1800. Dies ist die exakte Startadresse unseres Bootloaderbereiches.

Weiter oben wurde die Frage gestellt, woher der AVR weiß, an welcher Stelle (entweder 0x0000 oder in unserem Fall 0x1800) er nach dem Reset starten soll. Um dem AVR dies mitzuteilen, ist eine weitere Fuse nötig - die '''BOOTRST'''-Fuse. Eine weitere Tabelle aus dem Atmega88-Datenblatt gibt Auskunft über diese Fuse.

{| border="1" class="wikitable"
|+ Reset and Interrupt Vectors Placement in Atmega88, Tabelle 11-3 im Atmega88-Datenblatt S.58
|-
! BOOTRST|| IVSEL || Reset Adress || Interrupt Vectors Start Adress
|-
| 1 || 0 || 0x000 || 0x001
|-
| 1 || 1 || 0x000 || Boot Reset Address + 0x001
|-
| 0 || 0 || Boot Reset Address || 0x001
|-
| 0 || 1 || Boot Reset Address || Boot Reset Address + 0x001
|}

Mit der '''BOOTRST'''-Fuse wird festgelegt, dass der AVR nach dem Reset an die Startadresse der Bootloader Sektion im Flash springt. Auf das '''IVSEL'''-Bit (keine Fuse) möchte ich erst an späterer Stelle - wenn es um Interrupts geht - zurückkommen.

'''Noch ein wichtiger Hinweis für die Werte der Fuses im Datenblatt:''' '''''Der Wert "0" bedeutet, dass die Fuse programmiert ist, es entspicht dem Häkchen im AVR Studio!'''''

= Der "Hallo Welt" - Bootloader =

Wie oben erwähnt, wird für die Erstellung des Codes die kostenlose IDE von Atmel - das AVRStudio - benutzt. Ergänzt wird es durch C-Compiler und Tools des WinAVR Projektes. Des weiteren wird zur seriellen Kommunikation das Terminalprogramm benötigt. Im Tutorial wird PuTTY verwendet und sollte installiert sein. Die Hardware ist aufgebaut und via AVRISPmkII-Programmer an den PC angeschlossen - nun kann es losgehen!

Zu Beginn wird ein neues AVRStudio-Projekt erstellt. Danach werden folgende Schritte abgearbeitet:

== Schritt 1 - Konfiguration der Projekteinstellungen ==
[[Bild:Bootloader-Projekt.png|200px|thumb|Erstellen des Projekts]]
[[Bild:Bootloader-Config-General.PNG|200px|thumb|Generelle Optionen - setzten der Taktfrequenz]]
[[Bild:Bootloader-Config-Linker.png|200px|thumb|Linker Option eingeben]]

Als erstes öffnen wir die Projekteinstellungen (Menü ''Project/Configuration Options'') und tragen die richtige Taktfrequenz ein (Im Beispiel nutzen wir den internen Oszillator mit 8 Mhz). Danach gehen wir zum Reiter '''Custom Options'''. Dort klicken wir auf '''Linker Options''' und geben dann im Textfeld daneben '''-Ttext=0x1800''' ein. Danach drücken wir auf '''Add'''.

Was bewirkt dieser Linker-Parameter? Dafür muß wieder etwas weiter ausgeholt werden. Nach dem Kompilieren der Programmquellen ''linkt'' der Linker den Programmcode an bestimmte Stellen in den drei verschiedenen Speichern Flash, EEPROM und SRAM des AVR. In der vom Compiler verwendeten [http://www.nongnu.org/avr-libc/user-manual/mem_sections.html AVR Libc] ist der Speicher in verschiedene Sektionen aufgeteilt. Dem Linker muss mitgeteilt werden, in welche Speicher er den Programmcode linken soll. Die Lokalisierung des Speichers sind die Sektionen. Die Sektion ''.text'' ist dem ausführbaren Programmcode - also den Befehlen - vorbehalten und liegt im Flash des AVR, des weiteren gibt es auch noch die Sektionen ''.data'' und ''.bss'' für die statischen und dynamischen Variablen im SRAM und eine Sektion ''.eeprom'' für den EEPROM und noch ein paar spezielle (Flash-)Sektionen.

Nun gibt es verschiedene Methoden, dem Linker mitzuteilen, dass man den Programmcode an die Stelle des Bootloaderbereichs haben möchte. Eine sehr einfache Methode ist '''die Verschiebung der Sektion ''' '''''.text''''', welche normalerweise ab Adresse 0x0000 beginnt. Eben dies geschieht mit dem Linker Parameter '''-Ttext=0x1800'''. Die Adresse des Beginns der ''.text'' Sektion wird auf die (Byte-)Adresse 0x1800 gesetzt.

== Schritt 2 - Einbinden der UART Library von Peter Fleury ==

Wie bereits erwähnt, wird für die serielle Kommunikation auf der AVR-Seite die UART-Library von [http://www.jump.to/fleury Peter Fleury] verwendet. Nach dem Download werden die uart.c und uart.h in das Projekt eingebunden (für die uart.c im AVR Studio rechte Maustaste auf ''Source Files'' und dann ''Add Existing Source File(s)...'' und für die uart.h die rechte Maustaste auf ''Header Files'' und dann ''Add Existing Header File(s)...'')

== Schritt 3 - Programmieren des Bootloaders ==

[[Bild:Bootloader-Config-Linker-ok.PNG|200px|thumb|Linker Option nach Add]]
[[Bild:Bootloader-AVRStudio.PNG|200px|thumb|Kompilieren des Bootloaders]]

Nun soll eine kleine Applikation geschrieben werden. Keine Angst, unser erstes Ziel ist es, eine kleine Anwendung in dem Bootloaderbereich zu positionieren, welche serielle Ein-und Ausgaben behandelt. Die eigentliche Bootloaderfunktionalität kommt später dazu. Also schreiben wir die Datei ''main.c'' wie folgt:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
unsigned int c=0; /* Empfangenes Zeichen + Statuscode */
unsigned char temp, /* Variable */
flag=1, /* Flag zum steuern der Endlosschleife */
p_mode=0; /* Flag zum steuern des Programmiermodus */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */

char sregtemp = SREG;
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
SREG = sregtemp;

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der Bootloader\n\r");
_delay_ms(1000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
switch((unsigned char)c)
{
case 'q':
flag=0;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
while(flag);

uart_puts("Springe zur Adresse 0x0000!\n\r");
_delay_ms(1000);

/* vor Rücksprung eventuell benutzte Hardware deaktivieren
und Interrupts global deaktivieren, da kein "echter" Reset erfolgt */

/* Interrupt Vektoren wieder gerade biegen */
cli();
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Rücksprung zur Adresse 0x0000 */
start();
return 0;
}
</c>

'''''Erklärung des Codes'''''

Beginnen wir mit den Defines: Die Baudrate erklärt sich von selbst. Die Defines XON und XOFF werden später, wenn die Bootloader-Funktionalität dazukommt, zur Flusssteuerung gebraucht. Wir werden also die XON/XOFF-Flussteuerung nutzen (merken für die Einstellung von PuTTY).

Bei den Variablen ist nur eine interessant: Der Funktionspointer <pre>void (*start)( void ) = 0x0000;</pre> ist ein einfacher Trick, um mit dem Programmcounter (PC) zur Adresse 0x0000 zu springen. Wir definieren einfach eine (fiktive) Funktion an der Stelle 0x0000. Beim Aufruf der Funktion mit <pre>start();</pre> springt der Programmcounter und damit das Programm an Adresse 0x0000 und das Anwendungsprogramm - wenn es eins gibt - kann starten.

Nun folgt ein sehr wichtiger Teil, auf den ich noch eingehen muss - die Interrupt-Vektoren. Interrupt-Vektoren sind Einsprungpunkte der Interrupts, welche normalerweise fest ab Adresse 0x0001 im Flash liegen. Wird ein Interrupt ausgelöst, springt der AVR automatisch zu der festen Flash-Adresse. Von dort aus - wenn eine ISR programmiert ist - springt der Controller zur ISR ('''I'''nterrupt '''S'''ervice '''R'''outine). Nun haben wir folgendes Problem: Wenn wir den Bootloadercode ab der Adresse 0x1800 ausführen, nützt es uns gar nichts, wenn der AVR nach Auslösen eines Interrupts an die Stelle 0x0001 + X springt, da dieser Speicherbereich ja im Zweifelsfalle sogar von uns überschrieben wird. Unser Code soll nur ab Adresse 0x1800 stehen! Wir müssen also die Sprungtabelle "verbiegen", d.h. den AVR veranlassen, bei Auslösung eines Interrupts an Adresse 0x1801 + X zu springen und dann zur ISR. Das Verbiegen der Sprungtabelle passiert mit dem Setzen des '''IVSEL'''-Bits im '''MCUCR''' (ACHTUNG: beim Atmega8 '''GICR'''), also

beim Atmega88:
<pre>
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);
</pre>

bzw. beim Atmega8:
<pre>
temp = GICR;
GICR = temp | (1<<IVCE);
GICR = temp | (1<<IVSEL);
</pre>

Das '''IVCE'''-Bit wird nur benötigt, um dem Mikrocontroller zu sagen, dass wir als nächstes den Parameter '''IVSEL''' setzen wollen, das Bit wird nachher vom Controller wieder gelöscht. Um versehentliches verstellen der Interrupttabelle zu vermeiden muss das setzen von '''IVCE''' und '''IVSEL''' innerhalb von 4 Taktzyklen erfolgen. Um dies zu gewährleisten müssen alle interrupts während des Setzens deaktiviert sein. ACHTUNG Stolperfalle: Die Variable temp wird benötigt, da beim Setzen von '''IVSEL''' gleichzeitig '''IVCE''' gelöscht werden muss:

bei Atmega8/16:
<pre>
GICR |= (1<<IVCE); // noch richtig. IVCE wird gesetzt
GICR |= (1<<IVSEL); // falsch! IVSEL wird zwar gesetzt,
IVCE bleibt jedoch in diesem Prozessortakt gesetzt.
</pre>

In der Hauptschleife wird lediglich gepollt, ob ein neues Zeichen von der Konsole kommt. Nach dem Empfang eines Zeichens wird es ausgewertet (switch). Nach dem Drücken von ''"q"'' verlässt der Bootloader die Hauptschleife, setzt die Interrupt-Vektoren wieder zurück und startet die Hauptanwendung - wenn eine da ist.

Nach dem Kompilieren sagt uns der Linker, dass 754 Byte Programmspeicher und 265 Byte Datenspeicher verbraucht wurde. 754 Byte ist weit unter den 2048 Byte, welche uns ab der Adresse 0x1800 zur Verfügung stehen, wir haben also alles richtig gemacht.

Nun kontrollieren wir noch schnell, ob das Programm an der richtigen Stelle im Flash steht. Mit dem Hex-File (Bootloader.hex) wird auch ein List-File (Bootloader.lss) erzeugt. Im List-File findet sich das disassemblierte Programm und die Speicherzuordnungen. Hier ein Auszug der Datei:

<pre>
Bootloader.elf: file format elf32-avr

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000080 00800100 00001a68 000002fc 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 00000268 00001800 00001800 00000094 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00000085 00800180 00800180 0000037c 2**0
ALLOC
3 .debug_aranges 00000040 00000000 00000000 0000037c 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_pubnames 00000095 00000000 00000000 000003bc 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_info 00000459 00000000 00000000 00000451 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_abbrev 00000238 00000000 00000000 000008aa 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_line 000003eb 00000000 00000000 00000ae2 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_frame 000000a0 00000000 00000000 00000ed0 2**2
CONTENTS, READONLY, DEBUGGING
9 .debug_str 000001cf 00000000 00000000 00000f70 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_loc 0000024a 00000000 00000000 0000113f 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_ranges 00000048 00000000 00000000 00001389 2**0
CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00001800 <__vectors>:
1800: 19 c0 rjmp .+50 ; 0x1834 <__ctors_end>
1802: 33 c0 rjmp .+102 ; 0x186a <__bad_interrupt>
1804: 32 c0 rjmp .+100 ; 0x186a <__bad_interrupt>
1806: 31 c0 rjmp .+98 ; 0x186a <__bad_interrupt>
1808: 30 c0 rjmp .+96 ; 0x186a <__bad_interrupt>
180a: 2f c0 rjmp .+94 ; 0x186a <__bad_interrupt>
180c: 2e c0 rjmp .+92 ; 0x186a

...
(viele Zeilen)
...

0000186c <main>:
#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */

int main()
{
186c: cf 93 push r28
186e: df 93 push r29
unsigned char temp, /* Variable */
flag=1; /* Flag zum steuern der Endlosschleife */
void (*start)( void ) = 0x0000; /* Funktionspointer auf 0x0000 */

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
1870: 85 b7 in r24, 0x35 ; 53
MCUCR = temp | (1<<IVCE);
1872: 98 2f mov r25, r24
1874: 91 60 ori r25, 0x01 ; 1
1876: 95 bf out 0x35, r25 ; 53
MCUCR = temp | (1<<IVSEL);
1878: 82 60 ori r24, 0x02 ; 2
187a: 85 bf out 0x35, r24 ; 53

...
(noch mehr Zeilen)
</pre>

Wir erkennen, dass die Sektion ''.text'' ab der Adresse (VMA) 0x1800 beginnt. Weiter sehen wir im Disassembly der Sektion ''.text'', dass unser Programm mit der Interrupt-Einsprungstabelle ab Adresse 0x1800 beginnt. Unsere ''main()'' beginnt ab Adresse 0x186C. Super. Das hat geklappt. Aber nun schnell zu Schritt 4 - dem Flashen und Ausprobieren des Programms...

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==

[[Bild:Bootloader-AVRStudio-Fuses.png|200px|thumb|Setzen der Fuses]]
[[Bild:PuTTY-Serconfig.png|200px|thumb|Serielle Konfiguration von PuTTY]]
[[Bild:PuTTY-Serconfig-xon.png|200px|thumb|Serielle Konfiguration von PuTTY]]

Nach dem Start des AVRISPmkII-In-System-Programmers aus dem AVRStudio werden zunächst die Einstellungen geprüft. Die Signatur des AVRs muss stimmen und die ISP-Frequenz. Im Reiter Program muss unter ''Flash'' die richtige Datei angegeben sein (''Bootloader.hex''). Danach können wir uns an das setzen der Fuses machen. '''CKDIV8''' sollte ausgeschalten werden, der interne Takt von 8 Mhz sollte genutzt werden ('''SUT_CKSEL''') und ''BOOTSZ'' auf 1024 words gestellt werden. Zusätzlich muß die '''BOOTRST'''-Fuse gesetzt werden, damit der Bootloader an der richtigen Adresse anfängt. Für alle, die einen anderen Programmer benutzen (z.B. avrdude), hier die exakten Werte der Fuses:
* Low Fuse: '''0xE2'''
* High Fuse: '''0xD2'''
* Extended Fuse: '''0xF8'''

Jetzt kann PuTTY gestartet und konfiguriert werden. Der ''Connection type'' muss auf '''Serial''' gestellt werden. Die Baudrate beträgt 9600 Baud. Unter ''Connection/Serial'' muss der ''Flow control'' auf '''XON/XOFF''' gestellt werden. Nach dem Konfigurieren kann die Konsole mit ''Open'' geöffnet werden.

Jetzt kann wieder in das AVR Studio gewechselt werden. Mit einem beherztem Druck auf ''Program'' wird das Flash im ATmega88 programmiert. Nach dem Wechsel auf die Konsole erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-start.png|600px|Bootloader in PuTTY]]

Nach dem Drücken von ein paar Tasten erscheint folgendes:

[[Bild:PuTTY-Bootloader-taste.png|600px|Bootloader nach Tastendruck in PuTTY]]

Nach dem Drücken von '''q''' erscheint folgendes Bild:

[[Bild:PuTTY-Bootloader-restart.png|600px|Bootloader nach Tastendruck in PuTTY]]

Der Bootloader versucht, zur Adresse 0x0000 zu springen, wo er allerdings keinen Programmcode findet. Wie auch? Wir haben ja den ganzen Flash des AVR gerade gelöscht und mit dem Bootloader gefüllt. Nun muss man wissen, dass in einem gelöschten Flash ''0xFF'' in jeder Speicherzelle steht. ''0xFF'' ist für den AVR kein gültiger Opcode. Der Programmzähler zählt nur um eins nach oben. Damit hopst er sozusagen durch den gesamten Flash bis er wieder beim Bootloader landet.

'''''[http://de.wikipedia.org/wiki/Heureka Heureka]''''' wir haben es geschafft! Ein Programm wird im Bootloaderbereich des Flashs ausgeführt! Es ''bootet'' zwar schon schön, aber es ''loadet'' noch nichts in den Flash. Aber die halbe Miete haben wir damit schon. Nun schreiben wir erst einmal eine kleine Anwendung, welche wir nach der Erweiterung unseres Bootloaders in den Flash-Speicher laden.

= Die Test-Anwendung =

[[Bild:Anwendung-AVRStudio.png|200px|thumb|Erstellen des Projektes]]
[[Bild:Anwendung-AVRStudio-Code.png|200px|thumb|Sourcecode im AVRStudio]]

Die Kategorie Anwendung möchte ich möglichst kurz halten. Ziel ist es, eine kleine Anwendung zu schreiben, welche dann mit dem (echten) Bootloader ins Flash gespeichert wird.

== Schritt 1 - Erstellen des Projektes ==

Nach dem Erstellen eines neuen Projektes muss in den Projekt-Einstellungen des AVR Studios nur die Taktfrequenz eingetragen werden. Die Linker-Optionen werden nicht verändert, also bleibt wie es ist.

== Schritt 2 - Einbinden der UART Library ==

Dieser Schritt kann vom Bootloader übernommen werden. Es wird wieder die UART-Bibliothek von Peter Fleury verwendet.

== Schritt 3 - Programmieren der Anwendung ==

Wir starten also ein neues AVR Studio und legen ein neues Projekt an, konfigurieren die Taktfrequenz (8 MHz) und laden die ''uart.c'' und ''uart.h'' dazu. Nun schreiben wir in die ''main.c'' folgende Zeilen:

<c>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include "uart.h"

#define UART_BAUD_RATE 9600

int main()
{
unsigned int c;
void (*bootloader)( void ) = 0x1800;

uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
sei();

uart_puts_P("\n\rHier ist das Anwendungsprogramm...");

for(;;)
{
c = uart_getc();
if(!(c & UART_NO_DATA))
{
switch( (unsigned char)c)
{
case 'b':
uart_puts("\n\rSpringe zum Bootloader...");
_delay_ms(1000);
bootloader();
break;
default:
uart_puts("\n\rDu hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
break;
}
}
}
return 0;
}

</c>
'''''Erklärung des Codes'''''

Viel interessantes ist nicht an diesem Code. Es gibt wie immer die berühmte Endlosschleife. Wir definieren wieder einen fiktiven Funktionspointer<pre>void (*bootloader)( void ) = 0x1800;</pre> Nach drücken der Taste '''b''' soll das Programm wieder zum Bootloader springen.

Nach dem Kompilieren des Programms sehen wir, dass der Programmspeicher mit 686 Byte belegt ist, der Datenspeicher mit 201 Bytes.

== Schritt 4 - Ausprobieren der Anwendung ==

Wer möchte kann die Anwendung auf den AVR flashen und ausprobieren. Die Funktion sollte sich von selbst erschließen.

'''Achtung:''' Es muss darauf geachtet werden, dass beim flashen der Anwendung nicht der Bootloader überschrieben wird. Bei Verwendung von avrdude muss dazu die Option "-D" angegeben werden.

Nun wollen wir uns der Erweiterung des Bootloaders widmen.

= Der "echte" Bootloader =
[[Bild:Real-Bootloader-AVRStudio.png|200px|thumb|Programmieren des Bootloaders]]

Zum Erstellen des Bootloaders wird wieder Schrittweise vorgegangen. Folgende Schritte sind zu befolgen:

== Schritt 1 und 2 - siehe "Hallo Welt" Bootloader ==
Schritt 1 und 2 können vom "Hallo Welt" Bootloader übernommen werden. Es sind wieder die korrekte Taktfrequenz und die Verschiebung der Sektion '''.text''' auf die Bootresetadresse einzustellen.

== Schritt 3 - Programmieren des Bootloaders ==

Nun soll der Bootloader erweitert werden. Nach dem Kompilieren des Anwendungsprogramms erhalten wir eine Datei ''Anwendung.hex'' im [http://de.wikipedia.org/wiki/Intel_HEX Intel-HEX-Format]. Da wir im Bootloader diese Daten auswerten müssen, wollen wir uns kurz mit dem Format beschäftigen. Das Intel-HEX-Format ist geschaffen worden, um Binärdaten als ASCII-Daten zu übertragen. Jedes Byte ist in Form von zwei ASCII-Zeichen gespeichert, d.h. aus der Zahl ''0x4A'' wird die ASCII-Zeichenfolge ''"4A"''. Das bedeutet aber auch, dass aus den Binärdaten die doppelte Anzahl von Zeichen wird, welche übertragen werden müssen, hinzu kommen noch Steuerzeichen und Zusatzinformationen. Jede Zeile in der Intel-HEX-Datei folgt einem bestimmten Schema, in dem u.a. die Anzahl der Bytes, die Zieladresse und Checksumme stehen.

Für weiterführende Erklärungen zum Thema HEX-Datei-Format empfehle ich folgende Lektüre:
* [http://en.wikipedia.org/wiki/Intel_HEX Wikipedia Artikel über HEX-Files]
* [http://www.rn-wissen.de/index.php/HEX-Datei RN-Wissen-Artikel über HEX-Files]
* [http://www.schulz-koengen.de/biblio/intelhex.htm Artikel von Wolfgang R.Schulz]

Unser Bootloader muss in der Lage sein, dieses Format zu interpretieren. Wir müssen also einen Parser schreiben. ''Oje'' werden manche denken, das ist ja wieder ein Thema für sich. Das stimmt prinzipiell auch. Allerdings kommt uns hier das einfache Format der Intel-Hex-Datei zugute, welches den Aufwand in Grenzen hält.

Also erstes brauchen wir also Funktionen, um die ASCII-Zeichenfolgen wieder in Binärdaten umzuwandeln. Normalerweise könnte man dafür die C-Funktion [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html#gaf8ce3b8dae3d45c34c3b172de503f7b3 strtol] aus der stdlib.h nehmen. Allerdings würde das Benutzen dieses Befehls das Linken der Standardbibliothek nach sich ziehen und damit den Code unnötig aufblähen. Daher werden wir uns eine einfache eigene Funktion schreiben, um die Zeichenfolgen umzuwandeln. In der HEX-Datei kommen 2 Byte und 4 Byte Hex-Zahlen im ASCII-Format vor. Wir brauchen also eine Funktion, welche die ASCII-Zeichenfolgen in Zahlen umwandelt, hier ist sie:
<c>
static uint16_t hex2num(const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}
</c>
Wir benutzen hier einen sehr einfachen Ansatz, um die Zahlen zu generieren. Die Funktionen wandeln die ASCII-Zeichen entsprechend ihrer Wertigkeit in Zahlen um. Soll z.B. das ASCII-Zeichen '1' umgewandelt werden, wird vom ASCII-Code '1', also dezimal 49, 48='0' abgezogen: 49 - 48 = 1, somit haben wir ein ASCII-Zeichen in eine Zahl umgewandelt. Wen das ASCII-Zeichen 'C' ist (Dezimal: 67), werden 'A' - 10 = 65 -10 = 55 abgezogen, um 12 zu erhalten, den Wert der hex-Ziffer C. Näher möchte an dieser Stelle nicht darauf eingehen, wir wollen schnell weiter zum Beschreiben des Flashs kommen.

Um in den Flash zu schreiben, werden wir Makros aus der ''[http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html boot.h]'' der avr-libc verwenden. Hier findet man alle Werkzeuge, die wir brauchen. Dabei sollte vor allen das ''API Usage Example'' in der [http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Online Doku] näher betrachtet werden. Dieses Beispiel soll weitestgehend übernommen werden, da es die nötige Funktionalität beinhaltet. Hier ist die Funktion:
<c>
void boot_program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts.*/
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}
boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}
</c>
Als erstes fällt auf, dass man der Funktion die ''Page''-Adresse übergibt. Es wird also immer seitenweise geschrieben. Dies ist eine Spezialität des Flash-Speichers. Es '''muss''' immer die gesamte Seite geschrieben werden, dafür gibt es einen ''Page''-Puffer, welcher die Daten enthält, welche mit der nächsten Schreiboperation in die entsprechende Page geschrieben werden. Dabei werden die Daten Wortweise in den ''Page''-Puffer geschrieben. Die wesentlichen Funktionen der Routine sind ''boot_page_erase(page)'', ''boot_page_fill(page + i, w)'' und ''boot_page_write(page)''. Nicht zu vergessen auch ''boot_spm_busy_wait()''. Die Bedeutung der Funktionen (naja es sind eher Makros) findet man in der Dokumentation der AVR Libc. Im wesentlichen läuft das Schreiben einer ''Page'' so ab:
* ''Page'' löschen
* ''Page''-Puffer befüllen (aus der Variable ''buf'')
* ''Page'' schreiben
So einfach, so gut. Für den Bootloader bedeutet das, dass er die Daten sammeln muß, bis er genügend Daten für eine ''Page'' hat. Dann wird eine ''Page'' geschrieben und der Spaß fängt von vorn an.

Mit diesen beiden Funktionen sind wir nun in der Lage, den Parser zu schreiben. Die ''main.c'' sieht folgt aus:
<c>
#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/boot.h>
#include <util/delay.h>
#include "uart.h"

#define BOOT_UART_BAUD_RATE 9600 /* Baudrate */
#define XON 17 /* XON Zeichen */
#define XOFF 19 /* XOFF Zeichen */
#define START_SIGN ':' /* Hex-Datei Zeilenstartzeichen */

/* Zustände des Bootloader-Programms */
#define BOOT_STATE_EXIT 0
#define BOOT_STATE_PARSER 1

/* Zustände des Hex-File-Parsers */
#define PARSER_STATE_START 0
#define PARSER_STATE_SIZE 1
#define PARSER_STATE_ADDRESS 2
#define PARSER_STATE_TYPE 3
#define PARSER_STATE_DATA 4
#define PARSER_STATE_CHECKSUM 5
#define PARSER_STATE_ERROR 6

void program_page (uint32_t page, uint8_t *buf)
{
uint16_t i;
uint8_t sreg;

/* Disable interrupts */
sreg = SREG;
cli();

eeprom_busy_wait ();

boot_page_erase (page);
boot_spm_busy_wait (); /* Wait until the memory is erased. */

for (i=0; i<SPM_PAGESIZE; i+=2)
{
/* Set up little-endian word. */
uint16_t w = *buf++;
w += (*buf++) << 8;

boot_page_fill (page + i, w);
}

boot_page_write (page); /* Store buffer in flash page. */
boot_spm_busy_wait(); /* Wait until the memory is written.*/

/* Reenable RWW-section again. We need this if we want to jump back */
/* to the application after bootloading. */
boot_rww_enable ();

/* Re-enable interrupts (if they were ever enabled). */
SREG = sreg;
}

static uint16_t hex2num (const uint8_t * ascii, uint8_t num)
{
uint8_t i;
uint16_t val = 0;

for (i=0; i<num; i++)
{
uint8_t c = ascii[i];

/* Hex-Ziffer auf ihren Wert abbilden */
if (c >= '0' && c <= '9') c -= '0';
else if (c >= 'A' && c <= 'F') c -= 'A' - 10;
else if (c >= 'a' && c <= 'f') c -= 'a' - 10;

val = 16 * val + c;
}

return val;
}

int main()
{
/* Empfangenes Zeichen + Statuscode */
uint16_t c = 0,
/* Intel-HEX Zieladresse */
hex_addr = 0,
/* Zu schreibende Flash-Page */
flash_page = 0,
/* Intel-HEX Checksumme zum Überprüfen des Daten */
hex_check = 0,
/* Positions zum Schreiben in der Datenpuffer */
flash_cnt = 0;
/* temporäre Variable */
uint8_t temp,
/* Flag zum steuern des Programmiermodus */
boot_state = BOOT_STATE_EXIT,
/* Empfangszustandssteuerung */
parser_state = PARSER_STATE_START,
/* Flag zum ermitteln einer neuen Flash-Page */
flash_page_flag = 1,
/* Datenpuffer für die Hexdaten*/
flash_data[SPM_PAGESIZE],
/* Position zum Schreiben in den HEX-Puffer */
hex_cnt = 0,
/* Puffer für die Umwandlung der ASCII in Binärdaten */
hex_buffer[5],
/* Intel-HEX Datenlänge */
hex_size = 0,
/* Zähler für die empfangenen HEX-Daten einer Zeile */
hex_data_cnt = 0,
/* Intel-HEX Recordtype */
hex_type = 0,
/* empfangene HEX-Checksumme */
hex_checksum=0;
/* Funktionspointer auf 0x0000 */
void (*start)( void ) = 0x0000;

/* Füllen der Puffer mit definierten Werten */
memset(hex_buffer, 0x00, sizeof(hex_buffer));
memset(flash_data, 0xFF, sizeof(flash_data));

/* Interrupt Vektoren verbiegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);

/* Einstellen der Baudrate und aktivieren der Interrupts */
uart_init( UART_BAUD_SELECT(BOOT_UART_BAUD_RATE,F_CPU) );
sei();

uart_puts("Hallo hier ist der echte Bootloader\n\r");
_delay_ms(2000);

do
{
c = uart_getc();
if( !(c & UART_NO_DATA) )
{
/* Programmzustand: Parser */
if(boot_state == BOOT_STATE_PARSER)
{
switch(parser_state)
{
/* Warte auf Zeilen-Startzeichen */
case PARSER_STATE_START:
if((uint8_t)c == START_SIGN)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_SIZE;
hex_cnt = 0;
hex_check = 0;
uart_putc(XON);
}
break;
/* Parse Datengröße */
case PARSER_STATE_SIZE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_ADDRESS;
hex_cnt = 0;
hex_size = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_size;
uart_putc(XON);
}
break;
/* Parse Zieladresse */
case PARSER_STATE_ADDRESS:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 4)
{
uart_putc(XOFF);
parser_state = PARSER_STATE_TYPE;
hex_cnt = 0;
hex_addr = hex2num(hex_buffer, 4);
hex_check += (uint8_t) hex_addr;
hex_check += (uint8_t) (hex_addr >> 8);
if(flash_page_flag)
{
flash_page = hex_addr - hex_addr % SPM_PAGESIZE;
flash_page_flag = 0;
}
uart_putc(XON);
}
break;
/* Parse Zeilentyp */
case PARSER_STATE_TYPE:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_cnt = 0;
hex_data_cnt = 0;
hex_type = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_type;
switch(hex_type)
{
case 0: parser_state = PARSER_STATE_DATA; break;
case 1: parser_state = PARSER_STATE_CHECKSUM; break;
default: parser_state = PARSER_STATE_DATA; break;
}
uart_putc(XON);
}
break;
/* Parse Flash-Daten */
case PARSER_STATE_DATA:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
uart_putc('.');
hex_cnt = 0;
flash_data[flash_cnt] = (uint8_t)hex2num(hex_buffer, 2);
hex_check += flash_data[flash_cnt];
flash_cnt++;
hex_data_cnt++;
if(hex_data_cnt == hex_size)
{
parser_state = PARSER_STATE_CHECKSUM;
hex_data_cnt=0;
hex_cnt = 0;
}
/* Puffer voll -> schreibe Page */
if(flash_cnt == SPM_PAGESIZE)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
memset(flash_data, 0xFF, sizeof(flash_data));
flash_cnt = 0;
flash_page_flag = 1;
}
uart_putc(XON);
}
break;
/* Parse Checksumme */
case PARSER_STATE_CHECKSUM:
hex_buffer[hex_cnt++] = (uint8_t)c;
if(hex_cnt == 2)
{
uart_putc(XOFF);
hex_checksum = (uint8_t)hex2num(hex_buffer, 2);
hex_check += hex_checksum;
hex_check &= 0x00FF;
/* Dateiende -> schreibe Restdaten */
if(hex_type == 1)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page((uint16_t)flash_page, flash_data);
boot_state = BOOT_STATE_EXIT;
}
/* Überprüfe Checksumme -> muss '0' sein */
if(hex_check == 0) parser_state = PARSER_STATE_START;
else parser_state = PARSER_STATE_ERROR;
uart_putc(XON);
}
break;
/* Parserfehler (falsche Checksumme) */
case PARSER_STATE_ERROR:
uart_putc('#');
break;
default:
break;
}
}
/* Programmzustand: UART Kommunikation */
else if(boot_state != BOOT_STATE_PARSER)
{
switch((uint8_t)c)
{
case 'p':
boot_state = BOOT_STATE_PARSER;
uart_puts("Programmiere den Flash!\n\r");
uart_puts("Kopiere die Hex-Datei und füge sie"
" hier ein (rechte Maustaste)\n\r");
break;
case 'q':
boot_state = BOOT_STATE_EXIT;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
uart_puts("Du hast folgendes Zeichen gesendet: ");
uart_putc((unsigned char)c);
uart_puts("\n\r");
break;
}
}
}
}
while(boot_state!=BOOT_STATE_EXIT);

uart_puts("Reset AVR!\n\r");
_delay_ms(1000);

/* Interrupt Vektoren wieder gerade biegen */
temp = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp & ~(1<<IVSEL);

/* Reset */
start();

return 0;
}

</c>
'''''Erklärung des Codes'''''

Der Bootloader wird als ''Zustandsmaschine'' programmiert. Die Variable ''boot_state'' beinhaltet den aktuelle Programmzustand. Für den Parser gibt es eine eigene Zustandsvariable ''parser_state'', welche die einzelne Zustände des Parsers hält. Mit jeder HEX-Datei-Zeile läuft der Parser einmal durch alle Zustände. Nach Abarbeiten des aktuellen Zustands und Auswertung der empfangenen Daten wird der nächste Zustand aktiviert usw. Für das Verarbeiten der Datei wird jedes Mal die Kommunikation angehalten und ein ''XOFF'' gesendet. Nach Abarbeitung der Daten gibt der Parser den seriellen Empfang wieder frei (''XON''). '''''Es ist also wichtig, dass in PuTTY die XON/XOFF-Flußkontrolle aktiviert wird!''''' Durch den interruptgesteuerten Empfang mit einem 32 Byte tiefen Empfangspuffer geht kein Byte verloren. Am Ende einer HEX-Datei-Zeile wird die Checksumme ausgewertet. Bei falscher Checksumme springt der Parser in den ''PARSER_STATE_ERROR'', aus dem er nicht mehr rauskommt. Somit wird kein weiteres Byte in den Flash geschrieben. Zusätzlich könnte man noch implementieren, dass der Flash wieder gelöscht wird, wenn falsche Daten empfangen wurden, damit kein unvollständiges Programm im Flash steht.
Einschränkend muss noch festgehalten werden, das der Bootloader in dieser Fassung einen Adressraum bis 64K unterstützt (HEX-Zeilentyp 1). Die erweiterten Adressräume (HEX-Zeilentyp 2 bis 5) werden noch nicht unterstützt. Für ATmega-Devices mit > 64K Flash muss der Bootloader noch erweitert werden.

Nach dem Kompilieren beträgt die Größe des Bootloaders 1796 Byte, wir sind also unterhalb der 2048 Byte die wir "verbraten" können. Der Datenspeicher wird mit 283 Byte belastet.

Die Funktion des Bootloaders sieht wie folgt aus: Nach dem Reset wartet der Bootloader 2 Sekunden auf Eingaben (''_delay_ms(2000);''). Falls keine Eingaben von der Konsole kommen, springt der Bootloader zur Anwendung. Damit ist gewährleiset, dass die Anwendung später automatisch startet, auch wenn wir keine Taste drücken. Wird ein ''p'' gedrückt, springt der Bootloader in den ''BOOT_STATE_PARSER'' und erwartet eine HEX-Datei auf der Konsole. Dies ist der Zeitpunkt, die HEX-Datei der Anwendung mit Copy & Paste in die Konsole zu schreiben. Zum Einfügen von Daten aus dem Zwischenspeicher in die Konsole wird bei PuTTY die rechte Maustaste verwendet.

'''''WICHTIGER HINWEIS: ''''' Es hat sich gezeigt, das die Flußkontrolle durch XON/XOFF nicht immer funktioniert, da es eine Software-Flußsteuerung ist und u.U. der (UART-Sende-)Interrupt zu spät (oder gar nicht) ausgeführt wird. Bei Problemen beim Übertragen des HEX-Files sollte man als erstes versuchen die Baudrate zu senken (oder die Taktrate des Controllers erhöhen) um dem Controller mehr Zeit zum Verarbeiten und schnellerem Reagieren auf Interrupts zu geben.

== Schritt 4 - Flashen und Ausprobieren des Bootloaders ==
Nach dem Flashen via AVRISPmkII startet der Bootloader in der Konsole. Da noch kein Anwendungsprogramm im Flash liegt, startet der Bootloader nach 2 Sekunden immer wieder neu. Nach Drücken der Taste ''p'' erwartet der Bootlader die HEX-Datei der Anwendung. Nach dem Einfügen der Datei in Konsole erscheint für jedes empfangene Byte ein Punkt ("."). Das Beschreiben einer Flash-''Page'' kenzeichnet ein ''P''. Nach dem erfolgreichen Flashen startet die Anwendung automatisch.

Nach erfolgreichem Flashen des Bootloaders via AVRISPmkII erscheint nach dem Reset folgendes Bild:

[[Bild:PuTTY-Real-Bootloader-start.png|PuTTY: Bootloader nach dem Reset]]

Drückt man die Taste '''p''', springt ist der Bootloader bereit zum Empfang der HEX-Datei:

[[Bild:PuTTY-Real-Bootloader-wait.png|PuTTY: Warten auf die HEX-Datei "Anwendung.hex"]]

Nach Kopieren & Einfügen der HEX-Datei der vorher kompilierten Anwendung, hier die Intel-HEX-Datei "Anwendung.hex":
<pre>
:100000002CC046C045C044C043C042C041C040C0EF
:100010003FC03EC03DC03CC03BC03AC039C038C004
:1000200037C036C064C08FC033C032C031C030C0AA
:100030002FC02EC048696572206973742064617393
:1000400020416E77656E64756E677370726F67724C
:10005000616D6D2E2E2E0D0A000011241FBECFEFF4
:10006000D4E0DEBFCDBF11E0A0E0B1E0EAE6F2E00F
:1000700002C005900D92A434B107D9F711E0A4E4B1
:10008000B1E001C01D92A938B107E1F702D0EBC081
:10009000B7CFEF92FF920F931F93CF93DF9383E33A
:1000A00090E07BD0789484E390E0D0D088ECE82E88
:1000B000F12C00E018E18BD0EC0190FDFCCF8236F2
:1000C00069F480E091E0B6D080E197E2F7013197E2
:1000D000F1F70197D9F7F8010995EDCF8CE191E09F
:1000E000A9D08C2F91D081E491E0A4D0E4CF1F92CD
:1000F0000F920FB60F9211242F938F939F93EF932C
:10010000FF939091C0002091C600E0918601EF5FBF
:10011000EF7180918701E81711F482E008C0892F00
:100120008871E0938601F0E0EC59FE4F20838093C4
:100130008801FF91EF919F918F912F910F900FBEAA
:100140000F901F9018951F920F920FB60F921124C7
:100150008F939F93EF93FF939091840180918501FA
:10016000981769F0E0918501EF5FEF71E0938501E9
:10017000F0E0EC5BFE4F80818093C60005C080916B
:10018000C1008F7D8093C100FF91EF919F918F916E
:100190000F900FBE0F901F9018959C011092840134
:1001A00010928501109286011092870197FF04C07A
:1001B00082E08093C0003F773093C5002093C40055
:1001C00088E98093C10086E08093C20008959091F1
:1001D000860180918701981719F420E031E012C060
:1001E000E0918701EF5FEF71E0938701F0E0EC5958
:1001F000FE4F308120918801922F80E0AC01430FA7
:10020000511D9A01C9010895282F909184019F5F83
:100210009F71809185019817E1F3E92FF0E0EC5B85
:10022000FE4F2083909384018091C100806280936F
:10023000C1000895CF93DF93EC0102C02196E4DF63
:1002400088818823D9F7DF91CF910895CF93DF93E9
:10025000EC0101C0D9DFFE01219684918823D1F7FA
:0A026000DF91CF910895F894FFCFCD
:10026A00537072696E6765207A756D20426F6F747C
:10027A006C6F616465722E2E2E0D0A00447520681B
:10028A0061737420666F6C67656E646573205A6566
:10029A00696368656E20676573656E6465743A2084
:0402AA00000A0D0039
:00000001FF
</pre>
erscheinen folgende Ausgaben in PuTTY:

[[Bild:PuTTY-Real-Bootloader-prog.png|PuTTY: Flashen der HEX-Datei "Anwendung.hex"]]

Nach erfolgreichem Flashen startet die Anwendung und meldet sich mit der Zeile
<pre>
Hier ist das Anwendungsprogramm...
</pre>
Jetzt können nach belieben Tasten gedrückt werden, was die Anwendung jedesmal quittiert:

[[Bild:PuTTY-Real-Bootloader-anwend.png|PuTTY: Ausprobieren der Anwendung]]

Nach Drücken der Taste '''b''' springt die Anwendung wieder zur Startadresse des Bootloaders, also zur Adresse ''0x1800'' im Flash-Speicher. Nun hat man wieder 2 Sekunden Zeit, um die Taste '''p''' zu drücken, sonst startet die Anwendung wieder:

[[Bild:PuTTY-Real-Bootloader-reset.png|PuTTY: Rücksprung zum Bootloader auf Adresse 0x1800]]

Damit ist das Tutorial abgeschlossen.

'''''Viel Spass beim Ausprobieren und Weiterentwickeln!'''''

= Zusammenfassung =

Wer den Artikel bis hier hin nachvollzogen hat, ist jetzt in der Lage einen Bootloader selbst zu schreiben. Dabei kann der Bootloader an jede in Frage kommenden ATmega-Plattform angepaßt werden. Dazu muss
* die Linkereinstellung für das Verschieben der Sektion ''.text'' angepasst werden und ('''-Ttext = 0xXXXX''')
* evtl. der virtuelle Funktionspointer in der Anwendung geändert werden (falls ein Rücksprung zum Bootloader gewünscht ist '''void (*bootloader)(void) = 0xXXXX''').

Um dies zu erleichtern, habe ich hier die Sprungadressen für ausgewählte AVRs tabellarisch zusammengetragen. Dabei wurde immer die maximale Größe des Bootloader betrachtet, also '''BOOTSZ0=0''' und '''BOOTSZ1=0''':

{| border="1" class="wikitable"
|+ Größe und Startadresse der Bootloader Sektion für ausgewählte AVR-Devices
|-
! Device || Flash-Größe für Applikation || Flash-Größe des Bootloaders || Startadresse des Bootloaders (Byteadresse)
|-
| ATmega8/88 || 6144 Byte || 2048 Byte || 0x1800
|-
| ATmega16/164/168 || 14336 Byte || 2048 Byte || 0x3800
|-
| ATmega32/324/328 || 28672 Byte || 4096 Byte || 0x7000
|-
| ATmega64/644/640 || 57344 Byte || 8192 Byte || 0xE000
|-
| ATmega128/1284/1280/1281 || 122880 Byte || 8192 Byte || 0x1E000
|-
| ATmega2560/2561 || 253952 Byte || 8192 Byte || 0x3E000
|}

Damit kann jeder den Bootloader nach seinen Wünschen anpassen. Eine gängige Praxis ist auch, ein kleines PC-Programm zu schreiben, welches dem Bootloader die Flash-Daten gleich Binär übergibt. Das geht schneller und spart das aufwendige Parsen. Eine weitere Idee ist es, den Bootloader so anzupassen, das er sich wie ein STK500 an der seriellen Schnittstelle verhält. Dazu muss man die [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735 AP068] von Atmel umsetzen. Auch dies sollte nach dem Studium des Tutorial kein Problem mehr sein :)

[http://www.mikrocontroller.net/user/show/mario Nachricht an den Autor]

= FAQ =

== Wie kann man Bootloader und Anwendungsprogramm gemeinsam flashen? ==

Es ist in C ohne weiteres nicht möglich ein gemeinsames Hexfile aus Bootloader und Anwendungsprogramm zu kompilieren. Aber man kann das getrennt erstellte Hexfile des Bootloaders und das getrennt erstellte Hexfile des Anwendungsprogramms zusammenfügen und so gemeinsam mit ISP flashen. Dazu die letzte Zeile des 1. Hexfiles entfernen und dahinter das 2. Hexfile anfügen [http://www.mikrocontroller.net/topic/199241#1955092], [http://www.mikrocontroller.net/topic/198428#1949164].

[[Kategorie:AVR-Programmer und -Bootloader|B]]