Mikrocontroller.net - Benutzerbeiträge [de]

AVR Bootloader in C - eine einfache Anleitung

2015-03-20T12:42:04Z

Zumax: /* Referenzen / Links */

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 [http://homepage.hispeed.ch/peterfleury/avr-software.html 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:

<syntaxhighlight lang="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;
}
</syntaxhighlight>

'''''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.

Eine Besonderheit ist zu beachten, wenn der verfügbare Flash-Speicher größer als 128kB ist. In der Regel wird der Bootloader im oberen Teil des Speichers liegen und daher ist ein einfacher Rücksprung mit normaler 2Byte Wordadressierung nicht möglich. Leider hat gcc hier einen Bug und verwendet das vom Controller zusätzlich herangezogene Register EIND nicht. Dieses Register muß daher explizit vor dem Rücksprung auf 0 gesetzt werden. Also <pre>EIND = 0;
start();</pre>Ohne diesen Zusatz kann der Bootloader im Normalfall nicht mehr verlassen werden.

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:

<syntaxhighlight lang="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 ) = 0x0C00; // Achtung Falle: Hier Word-Adresse

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;
}

</syntaxhighlight>
'''''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 auf die '''Word'''-Adresse des Bootloaders. (Hier verhält sich der AVR-GCC leider etwas inkonsistent, da sonst bei Flash-Adressen mit Bytes gearbeitet wird. Gibt man hier versehentlich die Byteadresse an, kann es sein, dass der Sprung in den Bootloader klappt, es muss aber nicht funktionieren, da das Sprungziel undefiniert ist. Verwendet man stattdessen einen JMP befehl im Inline-Assembler, so ist die Byte-Adresse für das Sprungziel anzugeben.) <pre>void (*bootloader)( void ) = 0x0C00;</pre>

Nach drücken der Taste '''b''' soll das Programm wieder zum Bootloader springen.
Leider haben wir auch hier ein Problem, wenn der verfügbare Flash-Speicher größer als 128kB ist. Denn selbst wenn man dem Funktionspointer z.B. 0x1F000 (kleinste Bootloader Startadresse bei 256kB Devices) als Adresswert zuweist, werden nur die unteren zwei Bytes verwendet. Der Sprung in den Bootloader würde also nach 0xF000 gehen und man würde bei Applikationen, die größer sind als 120kB, irgendwo mitten im Code landen. Um sicher zu sein, daß an die korrekte Startadresse gesprungen wird, muß vor dem Sprung das EIND Register explizit auf 1 gesetzt werden. (Im Gegensatz zum Rücksprung mit EIND = 0) Also
<pre>EIND = 1;
bootloader();</pre>
Das EIND Register wird vom Controller bei extended calls oder jumps als höchstwertigstes Adressbyte verwendet, aber leider vom gcc Compiler in der aktuellen Version nicht unterstützt. Siehe [http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/AVR-Options.html]

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 (Flash-Speicher nicht automatisch löschen).

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.

Als 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:
<syntaxhighlight lang="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;
}
</syntaxhighlight>
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. Wenn 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:
<syntaxhighlight lang="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;
}
</syntaxhighlight>
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:
<syntaxhighlight lang="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;
}

</syntaxhighlight>
'''''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. Eine andere Möglichkeit ist, eine Verzögerung zu aktivieren. z.B. kann mit dem Programm CoolTerm einen "Transmit Character delay" eingestellt werden. Dies funktioniert dann ab 2ms, wenn die Flusssteuerung versagt.

== 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!'''''

= Der "echte" Bootloader für Programme > 64k =

Der Bootloader für AVRs mit mehr als 64K Flash-Speicher wird direkt Bootloader im vorherigen Kapitel abgeleitet.+

'''''ACHTUNG: Der Abschnitt befindet sich zur Zeit in Bearbeitung!! '''''

== 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 ==
Das Adresse eines Type 0 - Records im HEX86 - Format ist auf 16 Bit und somit auf 65535 Adressen beschränkt. Um den Adressbereich zu erweitern wurden die Record - Typen 2 bis 5 definert, wobei für uns nur Typ 2 und 4 relevant sind. Im Record-Typ 2 wird eine Offset- bzw Segmentadresse definiert. Sie wird mit 16 multipliziert und bei allen folgenden Schreiboperationen zur Adresse hinzuaddiert. Typ 4 sind die oberen 16 Bit einer 32 Bitadresse, die unteren 16 Bit sind in diesem Fall die im Record-Typ 0 angegebenen Adresse. Die Zustandsmaschine muß nun entsprechend erweitert werden:

<syntaxhighlight lang="c">
#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.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;
}

void write_page(uint32_t page, uint8_t *buf)
{
uart_puts("P\n\r");
_delay_ms(100);
program_page(page, buf);
memset(buf, 0xFF, sizeof(SPM_PAGESIZE));
}

int main()
{
/* Intel-HEX Zieladresse */
uint32_t hex_addr = 0,
/* Intel-HEX Zieladress-Offset */
hex_addr_offset = 0,
/* Zu schreibende Flash-Page */
flash_page = 0;
/* Empfangenes Zeichen + Statuscode */
uint16_t c = 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 = hex_addr_offset;
hex_addr += hex2num(hex_buffer, 4);
hex_check += (uint8_t) hex_addr;
hex_check += (uint8_t) (hex_addr >> 8);

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 1: parser_state = PARSER_STATE_CHECKSUM; break;
case 0:
case 2:
case 4: parser_state = PARSER_STATE_DATA;

/* Berechnen der neue Flash-Page (abhängig von hex_type) */
/* Liegen die Daten noch in der aktuellen Flash-Page? */
if(!flash_page_flag && (flash_page != (hex_addr - hex_addr % SPM_PAGESIZE)) )
{
/* Wenn die Daten nicht in der aktuellen Flash-Page liegen, */
/* wird die aktuelle Page geschrieben und ein Flag */
/* zum berechnen der neuen Page-Startadresse gesetzt */
write_page(flash_page, flash_data);
flash_cnt = 0;
flash_page_flag = 1;
}

/* Muss die Page-Startadresse neu berechnet werden? */
if(flash_page_flag)
{
/* Berechnen der neuen Page-Startadresse */
flash_page = hex_addr - hex_addr % SPM_PAGESIZE;

/* Füllen des Flash-Puffers mit dem "alten" Inhalt der Page */
memcpy_PF(flash_data, flash_page, SPM_PAGESIZE);

/* Flag setzen um anzuzeigen das eine neue Adresse da ist */
flash_page_flag = 0;
}
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;
switch(hex_type)
{
case 0: /* Record Typ 00 - Data Record auswerten */
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)
{
write_page(flash_page, flash_data);
flash_cnt = 0;
flash_page_flag = 1;
}
uart_putc(XON);
}
break;
case 2: /* Record Typ 02 - Extended Segment Address auswerten */
case 4: /* Record Typ 04 - Extended Linear Address auswerten */
if(hex_cnt == 4)
{
uart_putc(XOFF);
uart_putc('J');
hex_cnt = 0;

/* Schreibe angfangene Flash-Page vor Segment-Sprung */
write_page(flash_page, flash_data);
flash_cnt = 0;
flash_page_flag = 1;

/* Berechnen der Offsetadresse */
switch(hex_type)
{
case 2: hex_addr_offset = ((uint32_t)(hex2num(hex_buffer, 4)) << 4; break;
case 4: hex_addr_offset = ((uint32_t)hex2num(hex_buffer, 4)) << 16; break;
}

/* Addieren der empfangenen Werte für die Checksumme */
hex_check += (uint8_t) hex2num(hex_buffer, 2);
hex_check += (uint8_t) hex2num(hex_buffer + 2, 2);

parser_state = PARSER_STATE_CHECKSUM;
hex_data_cnt=0;
hex_cnt = 0;
}
break;
default:
break;
}
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)
{
write_page(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("Kopiere die Hex-Datei und füge sie hier ein\n\r");
break;
case 'q':
boot_state = BOOT_STATE_EXIT;
uart_puts("Verlasse den Bootloader!\n\r");
break;
default:
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;
}

</syntaxhighlight>

= 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 kommende ATmega-Plattform angepaßt werden. Dazu muss
* die Linkereinstellung für das Verschieben der Sektion ''.text'' angepasst werden und ('''-Ttext = 0xXXXXX''')
* evtl. der virtuelle Funktionspointer in der Anwendung geändert werden (falls ein Rücksprung zum Bootloader gewünscht ist '''void (*bootloader)(void) = 0xYYYYY''').

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) 0xXXXXX || Startadresse des Bootloaders (Wordadresse) 0xYYYYY
|-
| ATmega8/88 || 6144 Byte || 2048 Byte || 0x1800 || 0xC00
|-
| ATmega16/164/168 || 14336 Byte || 2048 Byte || 0x3800 || 0x1C00
|-
| ATmega32/324/328 || 28672 Byte || 4096 Byte || 0x7000 || 0x3800
|-
| ATmega64/644/640 || 57344 Byte || 8192 Byte || 0xE000 || 0x7000
|-
| ATmega128/1284/1280/1281 || 122880 Byte || 8192 Byte || 0x1E000 || 0xF000
|-
| ATmega2560/2561 || 253952 Byte || 8192 Byte || 0x3E000 || 0x1F000
|}

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 interpretieren der Daten (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 Application Note [http://www.atmel.com/images/doc2591.pdf AVR068] 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].

Mit Atmel Studio 6 lässt sich das Vorgehen sehr leicht über die Post-Build Events automatisieren. Benötigt wird hierzu ein kleines Batch-Script, welches z.B. als "hexjoin.bat" im Solution Directory abgelegt wird.

<source lang="dos">
type %1 | findstr /v :00000001FF > tmp.hex
type %2 >> tmp.hex
type tmp.hex > %1
</source>

Unter "Project->Properties->Build Events->Post-build event command line" kann nun das Script nach jedem Build ausgeführt werden und erzeugt eine kombinierte HEX-Datei. Im folgenden Beispiel wird davon ausgegangen, dass sowohl die Datei mit dem Bootloader, als auch das Batch-Script im Solution Directory liegen:

<source lang="dos">
$(SolutionDir)hexjoin.bat "$(OutputDirectory)\$(OutputFileName).hex" "$(SolutionDir)bootloader.hex"
</source>

= Referenzen / Links =

* [https://github.com/arduino/Arduino/blob/master/hardware/arduino/bootloaders/atmega/ATmegaBOOT_168.c Arduino Bootloader (simuliert den AVR ISP)] jetzt zu finden bei: [https://code.google.com/p/arduino/source/browse/tags/0015/hardware/bootloaders/atmega/ATmegaBOOT_168.c code.google.com]

* [http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger FastBoot von Peter Dannegger ]

* [http://www.mikrocontroller.net/articles/Bootloader allgemeines zu Bootloadern ]

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

Benutzer:Zumax

2014-11-22T19:17:15Z

Zumax:

03/2011 – 07/2013 Student der Fachrichtung Informatik mit der Vertiefung Eingebettete
und Mobile Systeme an der HTWG Konstanz mit Abschluss '''Master'''

10/2006 – 12/2010 Student der Fachrichtung Technische Informatik an der HTWG
Konstanz mit Abschluss '''Bachelor'''

Benutzer:Zumax

2014-11-22T19:16:47Z

Zumax:

03/2011 – 07/2013 Student der Fachrichtung Informatik mit der Vertiefung Eingebettete
und Mobile Systeme an der HTWG Konstanz mit Abschluss Master
10/2006 – 12/2010 Student der Fachrichtung Technische Informatik an der HTWG
Konstanz mit Abschluss Bachelor

AVR Net-IO Bausatz von Pollin

2010-04-18T17:29:57Z

Zumax: /* Bekannte Fehler */

== Einleitung ==

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058]

Eine Liste von Features:

Ethernet-Platine mit ATMega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

Technische Daten:

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (LxBxH): 108x76x22 mm.

== Hardware ==

[[Bild:AVR-NET-IO.JPG|thumb|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen sind nicht wie vorgesehen angereiht.]]Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Sie sind nicht(!) besonders geschützt, es finden sich zum Beispiel keine Schutzdioden für die Pins in der Schaltung.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe (nicht wie auf dem Foto; die Anschlussklemmen lassen sich sauber durch einen Steg zusammenstecken).
=== Erweiterungsplatine ===
Seit Januar 2010 gibt es auch eine Erweiterungsplatine.

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot
* RFM12 Funkmodul (nicht im Lieferumfang enthalten)

Ausserdem soll es die 3.3V Versorgung der Hauptplatine verbessern. Dazu sollte man einen 4,7 kOhm Widerstand parallel zu R2 schalten. Sonst beträgt die Ausgangsspannung nur ca. 2,8V. (Tipp aus dem u.g. Thread im Forum)

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5K ersetzen mit 2K
*R3 1,8K ersetzen mit 3,3K
*R19 470K ersetzen zu 470Ohm
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache NPN! und mehr als 100mA)

ISP-Anschluß nicht vollständig durchgeschleift. Keine Verbindung der RESET-Leitung zwischen ISP und ISP1.

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
* Ersatz des ATmega32 durch einen ATmega644 mit mehr FLASH-Speicher.

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die seriell Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal einen Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===

Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.

==== Funktionsfähige Konfiguration - AVR-Prog ====

Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

[[Bild:Avrprog.png]]

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0/24 Subnetz ====

Betreibt man den PC normalerweise nicht im 192.168.0/24 Subnetz, muss er wie folgt umkonfiguriert werden.

Den PC vom normalen Netzwerk abstecken. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FC NETMASK 
3FD - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Bekannte Fehler ==

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

*Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10uF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1uF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere im File ENC28J60.H
#define ENC28J60_PIN_SS 3
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

Wer gerne als Link-LED die grüne nutzen möchte
(U.Radig-Source)

enc28j60.c Zeile 150

"enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A)

Wert 0x347A in 0x374A ändern

(Quelle: http://www.mikrocontroller.net/topic/109988#994943)

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

Oder
[http://www.ethersex.de/firmware-builder/list.cgi hier] ein Firmware Image passend für das Pollin Net-IO mit eingebautem Webserver und Beispieldateien im Flash bauen lassen und flashen (firmware-builder). Einfacher geht´s nimmer. :-)

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== AvrArtNode ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt das viel Arbeit und Liebe in diesen Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-System welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

Benutzer:Zumax

2010-04-18T17:26:15Z

Zumax: Die Seite wurde neu angelegt: „Student of Applied Sciences @ HWTG Konstanz“

Student of Applied Sciences @ HWTG Konstanz