Mikrocontroller.net - Benutzerbeiträge [de]

AVR Bootloader in C - eine einfache Anleitung

2019-10-30T21:50:28Z

Pfleury: /* Software */

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.peterfleury.epizy.com/avr-software.html 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ändnis 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 besonderen 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 entspricht 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://www.peterfleury.epizy.com/avr-software.html UART-Library] von [http://www.peterfleury.epizy.com 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:

'''Achtung! Bitte unbedingt die Bezeichnung des SFRs für das Umschalten der Interruptvektoren beachten: bei Atmega88: MCUCR, bei Atmega8: GICR (s. auch etwas weiter unten)'''

<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 wie 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'' kennzeichnet 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 vom 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>

== Fehler bei Flash > 64k ==
Neuere avr-gcc optimieren den oben beschriebenen Bootloader mit so genannten "table jumps". Darin verwendet der Compiler LPM Instruktionen. Laut dem "AVR Instruction Set" kann dieser Befehl aber nur für Adressen bis 64k verwendet werden. Liegt nun der Bootloader am Ende eines 128k Flashs kann dies zum Absturz resp. Neustart des Controllers führen. Abhilfe schafft z.B. die Optimierungsoption "-fno-jump-tables".

= 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]]

GPS Logger

2019-10-30T21:24:32Z

Pfleury: /* Verwendete Libraries */

[[Bild:gLogger_Logo.png|right]]
''von Martin 'Kaktus621' Matysiak''

==Wichtige Information==

Mittlerweile gibt es diesen GPS-Logger in einer deutlich kleineren und verbesserten Version: [[GPS Logger Mini]].

==Einleitung==

Der Sommer nähert sich und die Versuchung steigt, sich mal vom Arbeitstisch zu entfernen und etwas im Freien zu unternehmen. Wie schön wäre es, den Bekannten daheim oder den Freunden im Internet ganz leicht zu zeigen, wo man überall gewesen ist?

Dies war der Auslöser für mein erstes großes Projekt : Ein GPS-Logger!

Über ein GPS Modul empfängt das Gerät die aktuelle Position des Trägers und schreibt diese auf eine SD-Speicherkarte.
Zu Hause angekommen kann man die aufgezeichneten Daten unter verschiedenen Gesichtspunkten analysieren, zum Beispiel die zurückgelegte Strecke (in Google Earth betrachtbar) oder die bewältigten Höhenmeter.

Der GPS-Logger besteht im Groben aus den folgenden 3 Komponenten:

* Ein AVR Mikrocontroller (z. B. ATMega32)
* Ein GPS Modul (z. B. Navilock NL507 TTL)
* Eine SD Speicherkarte

== Hardware ==

=== Planung ===
Neben den drei Hauptkomponenten gehören natürlich noch ein paar andere Teile zur Schaltung, damit die Kommunikation untereinander funktioniert. Im Folgenden der Schaltplan meines Aufbaus:

[[Bild:gLogger_schalt_v2.png|300px]]

Versorgt wird es von einem LiPo-Handyakku, der im voll geladenen Zustand 4,1V liefert. Das Ganze wird auf einer einseitigen Platine (u.A. mit Verwendung von SMD Bauteilen) aufgebaut, hier das Board Layout:

[[Bild:gLogger_board_v2.png|300px]]

=== Umsetzung ===
Und so sieht das Ganze fertig bestückt aus:

[[Bild:gLogger_platine_top.jpg|300px]] [[Bild:gLogger_platine_bottom.jpg|300px]]

Der TQFP AVR hat mir schon ein paar Schwierigkeiten beim Löten bereitet, aber es hat alles geklappt (konnte keine Kurzschlüsse feststellen), auch wenn es nicht ganz perfekt aussieht. Der verwendete MicroSD Kartenslot ist erhältlich bei CSD-Electronics unter der Artikelnummer SCHA2B0300.

Nachtrag 08.08.08:
Der eingesetzte MosFET stellt sich als in diesem Fall unbrauchbar heraus, da er einen zu hohen Source-Drain Widerstand besitzt, was zur Folge hat, dass das GPS Modul mit seinen ca. 60mA Stromverbrauch zu wenig Spannung erhält (lediglich 2,4V anstatt der vollen 3,3V).
Gelöst werden kann das Problem durch einen BSS138 als Ersatz, diesen gibt es allerdings nur im SOT23 Gehäuse, weshalb ich das Layout und den Schaltplan soeben aktualisiert habe. Ansonsten kann man den MosFET auch einfach entfernen, die Source-Drain-Strecke überbrücken und hat so immer volle 3,3V am GPS Modul (allerdings fehlt dann die Möglichkeit des Abschaltens bei schwachem Akku).

Außerdem habe ich das Gehäuse nun fertiggestellt, hier neue Fotos:

[[Bild:gLogger_gehaeuse_auf.jpg|300px]] [[Bild:gLogger_gehaeuse_zu.jpg|300px]]

=== Downloads ===
* [[Media:gLogger_eagle.zip|Eagle Projekt Dateien zum gLogger]]

== Software ==

=== AVR ===

==== Features ====

* Aufnahme kann per Taster gestartet / gestoppt werden
* Status LEDs zeigen den Status an
* Speicherverbrauch : ca. 1,4 MB pro Stunde (bei GPS Fix und 7 NMEA Meldungen pro Sekunde), man kann natürlich 6 von den 7 Meldungen abschalten, wenn man NUR die Position haben möchte, dann sinkt der Speicherverbrauch auf ca. 200KB pro Stunde
* Automatischer Stromsparmodus bei schwachem Akku (Aufnahme wird gestoppt, GPS Modul deaktiviert, der Mikrocontroller in einen Sleep-Modus versetzt)

==== Verwendete Libraries ====

* [[http://www.peterfleury.epizy.com/ UART library von Peter Fleury]]
* [[http://www.ulrichradig.de/home/index.php/avr/mmc-sd MMC/SD library von Ulrich Radig]]
* [[http://www.mikro-control.de/Joomla/index.php?option=com_content&task=view&id=5&Itemid=26 FAT16 library von Stephan Busker]]

==== Changelog ====

Version 1.02 (16.08.2008):

* Akkuspannung wird über den ADC ausgelesen und bei einer Akkuspannung kleiner als ca. 3,6V die Aufnahme gestoppt, das GPS Modul abgeschaltet und der µC in einen Sleepmode versetzt (muss noch getestet werden)
* Blinken während der Aufnahme überarbeitet (per Timer Interrupt)

Version 1.01 (17.07.2008):

* GPS Library um den Befehl gps_get_nmea erweitert -> Wartet erst auf einen vollständigen NMEA Datensatz und schreibt diesen in den übergebenen Buffer
* Die Ledcodes wurden überarbeitet. Überschreiben nicht mehr den ganzen Ports (wodurch z. B. Pull-Ups deaktiviert werden könnten) sondern verändern nur die jeweiligen Bits der Leuchtdioden

Version 1.00 (12.07.2008):

* Erstes öffentliches Release
* AVR empfängt im Aufzeichnungsmodus fortlaufend Zeichen vom GPS Modul und schreibt diese direkt auf die SD Karte

==== FAQ ====

Falls ihr Fragen oder Probleme habt, wendet euch per E-Mail an [[mailto:mail@k621.de mich]] oder schreibt die Frage in die [[http://www.mikrocontroller.net/topic/102452 Foren-Diskussion]]. Wenn ihr damit einverstanden seid, werde ich die Fragen dann auch hier veröffentlichen.

===== Was hat es mit den LED-Codes auf sich? =====
''eingesandt von Marcel''

Es gibt drei Leuchtdioden, nämlich '''LED_STAT''' (Grün), '''LED_WARN''' (Gelb) und '''LED_BATT''' (Rot).

'''Erste Regel:''' Ein Blinken ist ein gutes Zeichen dafür, dass alles funktioniert.

'''Zweite Regel:''' Grün bedeutet alles OK, Gelb möchte vor etwas Warnen und Rot zeigt an, dass der Akku schwach ist.

* Wenn alles in Ordnung ist, sollte nach dem Einschalten '''LED_WARN''' Blinken. Dies bedeutet, dass sich der Controller in der Hauptschleife befindet, aber keine Aufnahme läuft - Also kein Grund zur Sorge. Ist dies nicht der Fall (z. B. '''LED_WARN''' leuchtet dauerhaft), dann hat höchstwahrscheinlich die Initalisierung der SD Karte nicht funktioniert
* Betätigt man nun die Aufnahmetaste, leuchtet zunächst '''LED_STAT''' als Feedback auf, nach ca. 2 Sekunden erlischen dann beide LED's und '''LED_STAT''' beginnt zu blinken, das bedeutet, dass die Aufnahme läuft

===== Wieso kann ich die Aufnahme nicht beenden ? =====
''eingesandt von Marcel''

Es kann der Fall auftreten, dass ihr die Aufnahme ganz normal starten konntet und '''LED_STAT''' auch blinkt, aber ein erneutet Druck auf die Taste bewirkt nichts.

Dies ist ein anzeichen dafür, dass der Controller beim Auslesen der NMEA Meldung stecken geblieben ist. Die LED blinkt weiter, da diese über einen Timer gesteuert wird, parallel zum Hauptprogramm.

Wieso bleibt der Controller denn einfach so stecken? Das hat entweder den Grund, dass das GPS-Modul überhaupt nicht angesteckt ist, oder aber, dass dieses keine NMEA-Konformen Meldungen ausgibt oder die falsche Baudrate eingestellt ist.

==== Download ====

* [[Media:gLogger_avr_1.02.zip|gLogger AVR Software - Version 1.02 (16.08.2008)]]
* [[Media:gLogger_avr_1.01.zip|gLogger AVR Software - Version 1.01 (17.07.2008)]]

=== Computer ===

[[Bild:gLogger_nmeaTool.png|thumb|300px|Screenshot der NMEA Toolbox]]

Für den Computer habe ich derweilen eine Software entwickelt, die die aufgezeichneten GPS Daten verarbeiten kann und diese zum Beispiel in eine *.kml-Datei (Für Google Earth oder Google Maps) schreibt, oder aber Höhen- und Geschwindigkeitsdiagramme erstellen kann.

Die Funktion des Konvertierens zu *.kml funktioniert derzeit perfekt, die Optionen zum erstellen der Höhen- und Geschwindigkeitsdiagramme erzeugen bis jetzt lediglich Excel-Tabellen, wo man sich später leicht ein Diagramm anzeigen lassen kann, geplant ist allerdings, dass die "NMEA Toolbox" direkt Diagramme erstellt und anzeigt.

Die Toolbox wurde in Java entwickelt, der NetBeans-Projektordner in seiner aktuellen Version, sowie die kompilierte *.jar zum ausführen liegt hier als Download bereit.

==== Features ====

* Eingabeformat : Jedes beliebige, solange NMEA-Datensätze der Dateiinhalt sind
* Ausgabeformat :
** Google Earth Pfad (*.kml)
** Google Maps Pfad (*.kml)[1]
** Geschwindigkeitsdiagramm (*.csv)[2]
** Höhendiagramm (*.csv)[2]
** GPX-Track (*.gpx)
* Verschiedene konfigurierbare Filter, um Genauigkeitsverluste des GPS-Moduls möglichst zu entfernen

[1] : Das besondere am Maps Pfad ggü. Google Earth ist, dass hier die Anzahl der Pfadpunkte auf 350 reduziert wird, da Google Maps nicht mehr in einem Pfad akzeptiert, dadurch gibt es allerdings auch einen Verlust von Details in der Strecke

[2] : In Zukunft ist auch ein echtes Diagramm als Ausgabe geplant, dann als *.png oder ähnliches

==== Changelog ====

Version 1.3 (18.04.2010)

* Verwendung von "Preferences" zum Sichern des zuletzt verwendeten Ordners (Implementiert von [http://projekte.esuark.de/ Jens Krause], vielen Dank!)

Version 1.2 (21.03.2009):

* Javadoc angelegt
* Kompletten Code umstrukturiert
** Konvertierer in eigene Klassen gepackt
** Konvertierer laufen nun als Threads
** Insgesamt Code etwas aufgeräumt
* Interface 'erfrischt'
** Konvertier-Buttons durch Grafiken ersetzt (Text wird als Tooltip angezeigt)
** Statusanzeige eingebaut
* Weitere kleine Übersetzungen auf Deutsch
* Im description-Tag der KML-Datei wird nun das Erstellungsdatum angezeigt
* Einige Filter entfernt (werden nun autom. ausgeführt)
* Google Maps Frage erscheint nur noch, wenn man eine KML Datei erstellen möchte und der Pfad mehr als 350 Punkte besitzt
* Google Maps - Reduzieralgorithmus optimiert
* GPX Format implementiert

Version 1.1 (03.01.2009):

* Meldungen in Dialogfenstern auf Deutsch übersetzt
* Fehler bei Google-Maps-Filter behoben

Version 1.0d (25.09.2008):

* NMEA Toolbox auf Deutsch übersetzt

Version 1.00 (12.07.2008):

* Erstes öffentliches Release

==== FAQ ====

Falls ihr Fragen oder Probleme habt, wendet euch per E-Mail an [[mailto:mail@k621.de mich]] oder schreibt die Frage in die [[http://www.mikrocontroller.net/topic/102452 Foren-Diskussion]]. Wenn ihr damit einverstanden seid, werde ich die Fragen dann auch hier veröffentlichen.

==== Download ====

* [[Media:nmea_toolbox_src_1.3.zip|NMEA Toolbox - NetBeans Projektordner V1.3]]
* [[Media:nmea_toolbox_jar_1.3.zip|NMEA Toolbox - Ausführbare .jar V1.3]]
* [[Media:nmea_toolbox_src_1.2.zip|NMEA Toolbox - NetBeans Projektordner V1.2]]
* [[Media:nmea_toolbox_jar_1.2.zip|NMEA Toolbox - Ausführbare .jar V1.2]]
* [[Media:nmea_toolbox_src_1.1.zip|NMEA Toolbox - NetBeans Projektordner V1.1]]
* [[Media:nmea_toolbox_jar_1.1.zip|NMEA Toolbox - Ausführbare .jar V1.1]]
* [[Media:nmea_toolbox_src_1.0.d.zip|NMEA Toolbox - NetBeans Projektordner V1.0d]]
* [[Media:nmea_toolbox_jar_1.0.d.zip|NMEA Toolbox - Ausführbare .jar V1.0d]]
* [[Media:nmea_toolbox_src.zip|NMEA Toolbox - NetBeans Projektordner V1.0]]
* [[Media:nmea_toolbox_jar.zip|NMEA Toolbox - Ausführbare .jar V1.0]]

== To-Do / Ideen für die Zukunft ==

* Stromversorgung überdenken -> Geht es effizienter?
** Ja, siehe aktuelle Schaltung

* Das ganze auf einer richtigen Platine entwerfen, evtl. SMD-Bauteile verwenden, damit das Gerät noch kleiner wird
** Erledigt; Layout siehe oben, 6 Drahtbrücken, Platinengröße 61mm x 72mm

* Eine kompakte SMD-Platine entwerfen.

* Erweiterung : Einfaches Navigationssystem -> Am Computer wird ein Pfad festgelegt und das Gerät leitet einen von Wegpunkt zu Wegpunkt, indem die Richtung über LEDs oder ein Display gezeigt wird
** Idee wieder verworfen, Statusanzeige über Display wird aber möglicherweise noch realisiert

* Besseren Algorithmus für das Reduzieren der Pfadpunkte in der NMEA Toolbox entwickeln (mit geringerem Genauigkeitsverlust)
** Ist in Bearbeitung

* NMEA-Toolbox : Export in das *.GPX-Format
** Ist in Bearbeitung

* Echte Diagramme in der NMEA Toolbox erstellen
** Hierfür kann ich dir die JFreeChart Library empfehlen! (falls du die nicht schon kennst) Sehr einfach zu verwenden und macht sehr saubere Diagramme.
** Folgt in der übernächsten Version!

* Über das PC-Tool Parameter verändern (welche Werte sollen aufgezeichnet werden, welche Aufzeichnungsrate...)
** Würde eine direkte Verbindung zw. PC und gLogger erfordern -> vorerst nicht geplant (außer jemand möchte sich da dran setzen? :))
*** Hier wird man fündig: http://www.obdev.com/products/vusb/benefits-de.html, da gibt es viele Beispielprojekte, aus denen man sich das Benötigte zusammenkopieren kann.

* Digitaleingänge hinzu und die zustände dieser im log hinzufügen
** Folgt möglicherweise im Sommer (z. B. Temperaturüberwachung o.ä.)

* Alle Anschlüsse zum AVR per Pads freilegen

* Anschlussmöglichkeit für große Tastenmatrix (30-50 Tasten), um sehr schnell Geo-Attribute eingeben zu können. Die Idee ist, es für OpenStreetMap zu verwenden: dann kann man auf Knopfdruck "ab hier asphaltiert", "hier Foto gemacht", "hier steht eine Bank" usw. eingeben.
** Eine gute Idee. An sich kann man die Tastatur an den freigelegten Port klemmen, man müsste dann nur noch die Software dementsprechend anpassen

== Beispiele ==

* [http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=102721812355516657756.0004540865131e3917627 Beispiel-Route in Google Maps]

[[Bild:gLogger_vgl.jpg|thumb|600px|Genauigkeitsvergleich Google Maps Pfad - Originalpfad (G. Earth)]]

<hr style="visibility:hidden; clear:both">

== Siehe Auch ==

* Diskussion im Forum : http://www.mikrocontroller.net/topic/102452

== Weblinks ==

* [http://www.sparkfun.com/datasheets/GPS/NMEA%20Reference%20Manual1.pdf NMEA Reference Manual (PDF-Dokument)]

[[Category:1. Wettbewerb]]
[[Kategorie:GPS]]
[[Kategorie:AVR-Projekte]]

AVR-GCC-Tutorial/Der UART

2019-10-30T21:22:53Z

Pfleury: /* Einzelne Zeichen empfangen */

Über den [[UART]] kann ein [[AVR]] leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "[[seriell]]er Schnittstelle" verbunden werden.

== Allgemeines zum UART ==

Mögliche Anwendungen des UART:

;Debug-Schnittstelle: z. B. zur Anzeige von Zwischenergebnissen ("printf-debugging" - hier besser "Logging" oder "UART-debugging") über [[RS-232]] auf einem PC. Auf dem Rechner reicht dazu ein [[RS-232#Terminalprogramme|Terminalprogramm]] (MS-Windows: Hyperterm oder besser [https://sites.google.com/site/terminalbpp/], [http://www.der-hammer.info/terminal/ HTerm]; Unix/Linux z. B. minicom). Ein direkter Anschluss ist aufgrund unterschiedlicher Pegel nicht möglich, jedoch sind entsprechende Schnittstellen-ICs wie z. B. ein MAX232 günstig und leicht zu integrieren. Rechner ohne serielle Schnittstelle können über fertige USB-seriell-Adapter angeschlossen werden.
;Mensch-Maschine Schnittstelle: z. B. Konfiguration und Statusabfrage über eine "Kommandozeile" oder Menüs (siehe z. B. Forumsbeitrag [http://www.mikrocontroller.net/topic/52985 Auswertung RS232-Befehle] und Artikel [[Tinykon]])
;Übertragen von gespeicherten Werten: z. B. bei einem Datenlogger
;Anschluss von Geräten: mit serieller Schnittstelle (z. B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger).
;"Feldbusse": auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z. B. MAX485)
;DMX, Midi: etc.
;LIN-Bus: '''L'''ocal '''I'''nterconnect '''N'''etwork: Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus

Einige AVR-Controller haben ein bis zwei vollduplexfähige UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART").
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.

Neuere AVRs (ATmega, ATtiny) verfügen über einen bis vier U'''S'''ART(s), dieser unterscheidet sich vom UART hauptsächlich durch interne FIFO-Puffer für Ein- und Ausgabe und erweiterte Konfigurationsmöglichkeiten. Die Puffergröße ist allerdings nur 1 Byte.

== Die Hardware ==

Der UART basiert auf normalem TTL-Pegel mit 0V (logisch 0) und 5V (logisch 1). Die Schnittstellenspezifikation für RS-232 definiert jedoch -12V ... -3V (logisch 1) und
+3 ... +12V (logisch 0). Daher muss der Signalaustausch zwischen AVR und Partnergerät invertiert werden. Für die Anpassung der Pegel und das Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste davon ist wohl der MAX232.


Streikt die Kommunikation per UART, so ist oft eine fehlerhafte Einstellung der Baudrate die Ursache. Die Konfiguration auf eine bestimmte Baudrate ist abhängig von der Taktfrequenz des Controllers. Gerade bei neu aufgebauten Schaltungen (bzw. neu gekauften Controllern) sollte man sich daher noch einmal vergewissern, dass der Controller auch tatsächlich mit der vermuteten Taktrate arbeitet und nicht z. B. den bei einigen Modellen werksseitig eingestellten internen [[Oszillator]] statt eines externen Quarzes nutzt. Die Werte der verschiedenen fuse-bits im Fehlerfall also beispielsweise mit ''[[AVRDUDE]]'' kontrollieren und falls nötig anpassen. Grundsätzlich empfiehlt sich auch immer ein Blick in die [[AVR_Checkliste]].

Controller mit nur einem Quarzanschluss (z.B Atmega328), die den Timer2 im Asynchron Modus benutzen, müssen intern mit dem RC-Oszillator getaktet werden. Dieser sollte dann kalibriert werden:
[[AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Kalibrieren_des_internen_Oszillators_mit_Timer2_als_Zeitbasis|Kalibrieren des internen Oszillators mit Timer2 als Zeitbasis]]

== Die UART-Register ==

Die UART wird über vier separate Register angesprochen. Die USARTs der ATMEGAs verfügen über mehrere zusätzliche Konfigurationsregister. Das Datenblatt gibt darüber Auskunft. Die folgende Tabelle gibt nur die Register für die UARTs der ATmega8/16/32 u.ä. wieder.

{| class="wikitable"
|-
| width="100" | '''UCSRA   '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''A'''. 
Hier teilt uns der UART mit, was er gerade so macht.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXC'''|| '''TXC'''|| '''UDRE'''|| '''FE'''|| '''DOR'''|| '''PE'''|| '''U2X'''|| '''MPCM'''
|-
! R/W
| R|| R/W|| R|| R|| R|| R|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 1|| 0|| 0|| 0|| 0|| 0
|}

'''RXC''' (UART Receive Complete)
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.
:Das Zeichen muss nun schnellstmöglich aus dem Datenregister ausgelesen werden. Falls dies nicht erfolgt, bevor ein weiteres Zeichen komplett empfangen wurde, wird eine Überlauf-Fehlersituation eintreten. Mit dem Auslesen des Datenregisters wird das Bit automatisch gelöscht.

'''TXC''' (UART Transmit Complete)
:Dieses Bit wird vom AVR gesetzt, wenn das im Sende-Schieberegister befindliche Zeichen vollständig ausgegeben wurde und kein weiteres Zeichen im Sendedatenregister ansteht. Dies bedeutet also, dass die Kommunikation vollumfänglich abgeschlossen ist.
:Dieses Bit ist wichtig bei Halbduplex-Verbindungen, wenn das Programm nach dem Senden von Daten auf Empfang schalten muss. Im Vollduplexbetrieb brauchen wir dieses Bit nicht zu beachten.
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.
:Um das Bit zu löschen muss eine 1 an die entsprechende Position geschrieben werden!

'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)
:Dieses Bit zeigt an, ob der Sendepuffer bereit ist, um ein zu sendendes Zeichen aufzunehmen. Das Bit wird vom AVR gesetzt (1), wenn der Sendepuffer leer ist. Es wird gelöscht (0), wenn ein Zeichen im Sendedatenregister vorhanden ist und noch nicht in das Sende-Schieberegister übernommen wurde. Atmel empfiehlt aus Kompatibilitätsgründen mit kommenden µC, UDRE auf 0 zu setzen, wenn das UCSRA Register beschrieben wird.
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.

'''FE''' ('''F'''raming '''E'''rror)
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.

'''DOR''' ('''D'''ata '''O'''ver '''R'''un)
:Dieses Bit wird vom AVR gesetzt, wenn unser Programm das im Empfangsdatenregister bereit liegende Zeichen nicht abholt bevor das nachfolgende Zeichen komplett empfangen wurde.
:Das nachfolgende Zeichen wird verworfen.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''PE''' ('''P'''arity '''E'''rror''')
:Dieses Bit wird vom AVR gesetzt, wenn das im Empfangsdatenregister bereit liegende Zeichen einen Paritätsfehler aufweist.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''U2X''' (Double the transmission speed)
:Dieses Bit wird lediglich im asynchronen Modus genutzt. Im synchronen Modus ist es 0 zu setzen. Wird das Bit gesetzt, so wird der Baudraten Divisor von 16 auf 8 reduziert, was einer Verdopplung der Transferrate gleich kommt.

'''MPCM''' ('''M'''ulti '''P'''rozessor '''C'''ommunication '''M'''ode)
:Dieses Bit aktiviert die Multi-Prozessor-Kommunikation. Jeder eintreffende Frame der keine Adressinformation enthält wird dadurch ignoriert.

|-
| '''UCSRB    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''B'''. 
In diesem Register stellen wir ein, wie wir den UART verwenden möchten. 
Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXCIE'''|| '''TXCIE'''|| '''UDRIE'''|| '''RXEN'''|| '''TXEN'''|| '''UCSZ2'''|| '''RXB8'''|| '''TXB8'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART RX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART empfangen wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART TX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART gesendet wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART Datenregister Leer Interrupt ausgelöst, wenn der UART wieder bereit ist um ein neues zu sendendes Zeichen zu übernehmen. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''RXEN''' ('''R'''eceiver '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Empfänger des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''TXEN''' ('''T'''ransmitter '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Sender des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''UCSZ2''' (Characters Size)
:Dieses Bit setzt in Verbindung mit dem UCSZ1:0 Bits im UCSRC Register die Anzahl von Datenbits eines Frames beim Empfang oder Senden.

'''RXB8''' (Receive Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.

'''TXB8''' (Transmit Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann muss in dieses Bit das 9. Bit des zu sendenden Zeichens eingeschrieben werden bevor das eigentliche Datenbyte in das Datenregister geschrieben wird.
|-
| '''UCSRC    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''C'''. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''URSEL'''|| '''UMSEL'''|| '''UPM1'''|| '''UPM0'''|| '''USBS'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''UCPOL'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 1|| 0|| 0|| 0|| 0|| 1|| 1|| 0
|}

'''URSEL''' (Register Select)
:Dieses Bit selektiert die Auswahl des UCSRC- bzw. des UBRRH Registers. Beim Lesen von UCSRC wird es als 1 gelesen. Beim Schreiben auf UCSRC muss es auf 1 gesetzt werden.

:Achtung: Manche Prozessoren verfügen über dieses Bit, andere wiederrum nicht. Was hat es damit auf sich? Um Zugriffsadressen einzusparen, wurde von Atmel ein etwas seltsamer Weg gewählt. Das UCSRC Register und das High-Byte des Baudratenregisters teilen sich dieselbe Registeradresse! Um der Hardware mitzuteilen, welche Bedeutung ein zugewiesener Wert haben soll, entweder neue Belegung des Baudratenregisters oder eben Konfiguration des UCSRC Registers, dient dieses Bit. Ist es nicht gesetzt, dann wird eine Zuweisung immer als Zuweisung an das High-Byte des Baudratenregisters angesehen, selbst wenn das so nicht beabsichtigt war. Nur dann wenn dieses Bit gesetzt ist, dann wird eine Zuweisung auch tatsächlich als eine Zuweisung an das UCSRC Register gewertet und die Konfiguration verändert. Lässt man das Bit irrtümlich weg, dann verursacht eine Zuweisung an UCSRC eine Veränderung der Baudrateneinstellung!

'''UMSEL''' (USART Mode Select)
:Durch dieses Bit kann eine asynchrone oder synchrone Übertragung eingestellt werden. Durch Setzen des Bits wird eine synchrone Übertragung eingestellt.

'''UPM1:0''' (Parity Mode)
{| class="wikitable" style="text-align:center"
|-
| '''UPM1'''|| '''UPM0'''|| '''Parity Mode'''
|-
| 0|| 0|| Disabled
|-
| 0|| 1|| Reserved
|-
| 1|| 0|| Enabled, Even Priority
|-
| 1|| 1|| Enabled, OddPriority
|}

'''USBS''' ('''U'''SART '''S'''top '''B'''it '''S'''elect)
:Diese Bits setzen die Anzahl der zu sendenden Stopbits eines Frames. Beim Setzen werden 2 Stopbits übertragen, andernfalls nur 1 Stopbit.
{| class="wikitable" style="text-align:center"
|-
| '''USBS'''|| '''Anzahl der Stop Bits'''
|-
| 0|| 1
|-
| 1|| 2

|}

'''UCSZ1:0''' (Character Size)
:Diese Bits setzen in Verbindung mit UCSZ2 aus dem UCSRB Register die Anzahl der Datenbits eines Frames.
:Diese Bits setzen den entsprechenden Paritätsmodus.
{| class="wikitable" style="text-align:center"
|-
| '''UCSZ2'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''Character Size'''
|-
| 0|| 0|| 0|| 5-Bit
|-
| 0|| 0|| 1|| 6-Bit
|-
| 0|| 1|| 0|| 7-Bit
|-
| 0|| 1|| 1|| 8-Bit
|-
| 1|| 0|| 0|| Reserved
|-
| 1|| 0|| 1|| Reserved
|-
| 1|| 1|| 0|| Reserved
|-
| 1|| 1|| 1|| 9-Bit
|}

'''UCPOL''' (Clock Polarity)

|-
| '''UDR'''
| '''U'''ART '''D'''ata '''R'''egister. 
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf
den UART erfolgt wird automatisch das richtige UDR angesprochen.
|-
| '''UBRR'''
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister. 
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne kommunizieren möchten. Der Wert, der in dieses Register geschrieben werden muss, errechnet sich nach folgender Formel (wenn U2X Bit 0 gesetzt ist):

:<math>
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1
</math>

Es sind Baudraten bis über 115200 Baud möglich, je nach Controller und CPU-Frequenz. Siehe Datenblatt.
|}

== UART initialisieren ==

Wir wollen nun Daten mit dem UART auf die serielle Schnittstelle ausgeben. Dazu müssen wir den UART zuerst mal initialisieren. Dazu setzen wir je nach gewünschter Funktionsweise die benötigten Bits im '''U'''ART '''C'''ontrol '''R'''egister.

Da wir vorerst nur senden möchten und noch keine Interrupts auswerten wollen, gestaltet sich die Initialisierung wirklich sehr einfach, da wir lediglich das '''Transmitter Enable''' Bit setzen müssen:

<syntaxhighlight lang="c">
UCSRB |= (1<<TXEN);
</syntaxhighlight>

Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z. B.:

<syntaxhighlight lang="c">
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC = (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
</syntaxhighlight>

Nun ist noch das Baudratenregister '''UBRR''' der verwendeten UARTs einzustellen, bzw. bei neueren AVRs die beiden Register '''UBRRL''' und '''UBRRH'''. . Die Berechnung wird während des Compilerlaufs ausgeführt, beansprucht also in der gezeigten Form weder Speicher noch Rechenzeit des Controllers. Das Ergebniss wird jedoch als ganzzahliger Wert eingesetzt, d.h. Nachkommastellen werden einfach abgeschnitten und es erfolgt keine Rundung. Aus diesem Grund kann man sich eines kleinen Tricks bedienen, indem vor der eigentlichen Division bei der Zuweisung die Hälfte des Wertes dazu addiert wird. Allgemein formuliert bedeutet das: <code>int i = ( a + b/2 ) / b;</code>. Dies wird in der unten angegebenen Berechnung von UBRR_VAL ausgenutzt um den Fehler zu minimieren. (Eine ausführliche Erklärung zum ''cleveren Runden'' findet sich in einer [http://www.mikrocontroller.net/topic/170617#1631916 Forumsdiskussion].)

<syntaxhighlight lang="c">
/*
UART-Init:
Berechnung des Wertes für das Baudratenregister
aus Taktrate und gewünschter Baudrate
*/

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten
// Ohne ergeben sich unten Fehler in der Berechnung
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif
</syntaxhighlight>

Die Makros sind sehr praktisch, da damit sowohl automatisch der Wert für UBRR, als auch die Abweichung in der generierten (möglichen) von der gewünschten Baudrate berechnet wird. Im Falle einer zu hohen Abweichung (+/-1%) wird eine Fehlermeldung ausgegeben und der Compilerablauf abgebrochen. Damit können viele Probleme mit "UART sendet komische Zeichen" vermieden werden. Ausserdem kann man mühelos die Einstellung an eine neue Taktfrequenz bzw. Baudrate anpassen, ohne selber rechnen oder in Tabellen nachschlagen zu müssen.

Die eigentliche Initialisierung der UART Register kann im Hauptprogramm main() vorgenommen werden. Öfters wird jedoch eine Funktion z. B. uart_init() dafür geschrieben, die in der eigenen Codesammlung in mehreren Projekten verwendet werden kann.

Für einige AVR (z. B. ATmega169, ATmega48/88/168, AT90CAN jedoch nicht für z. B. ATmega16/32, ATmega128, ATtiny2313) wird durch die Registerdefinitionen der avr-libc (io*.h) auch für Controller mit zwei UBRR-Registern (UBRRL/UBRRH) ein UBRR bzw. UBRR0 als "16-bit-Register" definiert und man kann den Wert direkt per UBRR = UBRR_VAL zuweisen. Intern werden dann zwei Zuweisungen für UBRRH und UBRRL generiert.

<syntaxhighlight lang="c">
/* UART-Init Bsp. ATmega48 */

void uart_init(void)
{
UBRR0 = UBRR_VAL;
UCSR0B |= (1<<TXEN0);
// Frame Format: Asynchron 8N1
UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
}
</syntaxhighlight>

Die einzelne Anweisung ist nicht bei allen Controllern möglich, da die beiden Register nicht bei allen aufeinanderfolgende Addressen aufweisen. Die getrennte Zuweisung an UBRRH und UBRRL wie im nächsten Beispiel gezeigt, ist universeller und portabler und daher vorzuziehen. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird:

<syntaxhighlight lang="c">
/* UART-Init Bsp. ATmega16 */

void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;

UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
}
</syntaxhighlight>

Inzwischen gibt es in der avr-libc Makros für obige Berechnung der UBRR Registerwerte aus Taktrate F_CPU und Baudrate BAUD. Dazu wird die Includedatei [http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html <util/setbaud.h>] eingebunden, nachdem F_CPU und die gewünschte Baudrate definiert wurden. Einige Beispiele zur Anwendung finden sich in der Dokumentation der avr-libc. Im Quellcode kann dann analog zur oben gezeigten Vorgehensweise einfach das Makro UBRR_VALUE (bzw. UBRRH_VALUE und UBRRL_VALUE) an der entsprechenden Stelle eingesetzt werden. Es wird auch automatisch ermittelt, ob der U2X-Modus (vgl. Datenblatt) zu geringeren Abweichungen führt und dann dem Makro USE_U2X ein Wert ungleich null zugewiesen. Ein Beispiel (angelehnt an die avr-libc-Dokumentation):

<syntaxhighlight lang="c">
#include <avr/io.h>
#define F_CPU 1000000 /* evtl. bereits via Compilerparameter definiert */
#define BAUD 9600
#include <util/setbaud.h>

void uart_init(void)
{
UBRRH = UBRRH_VALUE;
UBRRL = UBRRL_VALUE;
/* evtl. verkuerzt falls Register aufeinanderfolgen (vgl. Datenblatt)
UBRR = UBRR_VALUE;
*/
#if USE_2X
/* U2X-Modus erforderlich */
UCSRA |= (1 << U2X);
#else
/* U2X-Modus nicht erforderlich */
UCSRA &= ~(1 << U2X);
#endif

// hier weitere Initialisierungen (TX und/oder RX aktivieren, Modus setzen
}
</syntaxhighlight>

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html Dokumentation der avr-libc zu <util/setbaud.h>]
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.
* [http://www.gjlay.de/helferlein/avr-uart-rechner.html AVR Baudraten-Rechner] in JavaScript

== Senden mit dem UART ==

=== Senden einzelner Zeichen ===

Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe
lediglich in das '''U'''ART '''D'''ata '''R'''egister schreiben. Vorher ist zu prüfen, ob das UART-Modul bereit ist, das zu sendende Zeichen entgegenzunehmen. Die Bezeichnungen des/der Statusregisters mit dem Bit UDRE ist abhängig vom Controllertypen (vgl. Datenblatt).

<syntaxhighlight lang="c">
// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */

// das entpricht dem "C Code Example USART_Transmit" in der ATMEL-Doku ...
// besser ist es aber, die CPU nicht in einer Warteschleife zu blockieren:

if(UCSRA & (1<<UDRE)) /* Senden, wenn UDR frei ist */
{ UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */
}
</syntaxhighlight>
Zum "Blockieren" vgl. [[AVR-GCC-Tutorial#Warten_auf_einen_bestimmten_Zustand|AVR-GCC-Tutorial]]

=== Senden einer Zeichenkette (String) ===

Die Aufgabe "String senden" wird durch zwei Funktionen abgearbeitet. Die universelle/controllerunabhängige Funktion uart_puts übergibt jeweils ein Zeichen der Zeichenkette an eine Funktion uart_putc, die abhängig von der vorhandenen Hardware implementiert werden muss. In der Funktion zum Senden eines Zeichens ist darauf zu achten, dass vor dem Senden geprüft wird, ob der UART bereit ist den "Sendeauftrag" entgegenzunehmen.

<syntaxhighlight lang="c">
/* ATmega16 */
int uart_putc(unsigned char c)
{
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/* puts ist unabhaengig vom Controllertyp */
void uart_puts (char *s)
{
while (*s)
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen(Terminator)" */
uart_putc(*s);
s++;
}
}
</syntaxhighlight>

Die in uart_putc verwendeten Schleifen, in denen gewartet wird bis die UART-Hardware zum senden bereit ist, sind insofern etwas kritisch, da während des Sendens eines Strings nicht mehr auf andere Ereignisse reagiert werden kann. Universeller ist die Nutzung von FIFO(first-in first-out)-Puffern, in denen die zu sendenden bzw. empfangenen Zeichen/Bytes zwischengespeichert und in Interruptroutinen an die U(S)ART-Hardware weitergegeben bzw. von ihr ausgelesen werden. Dazu existieren fertige Komponenten (Bibliotheken, Libraries), die man recht einfach in eigene Entwicklungen integrieren kann. Es empfiehlt sich, diese Komponenten zu nutzen und das Rad nicht neu zu erfinden.

=== Senden von Variableninhalten ===

Sollen Inhalte von Variablen (Ganzzahlen, Gleitkomma) in "menschenlesbarer" Form gesendet werden, ist vor dem Transfer eine Umwandlung in Zeichen ("ASCII") erforderlich. Bei nur einer Ziffer ist diese Umwandlung relativ einfach: man addiert den ASCII-Wert von Null zur Ziffer und kann diesen Wert direkt senden.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>
//...

// hier uart_putc (s.o.)

int main (void)
{
// Ausgabe von 0123456789
char c;

uart_init();

for (uint8_t i=0; i<=9; ++i) {
c = i + '0';
uart_putc( c );
// verkuerzt: uart_putc( i + '0' );
}

while (1) {

}

return 0; // never reached

}
</syntaxhighlight>

Soll mehr als eine Ziffer ausgegeben werden, bedient man sich zweckmäßigerweise vorhandener Funktionen zur Umwandlung von Zahlen in Zeichenketten/Strings. Die Funktion der avr-libc zur Umwandlung von vorzeichenbehafteten 16bit-Ganzzahlen (int16_t) in Zeichenketten heißt ''itoa'' (Integer to ASCII). Man muss der Funktion einen Speicherbereich zur Verarbeitung (buffer) mit Platz für alle Ziffern, das String-Endezeichen ('\0') und evtl. das Vorzeichen bereitstellen.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

int main(void)
{
char s[7];
int16_t i = -12345;

uart_init();

itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem
uart_puts( s );

// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:
uart_puts( itoa( i, s, 10 ) );

while (1) {
;
}

return 0; // never reached
}
</syntaxhighlight>

Für vorzeichenlose 16bit-Ganzzahlen (uint16_t) exisitert ''utoa''. Die Funktionen für 32bit-Ganzzahlen (int32_t und uint32_t) heißen ''ltoa'' bzw. ''ultoa''. Da 32bit-Ganzzahlen mehr Stellen aufweisen können, ist ein entsprechend größerer Pufferspeicher vorzusehen.

Auch Gleitkommazahlen (float/double) können mit bereits vorhandenen Funktionen in Zeichenfolgen umgewandelt werden, dazu existieren die Funktionen ''dtostre'' und ''dtostrf''. dtostre nutzt Exponentialschreibweise ("engineering"-Format). (Hinweis: z.Zt. existiert im avr-gcc kein "echtes" double, intern wird immer mit "einfacher Genauigkeit", entsprechend float, gerechnet.)

dtostrf und dtostre benötigen die libm.a der avr-libc. Bei Nutzung von Makefiles ist der Parameter -lm in in LDFLAGS anzugeben (Standard in den WinAVR/mfile-Makefilevorlagen). Nutzt man AVRStudio als IDE für den GNU-Compiler (gcc-Plugin) ist die libm.a unter Libaries auszuwählen: Project -> Configurations Options -> Libaries -> libm.a mit dem Pfeil nach rechts einbinden. Siehe auch die [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|FAQ]]

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

/* lt. avr-libc Dokumentation:
char* dtostrf(
double __val,
char __width,
char __prec,
char * __s
)
*/

int main(void)
{
// Pufferspeicher ausreichend groß
// evtl. Vorzeichen + width + Endezeichen:
char s[8];
float f = -12.345;

uart_init();

dtostrf( f, 6, 3, s );
uart_puts( s );
// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );

while (1) {
;
}

return 0; // never reached
}
</syntaxhighlight>

== Empfangen ==
=== Einzelne Zeichen empfangen ===

Zum Empfang von Zeichen muss der Empfangsteil des UART bei der Initialisierung aktiviert werden, indem das RXEN-Bit im jeweiligen Konfigurationsregister (UCSRB bzw UCSR0B/UCSR1B) gesetzt wird. Im einfachsten Fall wird solange gewartet, bis ein Zeichen empfangen wurde, dieses steht dann im UART-Datenregister (UDR bzw. UDR0 und UDR1 bei AVRs mit 2 UARTS) zur Verfügung (sogen. "Polling-Betrieb"). Ein Beispiel für den ATmega16:

<syntaxhighlight lang="c">
#include <inttypes.h>
#include <avr/io.h>

/* Siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */

void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;

UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
UCSRB |= (1<<RXEN); // UART RX einschalten
}

/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}
</syntaxhighlight>

Und die Anwendung in einem Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

// hier Makro für die Baudratenberechnung

// hier uart_init, uart_getc (s.o.)

int main(void)
{
uart_init();
while (1)
{
uint8_t c;
c = uart_getc();

// hier etwas mit c machen z.B. auf PORT ausgeben
DDRC = 0xFF; // PORTC Ausgang
PORTC = c;
}
return 0; // never reached
}
</syntaxhighlight>

Die Funktion uart_getc() blockiert allerdings den Programmablauf, denn es wird gewartet, bis ein Zeichen empfangen wird! Möchte man das Warten vermeiden, kann das RXC-Bit in einer Programmschleife abgefragt werden und dann nur bei gesetztem RXC-Bit UDR ausgelesen werden.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

// hier Makro für die Baudratenberechnung

// hier uart_init, uart_getc (s.o.)

int main(void)
{
uart_init();
while (1)
{
if ( (UCSRA & (1<<RXC)) )
{
// Zeichen wurde empfangen, jetzt abholen
uint8_t c;
c = uart_getc();
// hier etwas mit c machen z.B. auf PORT ausgeben
DDRC = 0xFF; // PORTC Ausgang
PORTC = c;
}
else
{
// Kein Zeichen empfangen, Restprogramm ausführen...
}
}
return 0; // never reached
}
</syntaxhighlight>

Eleganter und in den meisten Anwendungsfällen "stabiler" ist die Vorgehensweise, die empfangenen Zeichen in einer Interrupt-Routine einzulesen und zur späteren Verarbeitung in einem Eingangsbuffer (FIFO-Buffer) zwischenzuspeichern. Dazu existieren fertige und gut getestete [[Libraries|Bibliotheken]]  und Quellcodekomponenten (z. B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_sprintf_und_printf Die Nutzung von sprintf und printf]
* [http://www.peterfleury.epizy.com/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc


TODO: 9bit

=== Empfang von Zeichenketten (Strings) ===

Beim Empfang von Zeichenketten, muß man sich zunächst darüber im klaren sein, daß es ein Kriterium geben muß, an dem der µC erkennen kann, wann ein Text zu Ende ist. Sehr oft wird dazu das Zeichen 'Return' benutzt, um das Ende eines Textes zu markieren. Dies ist vom Benutzer einfach eingebbar und er ist auch daran gewöhnt, daß er eine Eingabezeile mit einem Druck auf die Return Taste abgeschlossen wird.

Prinzipiell gibt es jedoch keine Einschränkung bezüglich dieses speziellen Zeichens. Es muß nur sichergestellt werden, daß dieses spezielle 'Ende eines Strings' - Zeichen nicht mit einem im Text vorkommenden Zeichen verwechselt werden kann. Wenn also im zu übertragenden Text beispielsweise kein ';' vorkommt, dann spricht nichts dagegen, den Benutzer die Eingabe eines Textes mit einem ';' abschließen zu lassen.

Im Folgenden wird die durchaus übliche Annahme getroffen, daß eine Stringübertragung identisch ist mit der Übertragung einer Textzeile und daher mit einem Return ('\n') abgeschlossen wird.

Das Problem der Übertragung eines Strings reduziert sich damit auf die Aufgabenstellung: Empfange und sammle Zeichen in einem char Array, bis entweder das Array voll ist oder das Text Ende Zeichen' empfangen wurde. Danach wird der empfangene Text noch mit einem '\0' Zeichen abgeschlossen um einen Standard C-String daraus zu machen, mit dem dann weiter gearbeitet werden kann.

<syntaxhighlight lang="c">
/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}

void uart_gets( char* Buffer, uint8_t MaxLen )
{
uint8_t NextChar;
uint8_t StringLen = 0;

NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen

// Sammle solange Zeichen, bis:
// * entweder das String Ende Zeichen kam
// * oder das aufnehmende Array voll ist
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {
*Buffer++ = NextChar;
StringLen++;
NextChar = uart_getc();
}

// Noch ein '\0' anhängen um einen Standard
// C-String daraus zu machen
*Buffer = '\0';
}
</syntaxhighlight>

Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer
vernünftigen Größe definiert wird.

<syntaxhighlight lang="c">

char Line[40]; // String mit maximal 39 zeichen

uart_gets( Line, sizeof( Line ) );
</syntaxhighlight>

Bei der Benutzung von sizeof() ist allerdings zu beachten, dass sizeof() nicht die Anzahl der Elemente des Arrays liefert, sondern die Länge in Byte. Da ein char nur ein Byte lang ist, passt der Aufruf 'uart_gets(Line, sizeof( Line ) );' in diesem Fall. Falls man - aus welchen Gründen auch immer - andere Datentypen benutzen möchte, sollte man zur korrekten Angabe der Array-Länge folgende Vorgehensweise bevorzugen:

<syntaxhighlight lang="c">
int Line[40]; // Array vom Typ int

uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );
</syntaxhighlight>

==Interruptbetrieb==

Hier wird das Grundwissen des Artikels [[Interrupt]] und des Abschnitts [[AVR-GCC-Tutorial#Programmieren_mit_Interrupts|AVR-GCC-Tutorial: Programmieren_mit_Interrupts]] vorausgesetzt.

=== Empfangen (RX) ===

Beim ATmega8 muss das '''RXCIE''' Bit im Register UCSRB gesetzt werden, damit ein Interrupt beim Empfang eines Zeichens ausgelöst werden kann.

<syntaxhighlight lang="c">
/* siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */
void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
UCSRB |= (1<<RXEN)|(1<<TXEN)|(1<<RXCIE); // UART RX, TX und RX Interrupt einschalten
}
</syntaxhighlight>

Natürlich muss "Global Interrupt Enable" mittels des Befehls sei() aktiviert sein. Interrupt-spezifische Definitionen werden über die Includedatei eingebunden:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
</syntaxhighlight>

Der Interrupt wird immer ausgelöst, wenn ein Zeichen erfolgreich empfangen wurde. Zusätzlich braucht man die Interruptserviceroutine (ISR).

In diesem Beispiel enthält die ISR einen FIFO-Puffer (First in, First out). Dafür werden ein paar globale Variablen und Makros benötigt:

<syntaxhighlight lang="c">
#define UART_MAXSTRLEN 10

volatile uint8_t uart_str_complete = 0; // 1 .. String komplett empfangen
volatile uint8_t uart_str_count = 0;
volatile char uart_string[UART_MAXSTRLEN + 1] = "";
</syntaxhighlight>

<syntaxhighlight lang="c">
ISR(USART_RXC_vect)
{
unsigned char nextChar;

// Daten aus dem Puffer lesen
nextChar = UDR;
if( uart_str_complete == 0 ) { // wenn uart_string gerade in Verwendung, neues Zeichen verwerfen

// Daten werden erst in uart_string geschrieben, wenn nicht String-Ende/max Zeichenlänge erreicht ist/string gerade verarbeitet wird
if( nextChar != '\n' &&
nextChar != '\r' &&
uart_str_count < UART_MAXSTRLEN ) {
uart_string[uart_str_count] = nextChar;
uart_str_count++;
}
else {
uart_string[uart_str_count] = '\0';
uart_str_count = 0;
uart_str_complete = 1;
}
}
}
</syntaxhighlight>

Zur Funktion: Wurde eine komplette Zeichenkette empfangen, also das Ende (\n oder \r) erkannt oder die maximale Länge ''UART_MAXSTRLEN'' erreicht, wird die globale Variable ''uart_str_complete'' auf '1' gesetzt. Damit wird dem Hauptprogramm, welches auf diese Variable pollt, mitgeteilt, dass die Zeichenkette ''uart_string'' zur Verarbeitung bereit steht. Nach der Verarbeitung der Zeichenkette in der entsprechenden main-Routine, muss die Variable ''uart_str_complete'' wieder auf '0' zurück gesetzt werden. Dadurch werden alle neu empfangenen Zeichen wieder in den globalen Puffer geschrieben.

=== (Baustelle) ===

* Empfangen (Receive) (Anm.: z.T. erledigt)
** ggf. Fallstricke ([http://www.mikrocontroller.net/topic/84256#707214 UDR in der ISR lesen!])
** Komplettes, einfaches Beispiel ([http://www.mikrocontroller.net/topic/84228#707052 Echo] (noch buggy beim Datenzugriff, siehe Lit. 2+3!)), ggf. LED zur ISR-Empfangsanzeige oder Overflow-Anzeige

* Senden (Transmit)
** Variante "UART Data Register Empty" (UDRE) [http://www.mikrocontroller.net/topic/101472#882716]
** Variante "UART Transmit Complete" (TXC)

* FIFO-Puffer [http://www.mikrocontroller.net/topic/101472#882716], Ringpuffer (Byte Buffering (circular))

* UART-Bibliotheken
** [http://www.peterfleury.epizy.com/avr-software.html UART-Library] von Peter Fleury (UART (interrupt driven), Byte Buffering (circular))
** [http://beaststwo.org/avr-uart/index.shtml Updated AVR UART Library] (modernisierte und erweiterte Version der Bibliothek von Peter Fleury)
** [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] von Pascal Stang (UART (interrupt driven), Byte Buffering (circular), VT100 Terminal Output)
** [http://die-seite.ch/public/uart_driver.c uart_driver.c] Beispieltreiber in C mit minimalstem Code fuer ATMega8. Sendet und empfaengt Strings ueber Interrupts (von Markus Zimmermann)
** [https://github.com/crapp/uartavr uartavr] BSD-3-Clause Library von Christian Rapp für ATmega328. Interrupt driven und Byte Buffering (circular), [https://crapp.github.io/uartavr/uart_8h.html API Dokumentation]

* Literatur
** [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)
** avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_16bitio Why do some 16-bit timer registers sometimes get trashed?]

==Software-UART==

Falls die Zahl der vorhandenen Hardware-UARTs nicht ausreicht, können weitere Schnittstellen über sogennante Software-UARTs ergänzt werden. Es gibt dazu (mindestens) zwei Ansätze:
* Der bei AVRs üblichste Ansatz basiert auf dem Prinzip, dass ein externer Interrupt-Pin für den Empfang ("RX") genutzt wird. Das Startbit löst den Interrupt aus, in der Interrupt-Routine (ISR) wird der externe Interrupt deaktiviert und ein Timer aktiviert. In der Interrupt-Routine des Timers wird der Zustand des Empfangs-Pins entsprechend der Baudrate abgetastet. Nach Empfang des Stop-Bits wird der externe Interrupt wieder aktiviert. Senden kann über einen beliebigen Pin ("TX") erfolgen, der entsprechend der Baudrate und dem zu sendenden Zeichen auf 0 oder 1 gesetzt wird. Die Implementierung ist nicht ganz einfach, es existieren dazu aber fertige Bibliotheken (z. B. bei [http://www.avrfreaks.net/ avrfreaks] oder in der [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon avrlib]).
* Ein weiterer Ansatz erfordert keinen Pin mit "Interrupt-Funktion" aber benötigt mehr Rechenzeit. Jeder Input-Pin kann als Empfangspin (RX) dienen. Über einen Timer wird der Zustand des RX-Pins mit einem vielfachen der Baudrate abgetastet (dreifach scheint üblich) und High- bzw. Lowbits anhand einer Mindestanzahl identifiziert. (Beispiel: "Generic Software Uart" Application-Note von IAR)

Neuere AVRs (z. B. ATtiny26 oder ATmega48,88,168,169) verfügen über ein Universal Serial Interface (USI), das teilweise UART-Funktion übernehmen kann. Atmel stellt eine Application-Note bereit, in der die Nutzung des USI als UART erläutert wird (im Prinzip "Hardware-unterstützter Software-UART").

==Handshaking==
Wenn der Sender ständig sendet, wird irgendwann der Fall eintreten, daß der Empfänger nicht bereit ist, neue Zeichen zu empfangen. In diesem Fall muß durch ein '''Handshake-Verfahren''' die Situation bereinigt werden. Handshake bedeutet nichts anderes, als daß der Empfänger dem Sender mitteilt, daß er zur Zeit keine Daten annehmen kann und der Sender die Übertragung der nächsten Zeichen solange einstellen soll, bis der Empfänger signalisiert, daß er wieder Zeichen aufnehmen kann.
===Hardwarehandshake (RTS/CTS)===
Beim Hardwarehandshake werden zusätzlich zu den beiden Daten-Übertragungsleitungen noch 2 weitere Leitungen benötigt: '''RTS''' ('''R'''equest '''T'''o '''S'''end) und '''CTS''' ('''C'''lear '''T'''o '''S'''end). Jeder der beiden Kommunikationspartner ist verpflichtet, bevor ein Zeichen gesendet wird, den Zustand der '''RTS''' Leitung zu überprüfen. Nur wenn die Gegenstelle darauf Empfangsbereitschaft signalisiert, darf das Zeichen gesendet werden. Um der Gegenstelle zu signalisieren, daß sie zur Zeit keine Zeichen schicken soll, wird die Leitung '''CTS''' benutzt.

===Softwarehandshake (XON/XOFF)===
Beim Softwarehandshake sind keine speziellen Leitungen notwendig. Stattdessen werden besondere ASCII-Zeichen benutzt, die der Gegenstelle signalisieren, das Senden einzustellen bzw. wieder aufzunehmen.

* '''XOFF''' Aufforderung das Senden einzustellen
* '''XON''' Gegenstelle darf wieder senden

Nachteilig bei einem Softwarehandshake ist, dass dadurch keine direkte binäre Datenübertragung mehr möglich ist, denn von den möglichen 256 Bytewerten werden ja nun zwei (nämlich für '''XON''' und für '''XOFF''') für besondere Zwecke benutzt und fallen daher aus. In einem quasi-zufälligen Bytestrom, den eine Binärdatei darstellt, kämen diese beiden reservierten früher oder später vor und würden dann den Strom ungewollt stoppen und starten.

==Galvanische Trennung==
Für eine hohe Überspannungsfestigkeit empfielt es sich, die Datenkanäle über Optokoppler zu führen. Es bietet sich z.b. der 6N138 an, ein "normaler" CNY-17 ist für hohe Baudraten nicht brauchbar.

==Fehlersuche==
Erstaunlich oft wird im Forum der Hilferuf laut: "Meine UART funktioniert nicht, was mache ich falsch". In der überwiegenden Mehrzahl der Fälle stellt sich dann heraus, daß es sich um ein Hardwareproblem handelt, wobei da wiederrum der Löwenanteil auf das Konto einer nicht korrekt eingestellten Taktrate geht: Der µC benutzt nicht einen angeschlossenen Quarz, so wie er auch im Programm eingetragen ist, sondern läuft immer noch mit dem internen RC-Takt. Daraus resultiert aber auch, daß der Baudraten Konfigurationswert falsch berechnet wird.

Hilfreich zum Aufspüren solcher Fehler ist auch die [[AVR_Checkliste#UART/USART|AVR-Checkliste]].

==Links==
Tipps zur Verarbeitung von Strings sind in den [[FAQ]].

[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:UART und RS232]]

AVR-GCC-Tutorial/Der UART

2019-10-30T21:21:55Z

Pfleury: /* (Baustelle) */

Über den [[UART]] kann ein [[AVR]] leicht mit einer [[RS-232]]-Schnittstelle eines PC oder sonstiger Geräte mit "[[seriell]]er Schnittstelle" verbunden werden.

== Allgemeines zum UART ==

Mögliche Anwendungen des UART:

;Debug-Schnittstelle: z. B. zur Anzeige von Zwischenergebnissen ("printf-debugging" - hier besser "Logging" oder "UART-debugging") über [[RS-232]] auf einem PC. Auf dem Rechner reicht dazu ein [[RS-232#Terminalprogramme|Terminalprogramm]] (MS-Windows: Hyperterm oder besser [https://sites.google.com/site/terminalbpp/], [http://www.der-hammer.info/terminal/ HTerm]; Unix/Linux z. B. minicom). Ein direkter Anschluss ist aufgrund unterschiedlicher Pegel nicht möglich, jedoch sind entsprechende Schnittstellen-ICs wie z. B. ein MAX232 günstig und leicht zu integrieren. Rechner ohne serielle Schnittstelle können über fertige USB-seriell-Adapter angeschlossen werden.
;Mensch-Maschine Schnittstelle: z. B. Konfiguration und Statusabfrage über eine "Kommandozeile" oder Menüs (siehe z. B. Forumsbeitrag [http://www.mikrocontroller.net/topic/52985 Auswertung RS232-Befehle] und Artikel [[Tinykon]])
;Übertragen von gespeicherten Werten: z. B. bei einem Datenlogger
;Anschluss von Geräten: mit serieller Schnittstelle (z. B. (Funk-)Modems, Mobiltelefone, Drucker, Sensoren, "intelligente" LC-Displays, GPS-Empfänger).
;"Feldbusse": auf RS485/RS422-Basis mittels entsprechenden Bustreiberbausteinen (z. B. MAX485)
;DMX, Midi: etc.
;LIN-Bus: '''L'''ocal '''I'''nterconnect '''N'''etwork: Preiswerte Sensoren/Aktoren in der Automobiltechnik und darüber hinaus

Einige AVR-Controller haben ein bis zwei vollduplexfähige UART ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter) schon eingebaut ("Hardware-UART").
Übrigens: Vollduplex heißt nichts anderes, als dass der Baustein gleichzeitig senden und empfangen kann.

Neuere AVRs (ATmega, ATtiny) verfügen über einen bis vier U'''S'''ART(s), dieser unterscheidet sich vom UART hauptsächlich durch interne FIFO-Puffer für Ein- und Ausgabe und erweiterte Konfigurationsmöglichkeiten. Die Puffergröße ist allerdings nur 1 Byte.

== Die Hardware ==

Der UART basiert auf normalem TTL-Pegel mit 0V (logisch 0) und 5V (logisch 1). Die Schnittstellenspezifikation für RS-232 definiert jedoch -12V ... -3V (logisch 1) und
+3 ... +12V (logisch 0). Daher muss der Signalaustausch zwischen AVR und Partnergerät invertiert werden. Für die Anpassung der Pegel und das Invertieren der Signale gibt es fertige Schnittstellenbausteine. Der bekannteste davon ist wohl der MAX232.


Streikt die Kommunikation per UART, so ist oft eine fehlerhafte Einstellung der Baudrate die Ursache. Die Konfiguration auf eine bestimmte Baudrate ist abhängig von der Taktfrequenz des Controllers. Gerade bei neu aufgebauten Schaltungen (bzw. neu gekauften Controllern) sollte man sich daher noch einmal vergewissern, dass der Controller auch tatsächlich mit der vermuteten Taktrate arbeitet und nicht z. B. den bei einigen Modellen werksseitig eingestellten internen [[Oszillator]] statt eines externen Quarzes nutzt. Die Werte der verschiedenen fuse-bits im Fehlerfall also beispielsweise mit ''[[AVRDUDE]]'' kontrollieren und falls nötig anpassen. Grundsätzlich empfiehlt sich auch immer ein Blick in die [[AVR_Checkliste]].

Controller mit nur einem Quarzanschluss (z.B Atmega328), die den Timer2 im Asynchron Modus benutzen, müssen intern mit dem RC-Oszillator getaktet werden. Dieser sollte dann kalibriert werden:
[[AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Kalibrieren_des_internen_Oszillators_mit_Timer2_als_Zeitbasis|Kalibrieren des internen Oszillators mit Timer2 als Zeitbasis]]

== Die UART-Register ==

Die UART wird über vier separate Register angesprochen. Die USARTs der ATMEGAs verfügen über mehrere zusätzliche Konfigurationsregister. Das Datenblatt gibt darüber Auskunft. Die folgende Tabelle gibt nur die Register für die UARTs der ATmega8/16/32 u.ä. wieder.

{| class="wikitable"
|-
| width="100" | '''UCSRA   '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''A'''. 
Hier teilt uns der UART mit, was er gerade so macht.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXC'''|| '''TXC'''|| '''UDRE'''|| '''FE'''|| '''DOR'''|| '''PE'''|| '''U2X'''|| '''MPCM'''
|-
! R/W
| R|| R/W|| R|| R|| R|| R|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 1|| 0|| 0|| 0|| 0|| 0
|}

'''RXC''' (UART Receive Complete)
:Dieses Bit wird vom AVR gesetzt, wenn ein empfangenes Zeichen vom Empfangs-Schieberegister in das Empfangs-Datenregister transferiert wurde.
:Das Zeichen muss nun schnellstmöglich aus dem Datenregister ausgelesen werden. Falls dies nicht erfolgt, bevor ein weiteres Zeichen komplett empfangen wurde, wird eine Überlauf-Fehlersituation eintreten. Mit dem Auslesen des Datenregisters wird das Bit automatisch gelöscht.

'''TXC''' (UART Transmit Complete)
:Dieses Bit wird vom AVR gesetzt, wenn das im Sende-Schieberegister befindliche Zeichen vollständig ausgegeben wurde und kein weiteres Zeichen im Sendedatenregister ansteht. Dies bedeutet also, dass die Kommunikation vollumfänglich abgeschlossen ist.
:Dieses Bit ist wichtig bei Halbduplex-Verbindungen, wenn das Programm nach dem Senden von Daten auf Empfang schalten muss. Im Vollduplexbetrieb brauchen wir dieses Bit nicht zu beachten.
:Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber löschen.
:Um das Bit zu löschen muss eine 1 an die entsprechende Position geschrieben werden!

'''UDRE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty)
:Dieses Bit zeigt an, ob der Sendepuffer bereit ist, um ein zu sendendes Zeichen aufzunehmen. Das Bit wird vom AVR gesetzt (1), wenn der Sendepuffer leer ist. Es wird gelöscht (0), wenn ein Zeichen im Sendedatenregister vorhanden ist und noch nicht in das Sende-Schieberegister übernommen wurde. Atmel empfiehlt aus Kompatibilitätsgründen mit kommenden µC, UDRE auf 0 zu setzen, wenn das UCSRA Register beschrieben wird.
:Das Bit wird automatisch gelöscht, wenn ein Zeichen in das Sendedatenregister geschrieben wird.

'''FE''' ('''F'''raming '''E'''rror)
:Dieses Bit wird vom AVR gesetzt, wenn der UART einen Zeichenrahmenfehler detektiert, d.h. wenn das Stopbit eines empfangenen Zeichens 0 ist.
:Das Bit wird automatisch gelöscht, wenn das Stopbit des empfangenen Zeichens 1 ist.

'''DOR''' ('''D'''ata '''O'''ver '''R'''un)
:Dieses Bit wird vom AVR gesetzt, wenn unser Programm das im Empfangsdatenregister bereit liegende Zeichen nicht abholt bevor das nachfolgende Zeichen komplett empfangen wurde.
:Das nachfolgende Zeichen wird verworfen.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''PE''' ('''P'''arity '''E'''rror''')
:Dieses Bit wird vom AVR gesetzt, wenn das im Empfangsdatenregister bereit liegende Zeichen einen Paritätsfehler aufweist.
:Das Bit wird automatisch gelöscht, wenn das empfangene Zeichen in das Empfangsdatenregister transferiert werden konnte.

'''U2X''' (Double the transmission speed)
:Dieses Bit wird lediglich im asynchronen Modus genutzt. Im synchronen Modus ist es 0 zu setzen. Wird das Bit gesetzt, so wird der Baudraten Divisor von 16 auf 8 reduziert, was einer Verdopplung der Transferrate gleich kommt.

'''MPCM''' ('''M'''ulti '''P'''rozessor '''C'''ommunication '''M'''ode)
:Dieses Bit aktiviert die Multi-Prozessor-Kommunikation. Jeder eintreffende Frame der keine Adressinformation enthält wird dadurch ignoriert.

|-
| '''UCSRB    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''B'''. 
In diesem Register stellen wir ein, wie wir den UART verwenden möchten. 
Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''RXCIE'''|| '''TXCIE'''|| '''UDRIE'''|| '''RXEN'''|| '''TXEN'''|| '''UCSZ2'''|| '''RXB8'''|| '''TXB8'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''RXCIE''' ('''RX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART RX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART empfangen wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''TXCIE''' ('''TX''' '''C'''omplete '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART TX Complete Interrupt ausgelöst, wenn ein Zeichen vom UART gesendet wurde. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''UDRIE''' ('''U'''ART '''D'''ata '''R'''egister '''E'''mpty '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein UART Datenregister Leer Interrupt ausgelöst, wenn der UART wieder bereit ist um ein neues zu sendendes Zeichen zu übernehmen. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''RXEN''' ('''R'''eceiver '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Empfänger des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''TXEN''' ('''T'''ransmitter '''E'''nable)
:Nur wenn dieses Bit gesetzt ist, arbeitet der Sender des UART überhaupt. Wenn das Bit nicht gesetzt ist, kann der entsprechende Pin des AVR als normaler I/O-Pin verwendet werden.

'''UCSZ2''' (Characters Size)
:Dieses Bit setzt in Verbindung mit dem UCSZ1:0 Bits im UCSRC Register die Anzahl von Datenbits eines Frames beim Empfang oder Senden.

'''RXB8''' (Receive Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann enthält dieses Bit das 9. Datenbit eines empfangenen Zeichens.

'''TXB8''' (Transmit Data Bit 8)
:Wenn das vorher erwähnte CHR9-Bit gesetzt ist, dann muss in dieses Bit das 9. Bit des zu sendenden Zeichens eingeschrieben werden bevor das eigentliche Datenbyte in das Datenregister geschrieben wird.
|-
| '''UCSRC    '''
| '''U'''ART '''C'''ontrol and '''S'''tatus '''R'''egister '''C'''. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''URSEL'''|| '''UMSEL'''|| '''UPM1'''|| '''UPM0'''|| '''USBS'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''UCPOL'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 1|| 0|| 0|| 0|| 0|| 1|| 1|| 0
|}

'''URSEL''' (Register Select)
:Dieses Bit selektiert die Auswahl des UCSRC- bzw. des UBRRH Registers. Beim Lesen von UCSRC wird es als 1 gelesen. Beim Schreiben auf UCSRC muss es auf 1 gesetzt werden.

:Achtung: Manche Prozessoren verfügen über dieses Bit, andere wiederrum nicht. Was hat es damit auf sich? Um Zugriffsadressen einzusparen, wurde von Atmel ein etwas seltsamer Weg gewählt. Das UCSRC Register und das High-Byte des Baudratenregisters teilen sich dieselbe Registeradresse! Um der Hardware mitzuteilen, welche Bedeutung ein zugewiesener Wert haben soll, entweder neue Belegung des Baudratenregisters oder eben Konfiguration des UCSRC Registers, dient dieses Bit. Ist es nicht gesetzt, dann wird eine Zuweisung immer als Zuweisung an das High-Byte des Baudratenregisters angesehen, selbst wenn das so nicht beabsichtigt war. Nur dann wenn dieses Bit gesetzt ist, dann wird eine Zuweisung auch tatsächlich als eine Zuweisung an das UCSRC Register gewertet und die Konfiguration verändert. Lässt man das Bit irrtümlich weg, dann verursacht eine Zuweisung an UCSRC eine Veränderung der Baudrateneinstellung!

'''UMSEL''' (USART Mode Select)
:Durch dieses Bit kann eine asynchrone oder synchrone Übertragung eingestellt werden. Durch Setzen des Bits wird eine synchrone Übertragung eingestellt.

'''UPM1:0''' (Parity Mode)
{| class="wikitable" style="text-align:center"
|-
| '''UPM1'''|| '''UPM0'''|| '''Parity Mode'''
|-
| 0|| 0|| Disabled
|-
| 0|| 1|| Reserved
|-
| 1|| 0|| Enabled, Even Priority
|-
| 1|| 1|| Enabled, OddPriority
|}

'''USBS''' ('''U'''SART '''S'''top '''B'''it '''S'''elect)
:Diese Bits setzen die Anzahl der zu sendenden Stopbits eines Frames. Beim Setzen werden 2 Stopbits übertragen, andernfalls nur 1 Stopbit.
{| class="wikitable" style="text-align:center"
|-
| '''USBS'''|| '''Anzahl der Stop Bits'''
|-
| 0|| 1
|-
| 1|| 2

|}

'''UCSZ1:0''' (Character Size)
:Diese Bits setzen in Verbindung mit UCSZ2 aus dem UCSRB Register die Anzahl der Datenbits eines Frames.
:Diese Bits setzen den entsprechenden Paritätsmodus.
{| class="wikitable" style="text-align:center"
|-
| '''UCSZ2'''|| '''UCSZ1'''|| '''UCSZ0'''|| '''Character Size'''
|-
| 0|| 0|| 0|| 5-Bit
|-
| 0|| 0|| 1|| 6-Bit
|-
| 0|| 1|| 0|| 7-Bit
|-
| 0|| 1|| 1|| 8-Bit
|-
| 1|| 0|| 0|| Reserved
|-
| 1|| 0|| 1|| Reserved
|-
| 1|| 1|| 0|| Reserved
|-
| 1|| 1|| 1|| 9-Bit
|}

'''UCPOL''' (Clock Polarity)

|-
| '''UDR'''
| '''U'''ART '''D'''ata '''R'''egister. 
Hier werden Daten zwischen UART und CPU übertragen. Da der UART im
Vollduplexbetrieb gleichzeitig empfangen und senden kann, handelt es sich
hier physikalisch um 2 Register, die aber über die gleiche I/O-Adresse
angesprochen werden. Je nachdem, ob ein Lese- oder ein Schreibzugriff auf
den UART erfolgt wird automatisch das richtige UDR angesprochen.
|-
| '''UBRR'''
| '''U'''ART '''B'''aud '''R'''ate '''R'''egister. 
In diesem Register müssen wir dem UART mitteilen, wie schnell wir gerne kommunizieren möchten. Der Wert, der in dieses Register geschrieben werden muss, errechnet sich nach folgender Formel (wenn U2X Bit 0 gesetzt ist):

:<math>
\mathrm{UBRR} = \frac{\mathrm{Taktfrequenz}}{\mathrm{Baudrate} \cdot 16} - 1
</math>

Es sind Baudraten bis über 115200 Baud möglich, je nach Controller und CPU-Frequenz. Siehe Datenblatt.
|}

== UART initialisieren ==

Wir wollen nun Daten mit dem UART auf die serielle Schnittstelle ausgeben. Dazu müssen wir den UART zuerst mal initialisieren. Dazu setzen wir je nach gewünschter Funktionsweise die benötigten Bits im '''U'''ART '''C'''ontrol '''R'''egister.

Da wir vorerst nur senden möchten und noch keine Interrupts auswerten wollen, gestaltet sich die Initialisierung wirklich sehr einfach, da wir lediglich das '''Transmitter Enable''' Bit setzen müssen:

<syntaxhighlight lang="c">
UCSRB |= (1<<TXEN);
</syntaxhighlight>

Neuere AVRs mit USART haben mehrere Konfigurationsregister und erfordern eine etwas andere Konfiguration. Für einen ATmega16 z. B.:

<syntaxhighlight lang="c">
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC = (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
</syntaxhighlight>

Nun ist noch das Baudratenregister '''UBRR''' der verwendeten UARTs einzustellen, bzw. bei neueren AVRs die beiden Register '''UBRRL''' und '''UBRRH'''. . Die Berechnung wird während des Compilerlaufs ausgeführt, beansprucht also in der gezeigten Form weder Speicher noch Rechenzeit des Controllers. Das Ergebniss wird jedoch als ganzzahliger Wert eingesetzt, d.h. Nachkommastellen werden einfach abgeschnitten und es erfolgt keine Rundung. Aus diesem Grund kann man sich eines kleinen Tricks bedienen, indem vor der eigentlichen Division bei der Zuweisung die Hälfte des Wertes dazu addiert wird. Allgemein formuliert bedeutet das: <code>int i = ( a + b/2 ) / b;</code>. Dies wird in der unten angegebenen Berechnung von UBRR_VAL ausgenutzt um den Fehler zu minimieren. (Eine ausführliche Erklärung zum ''cleveren Runden'' findet sich in einer [http://www.mikrocontroller.net/topic/170617#1631916 Forumsdiskussion].)

<syntaxhighlight lang="c">
/*
UART-Init:
Berechnung des Wertes für das Baudratenregister
aus Taktrate und gewünschter Baudrate
*/

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
F_CPU im Makefile definiert werden, eine nochmalige Definition
hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
#ifndef/#endif

Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio
verwendet wird und dort eine andere, nicht zur Hardware passende
Taktrate eingestellt ist: Dann wird die folgende Definition
nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?)
von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned long beachten
// Ohne ergeben sich unten Fehler in der Berechnung
#endif

#define BAUD 9600UL // Baudrate

// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif
</syntaxhighlight>

Die Makros sind sehr praktisch, da damit sowohl automatisch der Wert für UBRR, als auch die Abweichung in der generierten (möglichen) von der gewünschten Baudrate berechnet wird. Im Falle einer zu hohen Abweichung (+/-1%) wird eine Fehlermeldung ausgegeben und der Compilerablauf abgebrochen. Damit können viele Probleme mit "UART sendet komische Zeichen" vermieden werden. Ausserdem kann man mühelos die Einstellung an eine neue Taktfrequenz bzw. Baudrate anpassen, ohne selber rechnen oder in Tabellen nachschlagen zu müssen.

Die eigentliche Initialisierung der UART Register kann im Hauptprogramm main() vorgenommen werden. Öfters wird jedoch eine Funktion z. B. uart_init() dafür geschrieben, die in der eigenen Codesammlung in mehreren Projekten verwendet werden kann.

Für einige AVR (z. B. ATmega169, ATmega48/88/168, AT90CAN jedoch nicht für z. B. ATmega16/32, ATmega128, ATtiny2313) wird durch die Registerdefinitionen der avr-libc (io*.h) auch für Controller mit zwei UBRR-Registern (UBRRL/UBRRH) ein UBRR bzw. UBRR0 als "16-bit-Register" definiert und man kann den Wert direkt per UBRR = UBRR_VAL zuweisen. Intern werden dann zwei Zuweisungen für UBRRH und UBRRL generiert.

<syntaxhighlight lang="c">
/* UART-Init Bsp. ATmega48 */

void uart_init(void)
{
UBRR0 = UBRR_VAL;
UCSR0B |= (1<<TXEN0);
// Frame Format: Asynchron 8N1
UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
}
</syntaxhighlight>

Die einzelne Anweisung ist nicht bei allen Controllern möglich, da die beiden Register nicht bei allen aufeinanderfolgende Addressen aufweisen. Die getrennte Zuweisung an UBRRH und UBRRL wie im nächsten Beispiel gezeigt, ist universeller und portabler und daher vorzuziehen. Wichtig ist, dass UBRRH '''vor''' UBRRL geschrieben wird:

<syntaxhighlight lang="c">
/* UART-Init Bsp. ATmega16 */

void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;

UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
}
</syntaxhighlight>

Inzwischen gibt es in der avr-libc Makros für obige Berechnung der UBRR Registerwerte aus Taktrate F_CPU und Baudrate BAUD. Dazu wird die Includedatei [http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html <util/setbaud.h>] eingebunden, nachdem F_CPU und die gewünschte Baudrate definiert wurden. Einige Beispiele zur Anwendung finden sich in der Dokumentation der avr-libc. Im Quellcode kann dann analog zur oben gezeigten Vorgehensweise einfach das Makro UBRR_VALUE (bzw. UBRRH_VALUE und UBRRL_VALUE) an der entsprechenden Stelle eingesetzt werden. Es wird auch automatisch ermittelt, ob der U2X-Modus (vgl. Datenblatt) zu geringeren Abweichungen führt und dann dem Makro USE_U2X ein Wert ungleich null zugewiesen. Ein Beispiel (angelehnt an die avr-libc-Dokumentation):

<syntaxhighlight lang="c">
#include <avr/io.h>
#define F_CPU 1000000 /* evtl. bereits via Compilerparameter definiert */
#define BAUD 9600
#include <util/setbaud.h>

void uart_init(void)
{
UBRRH = UBRRH_VALUE;
UBRRL = UBRRL_VALUE;
/* evtl. verkuerzt falls Register aufeinanderfolgen (vgl. Datenblatt)
UBRR = UBRR_VALUE;
*/
#if USE_2X
/* U2X-Modus erforderlich */
UCSRA |= (1 << U2X);
#else
/* U2X-Modus nicht erforderlich */
UCSRA &= ~(1 << U2X);
#endif

// hier weitere Initialisierungen (TX und/oder RX aktivieren, Modus setzen
}
</syntaxhighlight>

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html Dokumentation der avr-libc zu <util/setbaud.h>]
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.
* [http://www.gjlay.de/helferlein/avr-uart-rechner.html AVR Baudraten-Rechner] in JavaScript

== Senden mit dem UART ==

=== Senden einzelner Zeichen ===

Um nun ein Zeichen auf die Schnittstelle auszugeben, müssen wir dasselbe
lediglich in das '''U'''ART '''D'''ata '''R'''egister schreiben. Vorher ist zu prüfen, ob das UART-Modul bereit ist, das zu sendende Zeichen entgegenzunehmen. Die Bezeichnungen des/der Statusregisters mit dem Bit UDRE ist abhängig vom Controllertypen (vgl. Datenblatt).

<syntaxhighlight lang="c">
// bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */

// das entpricht dem "C Code Example USART_Transmit" in der ATMEL-Doku ...
// besser ist es aber, die CPU nicht in einer Warteschleife zu blockieren:

if(UCSRA & (1<<UDRE)) /* Senden, wenn UDR frei ist */
{ UDR = 'x'; /* schreibt das Zeichen x auf die Schnittstelle */
}
</syntaxhighlight>
Zum "Blockieren" vgl. [[AVR-GCC-Tutorial#Warten_auf_einen_bestimmten_Zustand|AVR-GCC-Tutorial]]

=== Senden einer Zeichenkette (String) ===

Die Aufgabe "String senden" wird durch zwei Funktionen abgearbeitet. Die universelle/controllerunabhängige Funktion uart_puts übergibt jeweils ein Zeichen der Zeichenkette an eine Funktion uart_putc, die abhängig von der vorhandenen Hardware implementiert werden muss. In der Funktion zum Senden eines Zeichens ist darauf zu achten, dass vor dem Senden geprüft wird, ob der UART bereit ist den "Sendeauftrag" entgegenzunehmen.

<syntaxhighlight lang="c">
/* ATmega16 */
int uart_putc(unsigned char c)
{
while (!(UCSRA & (1<<UDRE))) /* warten bis Senden moeglich */
{
}

UDR = c; /* sende Zeichen */
return 0;
}

/* puts ist unabhaengig vom Controllertyp */
void uart_puts (char *s)
{
while (*s)
{ /* so lange *s != '\0' also ungleich dem "String-Endezeichen(Terminator)" */
uart_putc(*s);
s++;
}
}
</syntaxhighlight>

Die in uart_putc verwendeten Schleifen, in denen gewartet wird bis die UART-Hardware zum senden bereit ist, sind insofern etwas kritisch, da während des Sendens eines Strings nicht mehr auf andere Ereignisse reagiert werden kann. Universeller ist die Nutzung von FIFO(first-in first-out)-Puffern, in denen die zu sendenden bzw. empfangenen Zeichen/Bytes zwischengespeichert und in Interruptroutinen an die U(S)ART-Hardware weitergegeben bzw. von ihr ausgelesen werden. Dazu existieren fertige Komponenten (Bibliotheken, Libraries), die man recht einfach in eigene Entwicklungen integrieren kann. Es empfiehlt sich, diese Komponenten zu nutzen und das Rad nicht neu zu erfinden.

=== Senden von Variableninhalten ===

Sollen Inhalte von Variablen (Ganzzahlen, Gleitkomma) in "menschenlesbarer" Form gesendet werden, ist vor dem Transfer eine Umwandlung in Zeichen ("ASCII") erforderlich. Bei nur einer Ziffer ist diese Umwandlung relativ einfach: man addiert den ASCII-Wert von Null zur Ziffer und kann diesen Wert direkt senden.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>
//...

// hier uart_putc (s.o.)

int main (void)
{
// Ausgabe von 0123456789
char c;

uart_init();

for (uint8_t i=0; i<=9; ++i) {
c = i + '0';
uart_putc( c );
// verkuerzt: uart_putc( i + '0' );
}

while (1) {

}

return 0; // never reached

}
</syntaxhighlight>

Soll mehr als eine Ziffer ausgegeben werden, bedient man sich zweckmäßigerweise vorhandener Funktionen zur Umwandlung von Zahlen in Zeichenketten/Strings. Die Funktion der avr-libc zur Umwandlung von vorzeichenbehafteten 16bit-Ganzzahlen (int16_t) in Zeichenketten heißt ''itoa'' (Integer to ASCII). Man muss der Funktion einen Speicherbereich zur Verarbeitung (buffer) mit Platz für alle Ziffern, das String-Endezeichen ('\0') und evtl. das Vorzeichen bereitstellen.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

int main(void)
{
char s[7];
int16_t i = -12345;

uart_init();

itoa( i, s, 10 ); // 10 fuer radix -> Dezimalsystem
uart_puts( s );

// da itoa einen Zeiger auf den Beginn von s zurueckgibt verkuerzt auch:
uart_puts( itoa( i, s, 10 ) );

while (1) {
;
}

return 0; // never reached
}
</syntaxhighlight>

Für vorzeichenlose 16bit-Ganzzahlen (uint16_t) exisitert ''utoa''. Die Funktionen für 32bit-Ganzzahlen (int32_t und uint32_t) heißen ''ltoa'' bzw. ''ultoa''. Da 32bit-Ganzzahlen mehr Stellen aufweisen können, ist ein entsprechend größerer Pufferspeicher vorzusehen.

Auch Gleitkommazahlen (float/double) können mit bereits vorhandenen Funktionen in Zeichenfolgen umgewandelt werden, dazu existieren die Funktionen ''dtostre'' und ''dtostrf''. dtostre nutzt Exponentialschreibweise ("engineering"-Format). (Hinweis: z.Zt. existiert im avr-gcc kein "echtes" double, intern wird immer mit "einfacher Genauigkeit", entsprechend float, gerechnet.)

dtostrf und dtostre benötigen die libm.a der avr-libc. Bei Nutzung von Makefiles ist der Parameter -lm in in LDFLAGS anzugeben (Standard in den WinAVR/mfile-Makefilevorlagen). Nutzt man AVRStudio als IDE für den GNU-Compiler (gcc-Plugin) ist die libm.a unter Libaries auszuwählen: Project -> Configurations Options -> Libaries -> libm.a mit dem Pfeil nach rechts einbinden. Siehe auch die [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|FAQ]]

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

//...

// hier uart_init, uart_putc, uart_puts (s.o.)

/* lt. avr-libc Dokumentation:
char* dtostrf(
double __val,
char __width,
char __prec,
char * __s
)
*/

int main(void)
{
// Pufferspeicher ausreichend groß
// evtl. Vorzeichen + width + Endezeichen:
char s[8];
float f = -12.345;

uart_init();

dtostrf( f, 6, 3, s );
uart_puts( s );
// verkürzt: uart_puts( dtostrf( f, 7, 3, s ) );

while (1) {
;
}

return 0; // never reached
}
</syntaxhighlight>

== Empfangen ==
=== Einzelne Zeichen empfangen ===

Zum Empfang von Zeichen muss der Empfangsteil des UART bei der Initialisierung aktiviert werden, indem das RXEN-Bit im jeweiligen Konfigurationsregister (UCSRB bzw UCSR0B/UCSR1B) gesetzt wird. Im einfachsten Fall wird solange gewartet, bis ein Zeichen empfangen wurde, dieses steht dann im UART-Datenregister (UDR bzw. UDR0 und UDR1 bei AVRs mit 2 UARTS) zur Verfügung (sogen. "Polling-Betrieb"). Ein Beispiel für den ATmega16:

<syntaxhighlight lang="c">
#include <inttypes.h>
#include <avr/io.h>

/* Siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */

void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;

UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
UCSRB |= (1<<RXEN); // UART RX einschalten
}

/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}
</syntaxhighlight>

Und die Anwendung in einem Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

// hier Makro für die Baudratenberechnung

// hier uart_init, uart_getc (s.o.)

int main(void)
{
uart_init();
while (1)
{
uint8_t c;
c = uart_getc();

// hier etwas mit c machen z.B. auf PORT ausgeben
DDRC = 0xFF; // PORTC Ausgang
PORTC = c;
}
return 0; // never reached
}
</syntaxhighlight>

Die Funktion uart_getc() blockiert allerdings den Programmablauf, denn es wird gewartet, bis ein Zeichen empfangen wird! Möchte man das Warten vermeiden, kann das RXC-Bit in einer Programmschleife abgefragt werden und dann nur bei gesetztem RXC-Bit UDR ausgelesen werden.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdlib.h>

// hier Makro für die Baudratenberechnung

// hier uart_init, uart_getc (s.o.)

int main(void)
{
uart_init();
while (1)
{
if ( (UCSRA & (1<<RXC)) )
{
// Zeichen wurde empfangen, jetzt abholen
uint8_t c;
c = uart_getc();
// hier etwas mit c machen z.B. auf PORT ausgeben
DDRC = 0xFF; // PORTC Ausgang
PORTC = c;
}
else
{
// Kein Zeichen empfangen, Restprogramm ausführen...
}
}
return 0; // never reached
}
</syntaxhighlight>

Eleganter und in den meisten Anwendungsfällen "stabiler" ist die Vorgehensweise, die empfangenen Zeichen in einer Interrupt-Routine einzulesen und zur späteren Verarbeitung in einem Eingangsbuffer (FIFO-Buffer) zwischenzuspeichern. Dazu existieren fertige und gut getestete [[Libraries|Bibliotheken]]  und Quellcodekomponenten (z. B. UART-Library von P. Fleury, procyon-avrlib und einige in der "Academy" von avrfreaks.net).

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html Dokumenation der avr-libc/stdlib.h]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_sprintf_und_printf Die Nutzung von sprintf und printf]
* [http://homepage.hispeed.ch/peterfleury/ Peter Fleurys] UART-Bibiliothek fuer avr-gcc/avr-libc


TODO: 9bit

=== Empfang von Zeichenketten (Strings) ===

Beim Empfang von Zeichenketten, muß man sich zunächst darüber im klaren sein, daß es ein Kriterium geben muß, an dem der µC erkennen kann, wann ein Text zu Ende ist. Sehr oft wird dazu das Zeichen 'Return' benutzt, um das Ende eines Textes zu markieren. Dies ist vom Benutzer einfach eingebbar und er ist auch daran gewöhnt, daß er eine Eingabezeile mit einem Druck auf die Return Taste abgeschlossen wird.

Prinzipiell gibt es jedoch keine Einschränkung bezüglich dieses speziellen Zeichens. Es muß nur sichergestellt werden, daß dieses spezielle 'Ende eines Strings' - Zeichen nicht mit einem im Text vorkommenden Zeichen verwechselt werden kann. Wenn also im zu übertragenden Text beispielsweise kein ';' vorkommt, dann spricht nichts dagegen, den Benutzer die Eingabe eines Textes mit einem ';' abschließen zu lassen.

Im Folgenden wird die durchaus übliche Annahme getroffen, daß eine Stringübertragung identisch ist mit der Übertragung einer Textzeile und daher mit einem Return ('\n') abgeschlossen wird.

Das Problem der Übertragung eines Strings reduziert sich damit auf die Aufgabenstellung: Empfange und sammle Zeichen in einem char Array, bis entweder das Array voll ist oder das Text Ende Zeichen' empfangen wurde. Danach wird der empfangene Text noch mit einem '\0' Zeichen abgeschlossen um einen Standard C-String daraus zu machen, mit dem dann weiter gearbeitet werden kann.

<syntaxhighlight lang="c">
/* Zeichen empfangen */
uint8_t uart_getc(void)
{
while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar
;
return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben
}

void uart_gets( char* Buffer, uint8_t MaxLen )
{
uint8_t NextChar;
uint8_t StringLen = 0;

NextChar = uart_getc(); // Warte auf und empfange das nächste Zeichen

// Sammle solange Zeichen, bis:
// * entweder das String Ende Zeichen kam
// * oder das aufnehmende Array voll ist
while( NextChar != '\n' && StringLen < MaxLen - 1 ) {
*Buffer++ = NextChar;
StringLen++;
NextChar = uart_getc();
}

// Noch ein '\0' anhängen um einen Standard
// C-String daraus zu machen
*Buffer = '\0';
}
</syntaxhighlight>

Beim Aufruf ist darauf zu achten, dass das empfangende Array auch mit einer
vernünftigen Größe definiert wird.

<syntaxhighlight lang="c">

char Line[40]; // String mit maximal 39 zeichen

uart_gets( Line, sizeof( Line ) );
</syntaxhighlight>

Bei der Benutzung von sizeof() ist allerdings zu beachten, dass sizeof() nicht die Anzahl der Elemente des Arrays liefert, sondern die Länge in Byte. Da ein char nur ein Byte lang ist, passt der Aufruf 'uart_gets(Line, sizeof( Line ) );' in diesem Fall. Falls man - aus welchen Gründen auch immer - andere Datentypen benutzen möchte, sollte man zur korrekten Angabe der Array-Länge folgende Vorgehensweise bevorzugen:

<syntaxhighlight lang="c">
int Line[40]; // Array vom Typ int

uart_gets( Line, sizeof( Line ) / sizeof( Line[0] ) );
</syntaxhighlight>

==Interruptbetrieb==

Hier wird das Grundwissen des Artikels [[Interrupt]] und des Abschnitts [[AVR-GCC-Tutorial#Programmieren_mit_Interrupts|AVR-GCC-Tutorial: Programmieren_mit_Interrupts]] vorausgesetzt.

=== Empfangen (RX) ===

Beim ATmega8 muss das '''RXCIE''' Bit im Register UCSRB gesetzt werden, damit ein Interrupt beim Empfang eines Zeichens ausgelöst werden kann.

<syntaxhighlight lang="c">
/* siehe auch obere Baudrateneinstellung */
/* USART-Init beim ATmega16 */
void uart_init(void)
{
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1
UCSRB |= (1<<RXEN)|(1<<TXEN)|(1<<RXCIE); // UART RX, TX und RX Interrupt einschalten
}
</syntaxhighlight>

Natürlich muss "Global Interrupt Enable" mittels des Befehls sei() aktiviert sein. Interrupt-spezifische Definitionen werden über die Includedatei eingebunden:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
</syntaxhighlight>

Der Interrupt wird immer ausgelöst, wenn ein Zeichen erfolgreich empfangen wurde. Zusätzlich braucht man die Interruptserviceroutine (ISR).

In diesem Beispiel enthält die ISR einen FIFO-Puffer (First in, First out). Dafür werden ein paar globale Variablen und Makros benötigt:

<syntaxhighlight lang="c">
#define UART_MAXSTRLEN 10

volatile uint8_t uart_str_complete = 0; // 1 .. String komplett empfangen
volatile uint8_t uart_str_count = 0;
volatile char uart_string[UART_MAXSTRLEN + 1] = "";
</syntaxhighlight>

<syntaxhighlight lang="c">
ISR(USART_RXC_vect)
{
unsigned char nextChar;

// Daten aus dem Puffer lesen
nextChar = UDR;
if( uart_str_complete == 0 ) { // wenn uart_string gerade in Verwendung, neues Zeichen verwerfen

// Daten werden erst in uart_string geschrieben, wenn nicht String-Ende/max Zeichenlänge erreicht ist/string gerade verarbeitet wird
if( nextChar != '\n' &&
nextChar != '\r' &&
uart_str_count < UART_MAXSTRLEN ) {
uart_string[uart_str_count] = nextChar;
uart_str_count++;
}
else {
uart_string[uart_str_count] = '\0';
uart_str_count = 0;
uart_str_complete = 1;
}
}
}
</syntaxhighlight>

Zur Funktion: Wurde eine komplette Zeichenkette empfangen, also das Ende (\n oder \r) erkannt oder die maximale Länge ''UART_MAXSTRLEN'' erreicht, wird die globale Variable ''uart_str_complete'' auf '1' gesetzt. Damit wird dem Hauptprogramm, welches auf diese Variable pollt, mitgeteilt, dass die Zeichenkette ''uart_string'' zur Verarbeitung bereit steht. Nach der Verarbeitung der Zeichenkette in der entsprechenden main-Routine, muss die Variable ''uart_str_complete'' wieder auf '0' zurück gesetzt werden. Dadurch werden alle neu empfangenen Zeichen wieder in den globalen Puffer geschrieben.

=== (Baustelle) ===

* Empfangen (Receive) (Anm.: z.T. erledigt)
** ggf. Fallstricke ([http://www.mikrocontroller.net/topic/84256#707214 UDR in der ISR lesen!])
** Komplettes, einfaches Beispiel ([http://www.mikrocontroller.net/topic/84228#707052 Echo] (noch buggy beim Datenzugriff, siehe Lit. 2+3!)), ggf. LED zur ISR-Empfangsanzeige oder Overflow-Anzeige

* Senden (Transmit)
** Variante "UART Data Register Empty" (UDRE) [http://www.mikrocontroller.net/topic/101472#882716]
** Variante "UART Transmit Complete" (TXC)

* FIFO-Puffer [http://www.mikrocontroller.net/topic/101472#882716], Ringpuffer (Byte Buffering (circular))

* UART-Bibliotheken
** [http://www.peterfleury.epizy.com/avr-software.html UART-Library] von Peter Fleury (UART (interrupt driven), Byte Buffering (circular))
** [http://beaststwo.org/avr-uart/index.shtml Updated AVR UART Library] (modernisierte und erweiterte Version der Bibliothek von Peter Fleury)
** [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] von Pascal Stang (UART (interrupt driven), Byte Buffering (circular), VT100 Terminal Output)
** [http://die-seite.ch/public/uart_driver.c uart_driver.c] Beispieltreiber in C mit minimalstem Code fuer ATMega8. Sendet und empfaengt Strings ueber Interrupts (von Markus Zimmermann)
** [https://github.com/crapp/uartavr uartavr] BSD-3-Clause Library von Christian Rapp für ATmega328. Interrupt driven und Byte Buffering (circular), [https://crapp.github.io/uartavr/uart_8h.html API Dokumentation]

* Literatur
** [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188 avrfreaks.net Tutorial] inkl. Diskussion (engl.)
** avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_16bitio Why do some 16-bit timer registers sometimes get trashed?]

==Software-UART==

Falls die Zahl der vorhandenen Hardware-UARTs nicht ausreicht, können weitere Schnittstellen über sogennante Software-UARTs ergänzt werden. Es gibt dazu (mindestens) zwei Ansätze:
* Der bei AVRs üblichste Ansatz basiert auf dem Prinzip, dass ein externer Interrupt-Pin für den Empfang ("RX") genutzt wird. Das Startbit löst den Interrupt aus, in der Interrupt-Routine (ISR) wird der externe Interrupt deaktiviert und ein Timer aktiviert. In der Interrupt-Routine des Timers wird der Zustand des Empfangs-Pins entsprechend der Baudrate abgetastet. Nach Empfang des Stop-Bits wird der externe Interrupt wieder aktiviert. Senden kann über einen beliebigen Pin ("TX") erfolgen, der entsprechend der Baudrate und dem zu sendenden Zeichen auf 0 oder 1 gesetzt wird. Die Implementierung ist nicht ganz einfach, es existieren dazu aber fertige Bibliotheken (z. B. bei [http://www.avrfreaks.net/ avrfreaks] oder in der [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon avrlib]).
* Ein weiterer Ansatz erfordert keinen Pin mit "Interrupt-Funktion" aber benötigt mehr Rechenzeit. Jeder Input-Pin kann als Empfangspin (RX) dienen. Über einen Timer wird der Zustand des RX-Pins mit einem vielfachen der Baudrate abgetastet (dreifach scheint üblich) und High- bzw. Lowbits anhand einer Mindestanzahl identifiziert. (Beispiel: "Generic Software Uart" Application-Note von IAR)

Neuere AVRs (z. B. ATtiny26 oder ATmega48,88,168,169) verfügen über ein Universal Serial Interface (USI), das teilweise UART-Funktion übernehmen kann. Atmel stellt eine Application-Note bereit, in der die Nutzung des USI als UART erläutert wird (im Prinzip "Hardware-unterstützter Software-UART").

==Handshaking==
Wenn der Sender ständig sendet, wird irgendwann der Fall eintreten, daß der Empfänger nicht bereit ist, neue Zeichen zu empfangen. In diesem Fall muß durch ein '''Handshake-Verfahren''' die Situation bereinigt werden. Handshake bedeutet nichts anderes, als daß der Empfänger dem Sender mitteilt, daß er zur Zeit keine Daten annehmen kann und der Sender die Übertragung der nächsten Zeichen solange einstellen soll, bis der Empfänger signalisiert, daß er wieder Zeichen aufnehmen kann.
===Hardwarehandshake (RTS/CTS)===
Beim Hardwarehandshake werden zusätzlich zu den beiden Daten-Übertragungsleitungen noch 2 weitere Leitungen benötigt: '''RTS''' ('''R'''equest '''T'''o '''S'''end) und '''CTS''' ('''C'''lear '''T'''o '''S'''end). Jeder der beiden Kommunikationspartner ist verpflichtet, bevor ein Zeichen gesendet wird, den Zustand der '''RTS''' Leitung zu überprüfen. Nur wenn die Gegenstelle darauf Empfangsbereitschaft signalisiert, darf das Zeichen gesendet werden. Um der Gegenstelle zu signalisieren, daß sie zur Zeit keine Zeichen schicken soll, wird die Leitung '''CTS''' benutzt.

===Softwarehandshake (XON/XOFF)===
Beim Softwarehandshake sind keine speziellen Leitungen notwendig. Stattdessen werden besondere ASCII-Zeichen benutzt, die der Gegenstelle signalisieren, das Senden einzustellen bzw. wieder aufzunehmen.

* '''XOFF''' Aufforderung das Senden einzustellen
* '''XON''' Gegenstelle darf wieder senden

Nachteilig bei einem Softwarehandshake ist, dass dadurch keine direkte binäre Datenübertragung mehr möglich ist, denn von den möglichen 256 Bytewerten werden ja nun zwei (nämlich für '''XON''' und für '''XOFF''') für besondere Zwecke benutzt und fallen daher aus. In einem quasi-zufälligen Bytestrom, den eine Binärdatei darstellt, kämen diese beiden reservierten früher oder später vor und würden dann den Strom ungewollt stoppen und starten.

==Galvanische Trennung==
Für eine hohe Überspannungsfestigkeit empfielt es sich, die Datenkanäle über Optokoppler zu führen. Es bietet sich z.b. der 6N138 an, ein "normaler" CNY-17 ist für hohe Baudraten nicht brauchbar.

==Fehlersuche==
Erstaunlich oft wird im Forum der Hilferuf laut: "Meine UART funktioniert nicht, was mache ich falsch". In der überwiegenden Mehrzahl der Fälle stellt sich dann heraus, daß es sich um ein Hardwareproblem handelt, wobei da wiederrum der Löwenanteil auf das Konto einer nicht korrekt eingestellten Taktrate geht: Der µC benutzt nicht einen angeschlossenen Quarz, so wie er auch im Programm eingetragen ist, sondern läuft immer noch mit dem internen RC-Takt. Daraus resultiert aber auch, daß der Baudraten Konfigurationswert falsch berechnet wird.

Hilfreich zum Aufspüren solcher Fehler ist auch die [[AVR_Checkliste#UART/USART|AVR-Checkliste]].

==Links==
Tipps zur Verarbeitung von Strings sind in den [[FAQ]].

[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:UART und RS232]]

3-Phasen Frequenzumrichter mit AVR

2019-10-30T21:20:04Z

Pfleury: /* Siehe auch */

''von matzetronics''

{{Wettbewerb Header}}

In diesem Artikel wird ein universeller 3-Phasen Frequenzumrichter mit einem einzigen ATMega 88/168/328P beschrieben. Der ATMega übernimmt dabei die komplette Steuerung der Bedienelemente, des LC-Displays und die Erzeugung der 3 Phasen. Das Projekt sollte auf fertigen Boards wie dem Arduino 2009 oder dem Uno auch laufen, das wurde aber nicht ausprobiert.
Im Gegensatz zu anderen Lösungen wird hier der Sinus nicht errechnet, sondern aus einer Tabelle gewonnen. Das spart sowohl Rechenzeit als auch Speicherplatz und ermöglicht dem MC, die gesamte Steuerung als Einzelprozessor (Single Chip) zu erledigen. Gleitkommaberechnungen kommen nicht vor.

Die Frequenz und Amplitude der Ausgangssignale sind über 3 Tasten einstellbar und können permanent in das EEPROM des MC gespeichert werden. Ebenso ist eine externe Steuerung über 2 analoge Eingänge vorgesehen. Die Drehrichtung der 3 Phasen wird über eine Steckbrücke oder Schalter festgelegt.

Eine einstellbare V/f Charakteristik erlaubt die Anpassung an viele Motoren und andere Verbraucher. Ein integrierter PID Regler für die analogen Eingänge wurde ebenso programmiert, die PID Parameter können im EEPROM abgelegt werden. Die Totzeit ist einstell- und abspeicherbar.

Im groben Zügen basiert die Software auf der Application Note AVR447 von Atmel/Microchip, ist aber erheblich geändert, um sie für den hier beschriebenen Regler zu benutzen. Ebenso wird die LCD Bibliothek von Peter Fleury benutzt, herzlichen Dank an ihn für diese schöne Software. Leider passt das Programm beim derzeitigen Stand nicht ganz in einen ATMega48, mit ein wenig Optimieren in den Stringfunktionen könnte es aber klappen.
Um etwaigen Fragen vorzubeugen - nein, das Ganze läuft nicht in einem (veralteten) ATMega 8. Diesem fehlen sowohl die Timerfunktionen als auch die Pinchange Interrupts.

'''Daten:'''

Frequenzbereich: regelbar von ca. 0,6 Hz - 162 Hz

Ausgangsspannung: regelbar von 0V - 325 Vpp, maximal die vorhandene Zwischenkreisspannung

Wellenformen: Entweder Motorkurven ('Popokurven') oder Sinus, wählbar vor dem Kompilieren

== Beschreibung ==

Der MC ist mit einem LC-Display des HD44780 Industriestandard im 4-bit Modus und 3 einfachen (Digi-)Tastern ausgerüstet. Beim Einschalten prüft der MC das Vorhandensein einer Steckbrücke (Jumper) und schaltet dann entweder in den internen oder externen Steuermodus. Die komplette MC Steuerplatine ist galvanisch von der Motorendstufe getrennt, hierzu dienen 6 Optokoppler vom Typ HCPL3120. Diese Optokoppler liefern die Signale für klassische Halbbrücken Treiber vom Typ IR2110/2113, welche wiederum die MOSFet/IGBT Endstufen ansteuern. Die gezeichnete Endstufe ist nur als Beispiel zu verstehen, natürlich sind auch andere Konfigurationen denk- und machbar.

Die 3 Timer des ATMega laufen synchron und es werden die OC (Output Compare) Ausgänge aller Timer benutzt. Einer der Timer (Timer 1) liefert einen Overflow Interrupt, der dazu benutzt wird, die Schrittgeschwindigkeit der Sinuserzeugung einzustellen und danach neue PWM Werte in alle 3 Timer zu schreiben. Der Quellcode erhält dazu auch ausführliche Kommentare. Die Schrittgeschwindigkeit ist direkt proportional der erzeugten Frequenz und wird vom Benutzer eingestellt. Mehr dazu findet sich im Abschnitt [[3-Phasen_Frequenzumrichter_mit_AVR#Sinuserzeugung|"Sinuserzeugung"]].

Aus Gründen der Übersichtlichkeit errechnet der MC aber daraus die Frequenz in Hertz und zeigt diese auf dem Display. Ebenso wird die Amplitude der Wellenzüge über die Pulsbreite der PWM Signale eingestellt und auf dem Display in Prozent der Zwischenkreisspannung dargestellt. Da Drehstrommotore meistens mit einer V/f Charakteristik angesteuert werden, wird auch diese errechnet, bevor die Timer neu geladen werden.

Hier Fotos vom Prototyp. Der Kontrollteil wurde auf 2,54 mm Punktraster in Fädeltechnik gebaut, der Leistungsteil auf Streifenleiterplatine mit 5,08 mm Raster. Fädeltechnik ist meine bevorzugte Technik für Einzelstücke und Prototypen. Der MC befindet sich unter dem LC Display. Ganz rechts auch noch ein Bild eines meiner treuen Drehstrom Motore. Dieser Motor hat 550 Watt und arbeitete seit 1969 in meiner Brunnenpumpe. Die Pumpe ist völlig verrostet und nun ausser Betrieb, aber der Motor läuft noch wunderbar. Gefertigt wurde er von den Stephan-Werken in Hameln.

[[Bild:Kontroll.jpg|200px]] [[Bild:PA+Koppler.jpg|200px]] [[Bild:Stephan_Motor.jpg|200px]]

== Software, Bedienung und Kompilieren==

Die Software ist so konzipiert, das die PWM Erzeugung komplett in Interrupts läuft. Die Hauptschleife des Programmes erledigt die Benutzerführung mit Tastenabfrage und LCD Ansteuerung. Ingesamt gibt es zwei Anzeigemodi:
Modus 1 ist das normale Menü, in dem per Taste 1 zwischen V/f Einstellung und Frequenzjustage gewechselt werden kann. Taste 2 und 3 verringern bzw. erhöhen den gewählten Wert. Der Cursor des Displays steht dabei unter dem editierbaren Wert. Eine einfache Autorepeat Funktion mit Beschleunigung erleichtert das Einstellen.

Modus 2 wird durch gleichzeitiges Drücken der Tasten 1 und 2 erreicht. Dieses Menü dient dazu, die PID Werte des Reglers und die Totzeit der Brückensteuerung einzustellen und sowohl diese als auch die Startwerte für V/f und Frequenz ins EEPROM zu schreiben. Auch hier wechselt Taste 1 zwischen den Parametern und Taste 2 und 3 dienen zum Einstellen. Gleichzeitiges Drücken von 1 und 2 speichert die Werte, gleichzeitiges Drücken von 1 und 3 verlässt den Modus ohne Abspeichern. Es werden dabei die Werte für V/f und Frequenz gespeichert, die im Menü Modus 1 gerade eingestellt sind.

Im Betrieb mit externen Signal zeigt Modus 1 die Werte an, sie lassen sich aber nicht per Taster ändern. Modus 2 hingegen ist anwählbar und funktioniert auch bei externer Kontrolle, um PID Werte und Totzeit zu justieren. Ein Interrupt wird durch den Analog-Digital Wandler ausgelöst. Dieser liest den Wert des ADC aus und speichert ihn in globalen Variablen. Das 'switch-case' Konstrukt erlaubt es, weitere Kanäle des ADC zu nutzen, wenn das erforderlich werden sollte. Die DIP Variante des ATMega88/168 bietet diese Möglichkeit zwar nicht, hier sind alle Anschlüsse des ADC benutzt. Allerdings hat die QFP Ausführung noch die ADC Kanäle 6 und 7, diese könnten genutzt werden.

Die hier beschriebene Schaltung ermöglicht es, sowohl Frequenz als auch V/f Werte als analoge Signale anzulegen. Ohne externe Spannungsteiler wird eine Eingangsspannung von 0-5 Volt an den Eingängen erwartet.

Die LCD Bibliothek musste leicht modifiziert werden, da hier zwei unterschiedliche Ports für Daten- und Steuerleitungen benutzt werden. Die Änderungen befinden sich in lcd.h und sollten so übernommen werden, da die PWM Ausgänge des MC nicht verändert werden können.

Übrigens wurden bis auf den PID Regler und die LCD Routinen alle Softwareteile in einer Datei zusammengefasst, um dem Compiler die beste Optimierung zu ermöglichen. Als Optimierungseinstellung hat sich -Os bewährt. Vor dem Kompilieren sollte nicht vergessen werden, die benutzte Quarzfrequenz in Hz in die Projekteinstellungen einzutragen. Unter Linux sollte das Makefile mit einem -DF_CPU 16000000 ergänzt werden, in AS4 unter "Projekt Settings -> General". Wird das mitgelieferte *.aps als Projektvorlage benutzt, ist das jedoch unnötig. Das Software Paket enthält alle Dateien, um mit AVR Studio 4 das Projekt zusammenzubauen. Der Sourcecode besteht aus folgenden Dateien:

'''main.c, pid.c, lcd.c'''

Dazu kommen die Header:

'''vfd.h, vfdtables.h, pid.h, lcd.h'''

Besondere Aufmerksamkeit verdient vfd.h. Hier sind alle Deklarationen für das Projekt zusammengefasst. Wer main.c studiert, wird eine Menge Konstanten finden, sie alle werden in vfd.h deklariert.
Die am häufigsten benutzten Variablen sind die Schrittgeschwindigkeit (inco), der Zeiger in die Sinustabelle(sinTableIncrement), die Amplitude (amplitude) und das V/f Verhältnis (VperHz). Diese Variablen werden direkt in Registern gehalten, um die Arbeitsgeschwindigkeit zu erhöhen. Vermutlich wäre das nicht nötig, aber als Beispiel zur Verwendung direkter Registervariablen ist es evtl. auch für andere Projekte hilfreich.
Eine weitere direkte Registervariable ist (fastFlags). Dieses struct wird bitweise benutzt, allerdings sind hier nur 4 bits benutzt worden. Ein Bit für die Umschaltung zwischen externer und interner Kontrolle, dann 2 Bits für die benutzte Wellenform (entweder 'undefined' oder 'Sinus') und dann noch ein Bit für die gewünschte Drehrichtung.
Die Anzeigeparameter werden über Integermathematik errechnet, da Gleitkommazahlen vermieden werden sollten. Eine regelmässige Aufgabe des Timerinterrupts ist das Aufrufen der Routine 'SpeedController' (nach 200 Timerüberläufen). Hier wird im externen Kontrollmodus der PID Regler aufgerufen und ausserdem die Anzeigeparameter errechnet. Die Anzeige auf dem LCD erfolgt im Kommandointerpreter.

Nach dem Reset werden zuerst das LCD und die Ports initialisiert und alle Variablen vorbelegt. Im Anschluss folgen die Initialisierung der Timer, der Pinchange Interrupts, des ADC und des PID Reglers. Nun werden die Jumper abgefragt und das EEPROM eingelesen. Zum Schluss erfolgt die Freigabe der globalen Interrupts und damit der Frequenzerzeugung.

Während des Vorganges werden Diagnosezahlen auf dem LCD ausgegeben, um etwaige Probleme mit 'steckengebliebenen' Tasten oder andere Probleme zu melden. Am Ende folgt die Hauptschleife, in der der 'Kommandointerpreter' (execCommand) läuft.

Der Kommandointerpreter tut nichts anderes, als erstmal nach gedrückten Tasten zu schauen. Findet er eine oder mehrere Tasten gedrückt, wird das switch-case Konstrukt abgearbeitet. Anschliessend wird das LCD aktualisiert. Eine zweite Kommandoebene tut das für das erweiterte Menü, die Arbeitsweise ist die gleiche. Bei allen Einstellungen wird dafür gesorgt, das die Werte nicht 'überschlagen' können, da das oft fatale Folgen hätte. So ist es z.B. nicht möglich, durch Drücken der - Taste die Arbeitsfrequenz von 0,1 Hz direkt auf 162 Hz umzuschalten oder die Totzeit auf 0 zu stellen.

Noch eine Anmerkung zu AVR Studio 4 - die letzte Version ist 4.19 und um Kompilierfehler zu vermeiden, sollte man die AVR Toolchain 3.3.1 - 1020 benutzen, sonst wird man mit Fehlern belästigt. (Vielen Dank an kabelbieger). Alternativ ist WinAVR geeignet - die Version 20100110 funktioniert bspw. recht gut.

== Sinuserzeugung ==

Die drei Phasen für den Sinusausgang werden aus einer Tabelle geholt, diese befindet sich in der Datei 'vfdtables.h'. Hier liegen in einem Array die Werte für U,V und W (Heute auch oft L1, L2 und L3 genannt, früher auch als R, S und T bezeichnet).
Die erzeugte Frequenz wird dadurch bestimmt, nach wieviel Aufrufen der 'TIMER1_CAPT' ISR der Zeiger in die Tabelle inkrementiert wird. Wenn 'inco' z.B. 1 ist, wird der Zeiger in die Tabelle erst nach 255 Durchläufen inkrementiert und der nächste Tabellenwert in die Timer geladen. Da die Tabelle 192 Werte lang ist, resultiert das in einer Ausgangsfrequenz von 0,635 Hertz, die sich aus der PWM Wiederholrate von 31,25 kHz/256 = 8,192ms * 192 ergibt.
Ist 'inco' bei 255, wird der nächste Tabellenwert bereits nach 1/31,25kHz = 32µs geladen und das resultiert in einer Ausgangsfrequenz von 1/(32µs * 192) = 162,7 Hz. Mein Dank geht an CNCler, der das richtig erklärt hat.

Die Drehrichtung wird einfach dadurch gewechselt, das die Werte für V und W vertauscht werden, bevor die Timer geladen werden. Tabellenzugriff und das Laden der PWM Timer erfolgen gesammelt in der Timer 1 Overflow Interrupt Routine.

Diese Routine stellt somit den Kern der Sinuserzeugung dar. Der Betrieb von Halbbrücken erfordert das Einfügen einer Totzeit, in der weder der obere noch der untere Schalter der Halbbrücke angeschaltet sein darf. Würde das der Fall sein, wird die Versorgungsspannung kurzgeschlossen, was auf keinen Fall passieren darf. (Dieser Fall wird oft als 'Shoot-through' bezeichnet).
Da die Totzeit stark von den verwendeten Halbbrücken abhängig ist, wurde sie einstellbar gemacht. Die Routine 'InsertDeadband' errechnet für jeden Timer die erforderliche Totzeit, bevor die Werte für die PWM in den Timer geschrieben werden.

Die Totzeit wird im EEPROM abgespeichert. Aus Sicherheitgründen wird bei EEPROM Lesefehlern oder zu kleinen Werten für die Totzeit ein Minimum statt des ungültigen Wertes angewendet. Eine zu grosse Totzeit ist nicht schädlich, begrenzt aber den nutzbaren PWM Bereich und die Effektivität des Frequenzumrichters.
Es schadet aber natürlich nicht, bei der Erstinbetriebnahme von einer sehr hohen Totzeit auszugehen und diese dann unter Beobachtung der Stromaufnahme zu verringern. Die Einheit der Totzeit (DEAD_TIME_HALF) bei der Anzeige im Display sind MC-Zyklen. Die resultierende Totzeit über die Halbbrücke ist doppelt so hoch wie die eingestellten MC-Zyklen. Bei der gezeigten Schaltung ist ein Wert von 20 verwendet worden, resultierend in einer Totzeit von (2 * 20 * 62,5ns = 2500ns).
Bei schnellen MOSFets oder IGBTs kann dieser Wert möglicherweise noch verringert werden. Die Stromaufnahme kann am Shunt R7 gemessen werden.
'''Achtung: Dieser Teil ist nicht netzgetrennt und sollte deswegen mit Vorsicht behandelt werden.''' '''Eine Verbindung zwischen GNDI und PE führt unweigerlich zur Zerstörung von Bauteilen im Netzeingang.'''

Die Wellenform der Phasen ist bei der gezeigten Tabelle dem Betrieb von Motoren angepasst. Andere Wellenformen lassen sich durch Austausch der Tabelle erreichen. Seit dem Update wird nun die Option '#define PURE_SINE_DRIVE' in vfd.h angeboten. Es werden in diesem Fall 3 echte Sinuskurven mit 120° Phasenverschiebung erzeugt, ohne die typischen 'Popokurven' für BLDC ähnliche Ansteuerung.
Beim Austausch gegen andere Tabellen sollte beachtet werden, das die Länge der Tabelle mit der Originaltabelle übereinstimmt, da die Berechnung der Schrittweite davon abhängt. Wenn der MC mit einer anderen Frequenz als 16Mhz betrieben wird, sollte auch der Parameter 'DIVISIONEER' in der Datei 'vfd.h' angepasst werden, damit die Darstellung am Display korrekt ist. Irgendwie kriege ich es nicht hin, das der Wert direkt aus F_CPU errechnet wird, wäre schön, wenn mir das mal jemand beibringt.
Wer lediglich einen Wechselstrom Ausgang benötigt, sollte die Tabelle durch echte Sinuswerte ersetzen ( wie jetzt im Update vorgesehen) und nur 2 Endstufen aufbauen. Zwischen den Ausgängen dieser Endstufen ist dann ein regelbares Wechselspannungspotential.

Natürlich sollte die Drehrichtung eines mit voller Geschwindigkeit laufenden Motors nicht einfach umgekehrt werden. In jedem Fall ist es ratsam, den Motor zu stoppen und erst dann die Drehrichtung zu ändern.

== V/f ==

Die V/f Charakteristik ist die meist angewandte Methode bei Frequenzumrichtern, um die aufgenommene Leistung eines Motors mit seiner Drehzahl zu regeln. 'Volt per Frequenz' Charakteristik heisst, das ein Motor bei z.B. 100% seiner Drehzahl zwar schon mit der vollen Nennspannung betrieben werden darf, das aber bei reduzierter Drehzahl auch die Betriebsspannung heruntergeregelt werden muss. Bei z.B. 50% der Nenndrehzahl sollten auch nicht mehr als 50% der Betriebsspannung angelegt werden usw. Die genauen Werte sind unterschiedlich und sollten deswegen entweder dem Datenblatt des Motors entnommen werden oder durch Ausprobieren ermittelt werden.

Ein Hinweis liefert dabei das erzielte Drehmoment (die "Kraft") des Motors. Selbstverständlich sollte es dabei sein, dem Motor nicht mehr abzuverlangen, als er liefern kann. Lautes Brummen ist z.B. ein Zeichen für zu viel Spannung, das V/f Verhältnis sollte kleiner gemacht werden.
Oft ist es aber ausreichend, der Maschine bei Nennfrequenz (z.B. 50 Hz) gerade 100% Betriebsspannung zu liefern, bei einer reduzierten Frequenz reduziert der MC dann auch proportional die mittlere Spannung an den Motorwicklungen.

Übrigens erlaubt diese Steuerung auch, den Umrichter als 'regelbares Netzteil' zu missbrauchen. Ich habe z.B. mit einem schnellen Gleichrichter auch schon einen DC-Motor aus einer Waschmaschine mit einer Spannung von 24 Volt (Waschen) bis 200 Volt (Schleudern) betrieben.

== Schaltbild ==
Das Schaltbild (siehe unten) bietet keine grossen Besonderheiten. Was hier angeberisch als 'DC/DC Wandler' beschrieben wird, ist im Fall des 5 Volt Wandlers ein Schaltnetzteil vom Typ Handylader und im Fall des 18 Volt Wandlers ein kleines Schaltnetzteil für LED Lichterketten, das durch geringfügiges ändern des Regelkreises von 12 auf 18 Volt hochgedreht wurde. Der benötigte Strom ist abhängig von der gewählten Treiberschaltung und den Endstufen und liegt bei der gezeichneten Variante so um die 150mA für alle 3 Endstufen. Wichtig ist wie immer eine gute Entkopplung möglichst direkt an den Treiberbausteinen. Die impulsartige Belastung durch den Ladevorgang der Gates sollte durch Elkos aufgefangen werden, wie im Schaltbild gezeigt.
Der 5 Volt Zweig wird ohne Hintergrundbeleuchtung des LCD mit etwa 40-80mA belastet, wobei der Löwenanteil für die LEDs der Optokoppler draufgeht. Übrigens sind auch Kleinnetzteile mit Einweggleichrichtung am Markt zu finden, die auf keinen Fall aus der Zwischenkreisspannung gespeist werden dürfen. Solche Netzteile sind auf der Wechselstromseite des Netzeingangs anzuschliessen.

18 Volt werden übrigens nur deswegen verwendet, weil die gerade vorhandenen Optokoppler vom Typ 3120 mindestens 16 Volt Betriebsspannung benötigen. Hätte ich welche vom Typ HCPL3180 gehabt, hätten 12 Volt ausgereicht und das Netzteil hätte nicht manipuliert werden müssen. Leider sind die Optokoppler nicht ganz billig, theoretisch sollten es aber auch preiswertere schnelle Typen tun, wie z.B. der 6N137 oder HCPL2630.

Letzterer bietet 2 Koppler in einem Gehäuse. Dabei ist allerdings die Signaltreue zu beachten. Keinesfalls darf der Optokoppler die Phase invertieren! Dieser Fehler würde zum 'Shoot-Through' der Endstufen führen. Falls invertierende Koppler benutzt werden, müssen also die Polaritäten der OC Ausgänge in der Software umgedreht werden und mit entsprechenden Pulldowns und -Ups dafür gesorgt werden, das keine falschen Signale an den IR Treibern erscheinen. Die gezeigte Endstufe ('''gezeigt wird nur eine Phase, die anderen beiden sind identisch''') besitzt mit dem Shunt R7 und den Transistoren T1 und T2 eine integrierte Überstromsicherung.

Bei einem zu hohen Strom (hier ca. 2 Ampere) leitet T1 und steuert T2 durch. Das Highsignal am Kollektor von T2 aktiviert die Shutdown Eingänge der Treiber ICs. L4 und L3 sollten hochstromfähig sein, da hier der Motorstrom herüberfliesst.
Die kleinen Schaltnetzteile (aka "DC/DC Wandler") werden direkt aus der Zwischenkreisspannung versorgt. Diese liegt ja typisch bei ca. 325 Volt und ist damit genau richtig. Man könnte die internen Gleichrichter und Siebelkos entfernen, aus Faulheit ist das bei mir nicht geschehen.

Auffällig ist das Netzeingangsfilter. Frequenzumrichter sind dafür bekannt, das sie harte Pulse mit hoher Frequenz erzeugen und um zu verhindern, das diese auf das Netz zurückwirken, wurde eine recht aufwendige Schaltung vorgesehen. Es ist auch ratsam, bei längeren Leitungen vom Ausgang der Endstufe zum Verbraucher diese Leitung entweder zu schirmen, oder über ein Filter direkt am Ausgang des FU zu führen. Die PWM Frequenz liegt bei ca. 31 kHz und hat steile Flanken, deswegen sollte der Abstrahlung von Störfeldern bzw. die Verhinderung derselben ein wenig Aufmerksamkeit geschenkt werden. C15 bis C18 sollten übrigens X2 Typen sein, wobei C17/C18 auch ein Y Typ sein kann. Bestens geeignet sind designierte Entstörkondensatoren, solange sie die nötige Spannungsfestigkeit haben. Die Drosseln können entweder stromkompensiert sein oder einzeln. Wie auf dem Bild oben zu sehen ist, habe ich ein fertiges Netzfilter mit Kaltgeräteeingang benutzt, das erspart den diskreten Aufbau eines Filters. R7 (der Shunt) muss natürlich den Motorstrom vertragen, ich verwand einen 5 Watt Betonwiderstand. Der hohe Einschaltstrom bei leerem Zwischenkreiskondensator wird durch R11, einen Hochstrom NTC, begrenzt, wie er auch in PC Netzteilen üblich ist. Die Bauform 644 von z.B. Philips ist hier gut geeignet.

Die Kondensatoren parallel zu den Tastern sind übrigens keineswegs zum Entprellen, obwohl sie diese Funktion nebenbei auch erfüllen. Sie verhindern die Einstrahlung von Störsignalen durch naheliegende LCD- und PWM- Leitungen und sorgen für einen Mindeststrom in den Tastern. (Siehe auch: http://www.mikrocontroller.net/topic/287303 ). Die Taster werden zyklisch im 'Kommandointerpreter' der Software abgefragt und benötigen deswegen keine gesonderte Entprellung.

Neben dem ISP Anschluss ist ein als 'Feature' Anschluss bezeichneter Verbinder zu sehen. An diesen können die beiden Analogsignale (Pin 6 und 8) angelegt werden. Pin 6 (ADC Kanal 5) steuert das V/f Verhältnis während an Pin 8 (ADC-Kanal 4) das Frequenzregelsignal anliegt. Pin 4 dient zur Änderung der Drehrichtung. Eine nach Masse gesetzte Brücke wendet den Motor. Pin 2 schaltet zwischen externer (ADC) und interner Kontrolle (Taster und LCD) um. Bei gesetzter Brücke nach Masse wird auf externe Kontrolle umgeschaltet. Diese Prüfung wird nur nach einem Resetzyklus des MC durchgeführt. Änderungen im Betrieb sind also nicht vorgesehen.

'''Wichtig ist die Unterscheidung zwischen GND und GNDI''': GND ist der netzgetrennte Bezugspunkt für die Steuerelektronik des MC, während GNDI direkt mit dem Netz verbunden ist. '''Auf keinen Fall dürfen GND und GNDI miteinander verbunden werden!''' Im Gegenteil, ausreichende Sicherheitsabstände sind auf jeden Fall einzuhalten. In meinem Prototyp sind deswegen Kontroll- und Leistungsplatine völlig voneinander getrennt und nur durch die Optokopplerplatine verbunden.

[[Bild:VF_Sine_Drive.png|800px]]

== Fazit ==
Der gezeigte Frequenzumrichter ist durch die Einfachheit des Steuerungsteils und die Verwendung von Standardbauteilen ein dankbares Projekt, um die Möglichkeiten moderner Mikrocontroller zu demonstrieren und mit Motorsteuerungen zu experimentieren. Je nach verwendeter Endstufe können auch andere Motoren, z.B. E-Autos, Festplattenmotoren oder Spiegelmotoren aus Laserdruckern angesteuert werden.
Ändern der PWM Frequenz z.B. ist in der Routine TimersInit() vorgesehen. Andere Vorteiler Einstellungen für alle 3 Timer können hier mit Hilfe der im Moment auf 0 stehenden 'CSx1' eingefügt werden. Natürlich kann der MC auch mit dem internen 8 MHz Oszillator betrieben werden. Man erhält dadurch zwei weitere Portpins für z.B. Überstromrückmeldung oder Drehzahlüberwachung für den Preis einer niedrigeren PWM Frequenz.

Die externe Kontrolle über Analogeingänge ermöglicht z.B. auch, Servomotoren wie Capstan anzusteuern und mittels z.B. PLL zu stabilisieren. Der integrierte PID Regler mit einstellbaren Parametern erlaubt die Anpassung an verschiedenste Problemstellungen.
Ich bin jedenfalls gespannt, was dem Leser an Anwendungen einfällt und freue mich über Anregungen und Ideen.
Noch ein Hinweis: Es lohnt sich, die Preise der verschiedenen möglichen Controller zu vergleichen. Oft ist mittlerweile der 'grosse' ATMega328 billiger erhältlich als seine kleinen Brüder. Sollte ein anderer Controller verwendet werden (Mega88, 168 und 328 sind ja alle untereinander kompatibel), sollte das in den Projekteinstellungen berücksichtigt werden.

== Downloads ==
Der Download enthält neben dem Source Code für AVR Studio 4 mit WinAVR auch ein Schaltbild und die Schaltung im Eagle Format (*.sch). Da die Anwendungen sich erheblich unterscheiden können, wurde auf die Erstellung eines Platinenlayouts verzichtet, ist aber mit dem Schaltplan für Eagle duchaus möglich. Die gewählten Bauformen für Teile sind nicht unbedingt die optimalsten, etwas Handarbeit und Anpassung könnten also nötig werden.
AVR Studio 4 wurde wegen seiner Stabilität benutzt, der Code sollte mit evtl. geringen Anpassungen aber natürlich auch unter AS5, AS6 oder AS7 kompilieren. Wer auf jegliche Codeveränderungen verzichten möchte, findet fertige HEX Dateien im Sourcecode Ordner in Unterordner 'default', welche für Mega88, 168 und 328 vorkompiliert wurden, jeweils für Motorkurven- oder Sinuskurven Erzeugung.

* [[Datei:VF_Sine_Drive.zip Sourcecode]]

== Siehe auch ==
* [http://www.mikrocontroller.net/topic/288205 Diskussion zum Artikel]
* [http://www.zum.de/dwu/depotan/apem112.htm Flash Animation zu Drehstrom bei der DWU - Zentrale für Unterrichtsmedien e.V.]
* [http://www.atmel.com Atmel Application Note AVR447 - BLDC Motor Driver with Hallsensors and Sine Modulation]
* [http://www.atmel.com Atmel Application Note AVR221 - A universal PID Controller with AVR]
* [http://www.peterfleury.epizy.com/ Peter Fleurys Homepage mit der verwendeten LCD Bibliothek]
* [http://www.infineon.com/ Infineon - Datenblätter und Applikationen für Treiber, MOSFet und IGBT]

[[Kategorie:AVR-Projekte]]
[[Kategorie:Spannungsversorgung und Energiequellen]]
[[Kategorie:Wettbewerb]]

IR-LCD

2019-10-30T21:17:46Z

Pfleury: /* Links */

'''Universeller Infrarot Decoder und Sender mit LCD Anzeige''' 

von '''[http://www.mikrocontroller.net/user/show/f_klee Frank Klee]''' 
Das ist ein kleines Projekt das auf der [[IRMP]] und [[IRSND]] Software von Frank Mayer basiert. Es dient als kleines Testgerät, um Infrarotfernsteuerungen zu untersuchen. Das Projekt wurde ursprünglich von Klaus Leidinger entwickelt und ist von mir um die Möglichkeit, IR-Telegramme zu senden erweitert worden. Ein vorhandenes IR-LCD nach Klaus Leidinger kann an die neue Version angepasst werden. Wie beschreibe ich weiter [[IR-LCD#.C3.84nderungen_an_IR-LCD_von_Klaus_Leidinger|unten]].
[[Bild:IR-LCD.jpg|300px|thumb]]

Man kann mit dem Gerät nicht nur Infrarotcodes anzeigen lassen. Ich habe z.B. für meinen Receiver einen Code (durch ausprobieren) entdeckt und ihn dann in eine programmierbare Fernbedienung programmiert. 
=== Hardware ===
Die Schaltung ist sehr einfach aufgebaut und besteht eigentlich nur aus einem Mikrocontroler mit LC-Display, einem IR-Empfängermodul und einer IR-Senderdiode mit Treiber. Der Aufbau erfolgt auf einer einseitigen Platine und benötigt nur 7 Brücken. Die Platine ist also für Selberätzer gut zu verwenden. Aufgrund der teilweise engen Leiterbahnführung ist etwas Umsicht beim löten angesagt. 
 
[[Bild:ir-lcd-v2Schaltplan.png]]
 
Das Layout ist einseitig und enthält sieben Brücken. Daher ist die Platine sicher auch für Selbstätzer geeignet, Der Programmierstecker K1 ist optional. Lässt man ihn weg entfallen drei Brücken. An den Steckverbinder K2 wird ein USB <-> TTL Wandlerkabel angeschlossen. Ich nutze dafür eines, das die Fa. Reichelt für den Raspberry Pi für wenig Geld anbietet. Dieses kabel sorgt auch für die Stromversorgung, entweder über den PC oder im Standalone-Betrieb über ein USB-Netzteil. 
Der Kondensator C12 stammt aus dem Originalschaltplan von Klaus Leidinger. Bei mir hat er zu Schwierigkeiten geführt und ich habe ihn ersatzlos gestrichen. 

=== Software ===
Basis ist die IRMP und IRSND Software von Frank Mayer, bei der ich nur den Teil zur Anzeige der Daten auf dem LCD und dem seriellen Port bzw. die Befehlsauswertung der Befehle vom seriellen Port bzw. die Befehlseingabe per Drehimpulsgeber dazu gebaut habe. Ich verwende dabei die LCD- und UART-Library von Peter Fleury. Vielen Dank an dieser Stelle. Originaldateien siehe in den Links. Die Encoder-Library habe ich geschrieben, nachdem ich diese Dinger fast in jedem Projekt einsetze. Wer einen anderen Encoder einsetzen möchte muss eventuell die encoder.h entsprechend anpassen. Hat man einen Two-Step oder Single-Step Encoder erwischt, muss die Auskommentierung der entsprechenden defines gelöscht oder gesetzt werden. 
Das Programm basiert auf der IRMP-Version vom 07.05.2015 und IRSND-Version vom 26.01.2015. Die serielle Schnittstelle arbeitet mit 38400 Baud, 8N1. Zur Kommunikation kann ein einfaches Terminalprogramm genutzt werden. Da es ziemlich mühselig ist, die Befehle Zeichen für Zeichen in die Tastatur zu tippen, habe ich ein kleine VB6-Programm geschrieben, das die Kommunikation übernimmt. 
Ich nutze AVR-Studio 6.2 zur Entwicklung meiner Software. Die entsprechenden Projektdateien findet ihr im Download. 
=== Bootloader ===
Um die Software bei eventuellen Änderungen bequem auf den Mega328 laden zu können habe ich ihm einen Bootloader spendiert. Um den Bootloader zu aktivieren muß der Taster während des Powerup gedrückt gehalten werden. Die Parameter des Bootloaders sind: 38400 Baud, Protokoll avr109. 
Im Download die an den Mega328 angepasste Version. Zur Programmierung nutze ich Avr-Osp II von Mike Henning, den ich in AVR-Studio eingebunden habe. Es kann natürlich auch jede andere Software verwendet werden, die das AVR109-Protokoll unterstützt. 
=== Fusebits einstellen ===
Wenn der Bootloader benutzt wird, müssen die Fusebits entsprechend eingestellt sein: 

[[Bild:FusesBootloader.png]] 
Ohne Bootloader sieht es so aus: 
[[Bild:Fuses.png]] 
Bei anderen Programmern dementsprechend... anders 

=== IR-Tester ===
Das Programm IR-Tester ist eigentlich selbsterklärend. Zur Sicherheit habe ich aber noch eine kleine Hilfedatei geschrieben. Das Programm scannt automatisch die ersten 16 COM-Ports, ob sich daran IR-LCD befindet. Der Port wird gespeichert, so dass beim nächsten mal nicht mehr gescannt werden muss. Man kann den Port aber auch manuell auswählen. In einem Fenster werden daraufhin alle empfangenen, decodierten Frames und auch die gesendeten Befehle angezeigt. Durch klicken auf einen Frame kann man diesen auch wieder senden oder vorher verändern. 
=== Änderungen an IR-LCD von Klaus Leidinger ===
Wer bereits einen IR-LCD gebaut hat möchte diesen natürlich weiter benutzen. Das ist ohne weiteres Möglich, es sind nur ein paar kleine Änderungen erforderlich. Das Programm ist größer als 16k und passt deshalb nicht mehr in einen ATmega168. Dieser muss gegen einen ATmega328 getauscht werden. Um Eingaben tätigen zu können war eine entsprechende Eingabeeinheit erforderlich. Der verwendete Drehimpulsgeber kann einfach nachgerüstet werden mit dem Nachteil, dass das vorhandene Gehäuse dann zu klein ist. Will man auf den Standalone-Betrieb verzichten kann der Drehimpulsgeber auch weggelassen werden. Alle anderen Änderungen beruhen darauf, dass ich auf den V24-Wandler verzichtet und statt dessen einen USB <-> TTL Wandler mit Spannungsversorgung benutzt habe. Dadurch war der Spannungsversorgungsteil ebenfalls überflüssig.
=== Downloads ===
==== Hardware: ====
Target Datei: [[Datei:ir-lcd-v2.T3001|ir-lcd-v2.T3001]] 
Schaltplan als PDF: [[Datei:Ir-lcd-v2_Schaltplan.pdf|Schaltplan.pdf]] 
Schaltplan und Layout nur zur privaten Verwendung. Gewerbliche Nutzung nur mit meiner Zustimmung.

==== Software: ====
Bootloader passend für IR-LCD: [[Datei:Bootloaderm328.zip|bootloaderm328.zip]] 
IR-LCD Software V2.0: [[Datei:ir-lcd-v2.zip|ir-lcd-v2.zip]] 
IR-Tester: [[Datei:irtester-setup.zip|irtester-setup]] 

=== Links ===
Beschreibung IRMP (Frank Mayer) : 
* [[IRMP]] 
* [[IRSND]] 

Diskussionsforum zu IRMP/IRSND auf microcontroller.net : 
* [http://www.mikrocontroller.net/topic/162119 Beitrag: Infrared Multi Protocol Decoder] 

Bootloader: 
* [http://atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109: Using Self Programming on tinyAVR and megaAVR devices] 
* Software: [http://atmel.com/dyn/resources/prod_documents/AVR109.zip AVR109.zip]

LCD Library von Peter Fleury (original): 
* http://www.peterfleury.epizy.com/avr-software.html

aktuelle Target Layout Software (kostenlose Demo): 
* http://ibfriedrich.com/index.htm

=== Danksagung ===
Neben allen anderen, die an der Erstellung der Librarys für dieses Projekt mitgewirkt haben, möchte ich mich bei Klaus Leidinger bedanken, der mich zu diesem Wiki-Artikel ermuntert hat.

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

I²C

2019-10-30T21:15:28Z

Pfleury: /* Bibliotheken */

'''I²C''' (gesprochen "I quadrat C") ist ein synchroner serieller Zweidraht-[[Bus]], der jeweils eine bidirektionale Daten- und Taktleitung verwendet und für die Kommunikation zwischen [[IC]]s über kleine Distanzen geeignet ist. Die Bezeichnung steht für IIC, Inter-Integrated Circuit. Der Bus wurde Anfang der 80er Jahre von Philips entwickelt.

Aus Lizenzgründen heißt der I²C Bus bei manchen Herstellern auch '''TWI''', two wire interface (siehe [[AVR TWI]]). Im PC wird ein dem I²C-Bus sehr ähnliches System benutzt, um z. B. die Daten eines SDRAM-Modules auszulesen. Dieser nennt sich [[SMBus]] (System Management Bus).

=== Busstruktur und Adressierung ===
In einem I²C-Bus gibt es mindestens einen Master sowie bis zu 127 Slaves. Ein I²C-Bus mit mehreren Mastern wird als "Multi-Master-Bus" bezeichnet.

Die Slaves in einem Verbund müssen alle mit einer eigenen, individuellen Adresse codiert werden. Somit sind sie für jedem Master individuell anzusprechen. Darüber hinaus existiert ein sogenannter Broadcastkanal, mit dem alle Slaves gleichzeitig angesprochen werden können.

Ein Problem mit manchen Slaves ist der eingeschränkte Adressbereich, d.h. sie liegen auf einem definierten Bereich und haben darin z.b. nur 3 Bit als Programmieroption. Somit schließen diese Slaves indirekt andere Adressen aus.

=== Adressierung ===
Der (oder die) Master sprechen die Slaves jeweils aktiv an. Slaves können '''nie''' selbstständig beginnen, Daten zu senden. Um eine Kommunikation zu etablieren, übernimmt der Master, der Daten senden oder empfangen möchte, den Bus und gibt die (7-bit- bzw. 10-bit-)Adresse des Slaves aus, mit dem er kommunizieren möchte.
Nach der Adresse teilt der Master dem entsprechenden Slave mit, ob er Daten senden oder empfangen möchte. Danach werden die eigentlichen Daten (entweder vom Master oder Slave) auf den Bus gelegt. Hat der Master den Lese- oder Schreibvorgang abgeschlossen, so gibt er den Bus wieder frei.
Sofern mehrere Master vorhanden sind, stellt ein logisches Protokoll sicher, dass sich diese nicht gegenseitig stören. Im Fall einer broad cast Operation kann ein time slot System sicherstellen, dass nie mehr als ein slave gleichzeitig antwortet.

=== Handshaking / Quittierung ===
Die Kommunikation auf Bitebene erfolgt seitens des Masters durch Senden von Start / Stopp Bedingungen, die sich aus der Kombination der Zustände von Takt- und Datenleitung ergeben. Um die erfolgreiche Kommunikation zwischen Master und Slave sicherzustellen, senden Slaves - ausser im broadcast Betrieb - nach erfolgreicher Dekodierung ihrer Adresse sowie im Schreibfall ein Acknowledge, in dem sie die Datenleitung ziehen. Diese muss dazu vom Master rechtzeitig freigegeben worden sein und beobachtet werden. Umgekehrt quittiert der Master in ähnlicher Weise den Empfang eines Datenbytes vom Slave und signalisiert somit weitere Empfangsbereitschaft. Der Takt wird immer vom Master getrieben.

=== Übertragungsraten ===
Die genormte Übertragungsrate beträgt beim sogenannten "standard mode" 100 kbit/s, beim "fast mode" 400 kbit/s und beim "fast mode+" 1000kbit/sec. Im sogenannten high-speed mode, der mit etwas anderen Spannungs- und Stromrandbedingungen arbeitet sind es zu 3,4 MBit/s. Die Raten beziehen sich auf die festgelegten Taktraten. Andere sind möglich, jedoch nicht genormt.

Die reale maximale Datenrate ist infolge des asynchronen Betriebs und der Pausen meistens etwas niedriger. Zudem kann - falls die Taktrate für einen Slave zu hoch ist - die Clock-Leitung auf Null durch ihn auf GND gezogen- und damit die Übertragung verlangsamt werden, was als sog. "Clock Stretching" bezeichnet wird. Dies ist auf Bit- wie auf Byte-Ebene möglich; ersteres allerdings nicht im high-speed mode.

==== Reale Beispiele ====
Um sich an längere Übertragungswege anzupassen, kann man die Taktrate theoretisch beliebig vermindern, jedoch erzeugen einige Bausteine aber irgendwann ein Time-Out. Manche interpretieren einen lange niedergehaltenen Takt auch als Reset. Daher sind Taktraten von unter 1kbps in der Regel nicht denkbar.

Als Beispiel können jedoch mit einer Taktfrequenz von nur 5 kbit/s durchaus mehrere Meter überbrückt werden:

Erfahrungen mit den Atmegas (gemessene I2C-Taktfrequenzen):
* 16,000MHz - schafft sauber bis zu 700KHz
* 18,432MHz - schafft sauber bis zu 950KHz

Selbst unter schlechten Bedingungen wie...

* 50cm 6-adriges Spiralkabel, frei schwingend verbaut in einem Rennwagen als Verbindung zwischen Lenkraddisplay und Amaturenbrett
* Nähe zu nicht geschirmten Leitungen mit 12V, GND und 5V PWM zum Dimmen von LEDs
* grausamen Umgebungsbedingungen, Fahrten im Regen, Schnee oder bei glühender Sonne und gefühlten 100° C ;-) auf der Rennstrecke.

... hat der Bus ohne Probleme funktioniert.

Um anders herum hohe Bandbreiten zu erreichen, lassen sich krumme I2C-Frequenzen ausserhalb der SPEC verwenden, damit sie besser zu den Controllern und deren Taktfrequenzen passen.

=== Bausteine ===

Neben Mikrocontrollern gibt es eine Reihe von Peripheriebausteinen, die per I²C angeschlossen werden können. Eine gute Anlaufstelle bei der Suche ist die unten angegebene Seite des "Erfinders" Philips, heute als [http://www.nxp.com NXP] bekannt.

*serielle [[Speicher#EEPROM | EEPROM]]s
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=24C01&action=Search 24Cxx]
** [http://ics.nxp.com/products/pcf/seeproms/ PCF85xx von NXP, 256-2048 Byte]

*I/O-Portexpander
** [[Port-Expander_PCF8574|PCF8574]]
** [http://www.mikrocontroller.net/part/MCP23008 MCP23008] (8-bit) von Microchip
** [http://www.mikrocontroller.net/part/MCP23017 MCP23017](16-bit) von Microchip

* I2C MUX, zum Anschluss von ICs mit gleicher, fester Adresse
** [http://www.datasheetcatalog.org/cgi-bin/helo.pl?field=Nume&type=C&text=PCA9545A&producedby=&action=Search PCA9545A]

* [[AD-Wandler]]
** [http://www.mikrocontroller.net/topic/182614 12x12 Bit ADC MAX1238]
** [http://www.mikrocontroller.net/topic/182614 12x10 Bit ADC MAX1138]
** [http://www.maxim-ic.com/datasheet/index.mvp/id/1890 MAX127 und MAX128 von Maxim, 12bit x8, PDIP24+SSOP28]
** [http://www.jtronics.de/platinen.html 12x8 Bit ADC MAX1038]

* [[DA-Wandler]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=TDA8444&producedby=&action=Search TDA8444, 8x6Bit]

* Uhrenbausteine
** [http://ww1.microchip.com/downloads/en/DeviceDoc/20005010F.pdf MCP7940N]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8583&producedby=&action=Search PCF8583, mit 256 Bytes RAM]
** DS1307

* [[LCD]]-Treiber
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?field=Nume&type=C&text=PCF8577&producedby=&action=Search PCF8577, 2x32 Segmente]

*[[LED]]-Treiber
** [http://www.mikrocontroller.net/part/HT16K33 HT16K33] (RAM Mapping 16*8 LED) von Holtek
** SAA1064 (seit 2005 abgekündigt! Restposten sehr teuer)

* [[Temperatursensor|Temperatursensoren]]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=DS1621&action=Search DS1621]
** [http://www.datasheetcatalog.net/cgi-bin/helo.pl?text=lm75&action=Search LM75]
** [http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT21.pdf SHT21]
** TMP101 von TexasInstruments
** TMP175 von TI (mehr als 8 Bausteine im gleichen Bus möglich)

* Drucksensoren
** SMD500
** BMP085

* Beschleunigungssensor
** [http://www.mikrocontroller.net/articles/BMA020 BMA020]

* Audioverstärker
** TPA2016
** TPA2026
** TDA8594

* TPMs (Trusted Platform Module)
** [http://www.infineon.com/cms/de/product/security-and-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/channel.html?channel=5546d462503812bb015066de24291768 SLB 9645]

=== Galvanische Trennung ===
* http://www.analog.com/static/imported-files/application_notes/AN_913.pdf
* http://www.analog.com/en/interface/digital-isolators/products/index.html#Isolated_I2C_Isolators
* http://www.silabs.com/Support%20Documents/TechnicalDocs/Si840x.pdf '''(Not Recommended for New Designs)'''
* http://www.silabs.com/applications/industrial/Pages/i2c-isolation.aspx
* http://www.mikrocontroller.net/attachment/5670/Galvanische_Trennung_fuer_I2C-Bus.pdf
* http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus/frequently-asked-questions/i2c-faq.html
* http://www.mikrocontroller.net/topic/17425#125464
* https://www.mikrocontroller.net/articles/Modulares_Board#I2C_Bus_Isolator

== Siehe auch ==
* [[AT91-TWI]]
* [[AVR TWI]]
* [[I2C als Hausbus]]
* [[Modulares Board]]
* [http://www.mikrocontroller.net/topic/181115#1748880 Forumsbeitrag]: I2C-Adressen mit 7 oder 8 Bit
* [https://www.mikrocontroller.net/topic/385874#4410598 Forumsbeitrag]: I2C über lange Entfernungen als differentielles Signal übertragen.

== Weblinks ==
* [http://www.nxp.com/products/interfaces/ic-bus:MC_41735 NXP (ehemals Philips) Produktseite]
* [http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf I2C Spezifikation 3.0]
* [http://www.i2c-bus.org I²C Bus FAQ, Einführung, Hintergrundinformationen zum I2C Bus auf Deutsch und Englisch]
* [http://www.robotikhardware.de/download/rn_pc_i2c.pdf robotikhardware.de]
* [http://www.elektronikwissen.net/pegelwandler/7-bidirektionaler-levelshifter-fuer-i2c.html Betrieb von 3V3 und 5V-Bausteinen am I2C-Bus]

=== Bibliotheken ===
* [http://www.jtronics.de/avr-projekte.html AVR TWI Slave]
* [http://www.mikrocontroller.net/topic/235733#2398750 TWI MASTER in ASM]
* [http://www.peterfleury.epizy.com/avr-software.html AVR TWI/I2C MASTER in C (Peter Fleury)]
* [http://www.mikrocontroller.net/topic/87597 AVR TWI Master und Slave Funktionen in C]
* [http://www.mikrocontroller.net/topic/266642 universelle I2C Master Prozedur für AVR]
* [http://www.mikrocontroller.net/topic/103600 I2C (TWI) Sniffer mit AVR]
* [https://www.mikrocontroller.net/topic/334653#3697582 I2CLCD], HD44780 LCD Ansteuerung über I2C Bus

===I²C-Interface===
* [http://www.mikrocontroller.net/topic/155136#1462320 Beitrag "i2c usb interface"] Diskussion zu Interfaces für Linux
* [http://sprut.de/electronic/pic/projekte/usb4all/usb4all.htm USB4ALL bei sprut.de] universeller USB-Baustein, auch für I2C (5V, CDC/Virtual-Comport)
* [http://www.totalphase.com/products/aardvark-i2cspi/ Aardvark I2C/SPI Host Adapter], Universeller Adapter für I2C und SPI
* [http://www.elv.de/usb-i2c-interface-komplettbausatz-inkl-gehaeuse-bearbeitet-und-bedruckt-usb-kabel-3-anschlusskabel.html USB-I2C-Interface] Komplettbausatz von ELV (5V, Virtual-Comport)
* [https://github.com/harbaum/I2C-Tiny-USB i2c-tiny-usb] Open Source/Hardware (5V, Linux-Kernel-Treiber, C/C++ Beispiele)
* [https://www.fischl.de/i2c-mp-usb/ I2C-MP-USB] Open Source (3,3V und 5V, Linux-Kernel-Treiber, Python-Bibliothek für Windows/MacOS/Linux)

===I²C-Monitor===
*http://realterm.sourceforge.net/#I2C%20Bus
*http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_id=411
* [http://www.telos.info/p/hw/conniimm20/ telos Connii MM 2.0 - I²C Monitor with USB Interface]
* [http://www.telos.info/p/hw/traciixl20/ telos Tracii XL 2.0 - High-End I²C Monitor]
*http://i2cchip.com/
* [http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab I2C Logger Firmware für USB AVR-ISP]
* [http://www.mikrocontroller.net/topic/41535 I2C Monitor mit Mega8 (Firmware)]
* [http://warmcat.com/milksop/cheapi2c.html Cheapi2c] by Numbnut (Andy Green) uses your PC CPU (Linux only!) and printer port to perform realtime snooping of a standard 100kHz I2C bus with 100% capture.
* [http://www.mikrocontroller.net/topic/103600#905495 I2C (TWI) Sniffer]. Basierend auf einem ATtiny85 mit Ausgabe auf RS232 (C und ASM).
* [http://en.radzio.dxp.pl/i2c-sniffer/ I2C/TWI bus sniffer/analyzer] (ATTiny2313 @ 20 MHz und USB über FTDI FT245RL oder UM245R)
* [http://www.i2cchip.com/start_bit_detector1.jpg I2C Startbit-Detector] auf [http://www.i2cchip.com/ www.i2cchip.com]

[[Category:I2C| ]]

HD44780

2019-10-30T21:11:58Z

Pfleury: /* Weblinks */

Der HD44780 ist ein Steuer-IC für Textdisplays (siehe [[LCD]]). Praktisch alle Textdisplays werden mit diesem oder einem kompatiblen Controller (z. B. KS0066) angesteuert.

== Allgemeine Ansteuerung ==

=== Pinbelegung ===

Die Pinbelegung des ICs selber ist für den Anwender praktisch uninteressant. Hier ist die häufigste Anschluss-Belegung der damit ausgestatteten LCD-Module angegeben.

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

{| class="wikitable"
!style="width:5%" | Pin || style="width:10%" | Funktion || Beschreibung
|-
|1 || | USS || Bezugspotenzial 0 Volt
|-
|2 || | UCC || Speisespannung + 5 Volt, ≈ 1 mA

|-
|3 || | U0 ||Kontrastspannung, zwischen UCC und USS, typisch 0..1 V, kann auf USS gelegt oder via Potenziometer (Richtwert 10 kΩ) angeschlossen werden. Bei großflächigen LCDs oder LCDs für den erweiterten Temperaturbereich kann auch eine negative Kontrastspannung im Bereich von 0..–5 V nötig sein.
|-
|4 || | RS || Registerauswahl 0 = Befehlsregister, 1 = Datenregister
|-
|5 || | R/W || Lese- oder Schreibzugriff; kann fest auf GND gelegt werden, wenn Busy-Auswertung durch Warten ersetzt wird 0 = Schreiben, 1 = Lesen
|-
|6 || | E || Freigabe- und Taktleitung (Achtung! Diese Leitung hat im Gegensatz zu den anderen bei einigen Displays keinen internen Pullup, man muss also einen externen vorsehen, falls man mit Open-Drain-Ausgängen arbeitet.)
|-
|7 || | DB0 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|8 || |DB1 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|9 || |DB2 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|10 || |DB3 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|11 || |DB4 || Datenleitung
|-
|12 || |DB5 || Datenleitung
|-
|13 || |DB6 || Datenleitung
|-
|14 || |DB7 || Datenleitung
|-
|15 || A || Anode der LED-Hintergrundbeleuchtung (fakultativ)
|-
|16 || K || Katode der LED-Hintergrundbeleuchtung (fakultativ)
|-
| || || Es gibt auch Displays ohne die Datenleitungen DB0-3 (werden nur im 4-Bit-Modus angesteuert), dann rutschen die Bezeichnungen dann entsprechend nach unten
|}

===Speicher===

Ein HD44780 besitzt mehrere Speicher. In ihnen wird der Inhalt des Displays sowie das Aussehen von Sonderzeichen gespeichert.

==== CGROM ====

Der '''C'''haracter '''G'''enerator '''ROM''' enthält die Zeichen in Form von 5x8 oder 5x10 Punktmatrizen. Er kann nicht geändert werden, ausser man sendet einen EEPROM zu Hitachi für eine Massenproduktion. Es sind viele verschiedene ROMs (Zeichensätze, engl. Fonts) verfügbar. Er ist für den Anwender nicht zugänglich.

==== CGRAM ====

Im '''C'''haracter '''G'''enerator '''RAM''' können acht 5x8 Pixel oder vier 5x10 Pixel große benutzerdefinierte Zeichen abgelegt werden. Braucht man keine benutzerdefinierten Zeichen, kann man diesen Bereich als Auslagerungsspeicher für den ansteuernden Mikrocontroller benutzen. Dazu muss aber die '''R/W''' Leitung angesteuert werden.

==== DDRAM ====

Im '''D'''isplay '''D'''ata '''RAM''' ist der Inhalt des LCDs gespeichert. Die Kodierung orientiert sich weitestgehend am ASCII Zeichensatz.

Das DDRAM hat üblicherweise mehr Speicherstellen als das Display gleichzeitig anzeigt. Durch Anwenden der Display-Shift-Befehle können die nicht sichtbaren Zeichen zur Anzeige gebracht werden.

Benachbarte Zeichen haben im DDRAM nicht zwangsweise auch aufeinanderfolgende Adressen. So ist etwa bei 1x16-Displays (1 Zeile, 16 Zeichen) oft in der Mitte des Displays ein Adresssprung von 0x07 auf 0x40; bei 2x16-Displays ist der Sprung auf 0x40 normalerweise (programmiererfreundlich) zwischen Ende der ersten und Beginn der zweiten Zeile. Näheres ist dem Datenblatt zu entnehmen.

=== Kommandos ===

{| class="wikitable"
|+ '''HD44780 Befehlssatz'''
!style="width:30%" | Befehl
!RS
!RW
!D7
!D6
!D5
!D4
!D3
!D2
!D1
!D0
|-
|Bildschirminhalt löschen
|0
|0
|0
|0
|0
|0
|0
|0
|0
|1
|-
|Cursor auf Startpos
|0
|0
|0
|0
|0
|0
|0
|0
|1
|X
|-
|Modus festlegen
|0
|0
|0
|0
|0
|0
|0
|1
|I/D
|S
|-
|Display/Cursor
|0
|0
|0
|0
|0
|0
|1
|D
|C
|B
|-
|Cursor/Display schieben
|0
|0
|0
|0
|0
|1
|S/C
|R/L
|X
|X
|-
|Funktionen
|0
|0
|0
|0
|1
|DL
|N
|F
|X
|X
|-
|CGRAM Adresse setzen
|0
|0
|0
|1
|colspan ="6" align="center"|CGRAM-Adresse
|-
|DDRAM Adresse setzen
|0
|0
|1
|colspan="7" align="center"|DDRAM-Adresse
|-
|Adresse/Status lesen
|0
|1
|BF
|colspan="7" align="center"|CG-/DDRAM-Adresse
|-
|Daten in DDRAM/CGRAM schreiben
|1
|0
|colspan="8" align="center"|Daten
|-
|Daten aus DDRAM/CGRAM lesen
|1
|1
|colspan="8" align="center"|Daten
|}

{| class="wikitable"
|+ '''Kodierung der Steuerbits'''
!Bit
!0
!1
|-
|I/D
|Cursorposition dekrementieren
|Cursorposition inkrementieren
|-
|S
|Displayinhalt fest
|Displayinhalt weiterschieben
|-
|D
|Display aus
|Display an
|-
|C
|Cursor aus
|Cursor an
|-
|B
|Cursor blinkt nicht
|Cursor blinkt
|-
|S/C
|Cursor bewegen
|Displayinhalt schieben
|-
|R/L
|Nach links schieben
|Nach rechts schieben
|-
|DL
|4-Bit Interface
|8-Bit Interface
|-
|N
|1-zeiliges Display
|2/4-zeiliges Display
|-
|F
|5×7-Font
|5×10-Font
|-
|BF
|Kann Kommandos annehmen
|Ist beschäftigt
|}

== Ansteuerung per Microcontroller ==

Die Ansteuerung eines HD44780-basierten Displays gestaltet sich sowohl in Bezug auf den Hardware- als auch den Softwareaufwand recht einfach. Sie eignet sich somit sehr gut als Übungsprojekt für Anfänger.

Das HD44780-Interface besteht aus acht Datenleitungen (D0-D7) sowie den drei Steuerleitungen RS ('''R'''egister '''S'''elect), R/W ('''R'''ead/'''W'''rite) und E ('''E'''nable). Die Displays werden mit 5V Betriebsspannung versorgt, die Kontrastspannung V0 bekommt man, indem man ein 10kΩ-[[Potentiometer]] zwischen VCC und GND anschließt und den mittleren Anschluss als Kontrastspannung verwendet. Bei ca. 0,5 Volt werden dann die Pixel sichtbar. Optional haben viele Displays noch eine LED-Beleuchtung eingebaut, diese kann manchmal direkt an 5V angeschlossen werden, da der Vorwiderstand auf der LCD-Platine integriert ist. Oft ist aber auch ein externer Vorwiderstand nötig! Darum vorher besser im Datenblatt nachschauen.

Möchte man IO-Pins am Mikrocontroller sparen, kann das Display im 4-Bit-Modus betrieben werden, die Dateneingänge D0 bis D3 bleiben dann offen. Durch zusätzliche Bauteile ([[AVR-Tutorial:_Schieberegister]]) kann die Zahl der benötigten Port-Pins noch weiter reduziert werden.

Beispielprogramme zur Ansteuerung findet man zuhauf im Internet, u.a. auch hier: [[AVR-Tutorial: LCD]] und [[AVR-GCC-Tutorial/LCD-Ansteuerung|AVR-GCC-Tutorial: LCD-Ansteuerung]]

=== Fertige Projekte oder Bibliotheken ===

* Peter Fleurys [http://www.peterfleury.epizy.com/avr-software.html LCD library for HD44780 based LCDs]
* avr-libc [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Demo-Projekt für stdio]
* [http://www.ipd.uka.de/~buchmann/microcontroller/lcd.htm Grundlagen und Code für 8051] von Erik Buchmann
* [http://www.ekenrooi.net/lcd/lcd.shtml ''How to control a HD44780-based Character-LCD''] von Peter Ouwehand. Beispiele für 8051, PIC16C54, AT90S2313
* Firma wickenhäuser [http://www.wickenhaeuser.de 8051 Compiler und Treiber für LCDs ]

== Sonderzeichen ==
{| class="wikitable"
|-
| \40 ! || \41 " || \42 # || \43 $ || \44 % || \45 & || \50 ( || \51 ) || \52 * || \53 Plus-Zeichen
|-
| \54 Komma || \55 Minus-Zeichen || \56 Punkt || \57 Schrägstrich || \72 Doppelpunkt || \73 Semikolon || \74 < || \75 Gleichheitszeichen || \76 > || \77 ?
|-
| \100 @ || \134 eckige Klammer links || \136 eckige Klammer rechts || \137 accent circonflexe || \138 Unterstrich || \140 accent grave || \173 geschweifte Klammer links || \174 senkrechter Strich || \175 geschweifte Klammer rechts || \176 Pfeil nach rechts
|-
| \177 Pfeil nach links || \260 Minuszeichen || \333 Kastenrahmen || \337 hochgestellter Kastenrahmen(wie Potenz) || \340 gr. alpha || \341 ä || \342 β (als ß brauchbar) || \343 ε klein epsilon || \344 µ || \350 √ Wurzelzeichen
|-
| \351 hoch minus 1 || \353 hoch x || \356 ñ (spanisch) || \357 ö || \363 ∞ Zeichen unendlich || \364 Ohm || \365 ü || \366 Σ gr.Summe || \367 π (klein) || \371 u mit strich rechts unten
|-
| \375 geteilt durch || \377 alle Leuchtpunkte eingeschaltet || || || || || || || ||
|}

Für die 5 Kleinbuchstaben mit Unterlänge 'g', 'j', 'p', 'q' und 'y' stehen mit Offset 80h solche ''mit'' tatsächlicher Unterlänge zur Verfügung.

Im 7-Bit-ASCII-Bereich passen nur die Zeichen '\' (Backslash) und '~' (Tilde) nicht. Zur Wiedergabe portabler ASCII-Daten (typischerweise aus externer Quelle, etwa Dateinamen einer SD-Karte oder SMS-Text) muss man diese beiden Kodepositionen in 2 der 8 möglichen benutzerdefinierten Zeichen transkodieren.

==== Wie nutzt man diese Sonderzeichen in C oder C++? ====

Angegeben sind die ''Oktalnotationen'' der Sonderzeichen. Diese bettet man dreistellig in den String ein: <code>"\3502"</code> ergibt <kbd>√2</kbd> auf der Anzeige und belegt 2 Bytes (mit der terminierenden Null 3 Bytes) im Programm- bzw. Datenspeicher.

Ist diese Notation für häufig benutzte Symbole zu unleserlich oder lästig, nutzt man die compilerseitige Stringkonstanten-Verkettung:
#define WURZEL "\350"
...
emit (WURZEL "2")
// dasselbe wie emit ("\350" "2") und dasselbe wie emit ("\3502")
// Das Leerzeichen zwischen WURZEL und "2" ist nicht erforderlich.

Damit <code>"√2"</code> ''im Programmquelltext'' funktioniert, ist 1. der Quelltext in UTF-8 zu schreiben und 2. eine UTF-8-zu-HD44780-Konvertierroutine zu schreiben. Das kommt allenfalls für größere Mikrocontroller in Frage.

=== Benutzerdefinierte Sonderzeichen ===
* Benutzerspezifische Zeichen für den HD44780 mit dem [http://www.mugui.de/bin/menu.php?link=hd44780_demo&lang=de Font and Bitmap Generator] erstellen
* http://www.parallax.com/ProductInfo/Microcontrollers/BASICStampSoftware/LCDCharacterCreator/tabid/482/Default.aspx

Mit den benutzerdefinierten Sonderzeichen steht für 8 Zeichenpositionen Vollgrafik zur Verfügung,
so dass sich bspw. einfache Signalverläufe in einem 40×8-Pixel-Feld darstellen lassen.

== Siehe auch ==

* [[AVR-GCC-Tutorial/LCD-Ansteuerung]]
* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Forumsbeitrag]: Ermittlung der Startadresse der einzelnen Zeilen
* [https://www.mikrocontroller.net/topic/387596?goto=4438017#4438017 Forumsbeitrag]: HD44780 Extender, transparente Serialisierung der Ansteuerung im 4 oder 8 Bit Modus
* [https://omerk.github.io/lcdchargen/ Custom Character Generator for HD44780 LCD Modules]
* [http://blog.riyas.org/2013/12/online-led-matrix-font-generator-with.html Online led matrix font generator with binary and hex codes for Arduino ]

== Weblinks ==

* [http://www.sprut.de/electronic/lcd/ Ausführliche Beschreibung des HD44780]
* [http://www.peterfleury.epizy.com/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Ansteuern des HD44780 mit den XC8/C18-Libraries - PIC]
* [http://www.fonts2u.com/hd44780-regular.font TTF Matrix Pixel Font]

[[Category:Bauteile]]
[[Category:Displays und Anzeigen]]
[[Category:LCD]]

HD44780

2019-10-30T21:10:17Z

Pfleury: /* Fertige Projekte oder Bibliotheken */

Der HD44780 ist ein Steuer-IC für Textdisplays (siehe [[LCD]]). Praktisch alle Textdisplays werden mit diesem oder einem kompatiblen Controller (z. B. KS0066) angesteuert.

== Allgemeine Ansteuerung ==

=== Pinbelegung ===

Die Pinbelegung des ICs selber ist für den Anwender praktisch uninteressant. Hier ist die häufigste Anschluss-Belegung der damit ausgestatteten LCD-Module angegeben.

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

{| class="wikitable"
!style="width:5%" | Pin || style="width:10%" | Funktion || Beschreibung
|-
|1 || | USS || Bezugspotenzial 0 Volt
|-
|2 || | UCC || Speisespannung + 5 Volt, ≈ 1 mA

|-
|3 || | U0 ||Kontrastspannung, zwischen UCC und USS, typisch 0..1 V, kann auf USS gelegt oder via Potenziometer (Richtwert 10 kΩ) angeschlossen werden. Bei großflächigen LCDs oder LCDs für den erweiterten Temperaturbereich kann auch eine negative Kontrastspannung im Bereich von 0..–5 V nötig sein.
|-
|4 || | RS || Registerauswahl 0 = Befehlsregister, 1 = Datenregister
|-
|5 || | R/W || Lese- oder Schreibzugriff; kann fest auf GND gelegt werden, wenn Busy-Auswertung durch Warten ersetzt wird 0 = Schreiben, 1 = Lesen
|-
|6 || | E || Freigabe- und Taktleitung (Achtung! Diese Leitung hat im Gegensatz zu den anderen bei einigen Displays keinen internen Pullup, man muss also einen externen vorsehen, falls man mit Open-Drain-Ausgängen arbeitet.)
|-
|7 || | DB0 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|8 || |DB1 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|9 || |DB2 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|10 || |DB3 || Datenleitung (bleibt im 4-Bit-Modus offen)
|-
|11 || |DB4 || Datenleitung
|-
|12 || |DB5 || Datenleitung
|-
|13 || |DB6 || Datenleitung
|-
|14 || |DB7 || Datenleitung
|-
|15 || A || Anode der LED-Hintergrundbeleuchtung (fakultativ)
|-
|16 || K || Katode der LED-Hintergrundbeleuchtung (fakultativ)
|-
| || || Es gibt auch Displays ohne die Datenleitungen DB0-3 (werden nur im 4-Bit-Modus angesteuert), dann rutschen die Bezeichnungen dann entsprechend nach unten
|}

===Speicher===

Ein HD44780 besitzt mehrere Speicher. In ihnen wird der Inhalt des Displays sowie das Aussehen von Sonderzeichen gespeichert.

==== CGROM ====

Der '''C'''haracter '''G'''enerator '''ROM''' enthält die Zeichen in Form von 5x8 oder 5x10 Punktmatrizen. Er kann nicht geändert werden, ausser man sendet einen EEPROM zu Hitachi für eine Massenproduktion. Es sind viele verschiedene ROMs (Zeichensätze, engl. Fonts) verfügbar. Er ist für den Anwender nicht zugänglich.

==== CGRAM ====

Im '''C'''haracter '''G'''enerator '''RAM''' können acht 5x8 Pixel oder vier 5x10 Pixel große benutzerdefinierte Zeichen abgelegt werden. Braucht man keine benutzerdefinierten Zeichen, kann man diesen Bereich als Auslagerungsspeicher für den ansteuernden Mikrocontroller benutzen. Dazu muss aber die '''R/W''' Leitung angesteuert werden.

==== DDRAM ====

Im '''D'''isplay '''D'''ata '''RAM''' ist der Inhalt des LCDs gespeichert. Die Kodierung orientiert sich weitestgehend am ASCII Zeichensatz.

Das DDRAM hat üblicherweise mehr Speicherstellen als das Display gleichzeitig anzeigt. Durch Anwenden der Display-Shift-Befehle können die nicht sichtbaren Zeichen zur Anzeige gebracht werden.

Benachbarte Zeichen haben im DDRAM nicht zwangsweise auch aufeinanderfolgende Adressen. So ist etwa bei 1x16-Displays (1 Zeile, 16 Zeichen) oft in der Mitte des Displays ein Adresssprung von 0x07 auf 0x40; bei 2x16-Displays ist der Sprung auf 0x40 normalerweise (programmiererfreundlich) zwischen Ende der ersten und Beginn der zweiten Zeile. Näheres ist dem Datenblatt zu entnehmen.

=== Kommandos ===

{| class="wikitable"
|+ '''HD44780 Befehlssatz'''
!style="width:30%" | Befehl
!RS
!RW
!D7
!D6
!D5
!D4
!D3
!D2
!D1
!D0
|-
|Bildschirminhalt löschen
|0
|0
|0
|0
|0
|0
|0
|0
|0
|1
|-
|Cursor auf Startpos
|0
|0
|0
|0
|0
|0
|0
|0
|1
|X
|-
|Modus festlegen
|0
|0
|0
|0
|0
|0
|0
|1
|I/D
|S
|-
|Display/Cursor
|0
|0
|0
|0
|0
|0
|1
|D
|C
|B
|-
|Cursor/Display schieben
|0
|0
|0
|0
|0
|1
|S/C
|R/L
|X
|X
|-
|Funktionen
|0
|0
|0
|0
|1
|DL
|N
|F
|X
|X
|-
|CGRAM Adresse setzen
|0
|0
|0
|1
|colspan ="6" align="center"|CGRAM-Adresse
|-
|DDRAM Adresse setzen
|0
|0
|1
|colspan="7" align="center"|DDRAM-Adresse
|-
|Adresse/Status lesen
|0
|1
|BF
|colspan="7" align="center"|CG-/DDRAM-Adresse
|-
|Daten in DDRAM/CGRAM schreiben
|1
|0
|colspan="8" align="center"|Daten
|-
|Daten aus DDRAM/CGRAM lesen
|1
|1
|colspan="8" align="center"|Daten
|}

{| class="wikitable"
|+ '''Kodierung der Steuerbits'''
!Bit
!0
!1
|-
|I/D
|Cursorposition dekrementieren
|Cursorposition inkrementieren
|-
|S
|Displayinhalt fest
|Displayinhalt weiterschieben
|-
|D
|Display aus
|Display an
|-
|C
|Cursor aus
|Cursor an
|-
|B
|Cursor blinkt nicht
|Cursor blinkt
|-
|S/C
|Cursor bewegen
|Displayinhalt schieben
|-
|R/L
|Nach links schieben
|Nach rechts schieben
|-
|DL
|4-Bit Interface
|8-Bit Interface
|-
|N
|1-zeiliges Display
|2/4-zeiliges Display
|-
|F
|5×7-Font
|5×10-Font
|-
|BF
|Kann Kommandos annehmen
|Ist beschäftigt
|}

== Ansteuerung per Microcontroller ==

Die Ansteuerung eines HD44780-basierten Displays gestaltet sich sowohl in Bezug auf den Hardware- als auch den Softwareaufwand recht einfach. Sie eignet sich somit sehr gut als Übungsprojekt für Anfänger.

Das HD44780-Interface besteht aus acht Datenleitungen (D0-D7) sowie den drei Steuerleitungen RS ('''R'''egister '''S'''elect), R/W ('''R'''ead/'''W'''rite) und E ('''E'''nable). Die Displays werden mit 5V Betriebsspannung versorgt, die Kontrastspannung V0 bekommt man, indem man ein 10kΩ-[[Potentiometer]] zwischen VCC und GND anschließt und den mittleren Anschluss als Kontrastspannung verwendet. Bei ca. 0,5 Volt werden dann die Pixel sichtbar. Optional haben viele Displays noch eine LED-Beleuchtung eingebaut, diese kann manchmal direkt an 5V angeschlossen werden, da der Vorwiderstand auf der LCD-Platine integriert ist. Oft ist aber auch ein externer Vorwiderstand nötig! Darum vorher besser im Datenblatt nachschauen.

Möchte man IO-Pins am Mikrocontroller sparen, kann das Display im 4-Bit-Modus betrieben werden, die Dateneingänge D0 bis D3 bleiben dann offen. Durch zusätzliche Bauteile ([[AVR-Tutorial:_Schieberegister]]) kann die Zahl der benötigten Port-Pins noch weiter reduziert werden.

Beispielprogramme zur Ansteuerung findet man zuhauf im Internet, u.a. auch hier: [[AVR-Tutorial: LCD]] und [[AVR-GCC-Tutorial/LCD-Ansteuerung|AVR-GCC-Tutorial: LCD-Ansteuerung]]

=== Fertige Projekte oder Bibliotheken ===

* Peter Fleurys [http://www.peterfleury.epizy.com/avr-software.html LCD library for HD44780 based LCDs]
* avr-libc [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Demo-Projekt für stdio]
* [http://www.ipd.uka.de/~buchmann/microcontroller/lcd.htm Grundlagen und Code für 8051] von Erik Buchmann
* [http://www.ekenrooi.net/lcd/lcd.shtml ''How to control a HD44780-based Character-LCD''] von Peter Ouwehand. Beispiele für 8051, PIC16C54, AT90S2313
* Firma wickenhäuser [http://www.wickenhaeuser.de 8051 Compiler und Treiber für LCDs ]

== Sonderzeichen ==
{| class="wikitable"
|-
| \40 ! || \41 " || \42 # || \43 $ || \44 % || \45 & || \50 ( || \51 ) || \52 * || \53 Plus-Zeichen
|-
| \54 Komma || \55 Minus-Zeichen || \56 Punkt || \57 Schrägstrich || \72 Doppelpunkt || \73 Semikolon || \74 < || \75 Gleichheitszeichen || \76 > || \77 ?
|-
| \100 @ || \134 eckige Klammer links || \136 eckige Klammer rechts || \137 accent circonflexe || \138 Unterstrich || \140 accent grave || \173 geschweifte Klammer links || \174 senkrechter Strich || \175 geschweifte Klammer rechts || \176 Pfeil nach rechts
|-
| \177 Pfeil nach links || \260 Minuszeichen || \333 Kastenrahmen || \337 hochgestellter Kastenrahmen(wie Potenz) || \340 gr. alpha || \341 ä || \342 β (als ß brauchbar) || \343 ε klein epsilon || \344 µ || \350 √ Wurzelzeichen
|-
| \351 hoch minus 1 || \353 hoch x || \356 ñ (spanisch) || \357 ö || \363 ∞ Zeichen unendlich || \364 Ohm || \365 ü || \366 Σ gr.Summe || \367 π (klein) || \371 u mit strich rechts unten
|-
| \375 geteilt durch || \377 alle Leuchtpunkte eingeschaltet || || || || || || || ||
|}

Für die 5 Kleinbuchstaben mit Unterlänge 'g', 'j', 'p', 'q' und 'y' stehen mit Offset 80h solche ''mit'' tatsächlicher Unterlänge zur Verfügung.

Im 7-Bit-ASCII-Bereich passen nur die Zeichen '\' (Backslash) und '~' (Tilde) nicht. Zur Wiedergabe portabler ASCII-Daten (typischerweise aus externer Quelle, etwa Dateinamen einer SD-Karte oder SMS-Text) muss man diese beiden Kodepositionen in 2 der 8 möglichen benutzerdefinierten Zeichen transkodieren.

==== Wie nutzt man diese Sonderzeichen in C oder C++? ====

Angegeben sind die ''Oktalnotationen'' der Sonderzeichen. Diese bettet man dreistellig in den String ein: <code>"\3502"</code> ergibt <kbd>√2</kbd> auf der Anzeige und belegt 2 Bytes (mit der terminierenden Null 3 Bytes) im Programm- bzw. Datenspeicher.

Ist diese Notation für häufig benutzte Symbole zu unleserlich oder lästig, nutzt man die compilerseitige Stringkonstanten-Verkettung:
#define WURZEL "\350"
...
emit (WURZEL "2")
// dasselbe wie emit ("\350" "2") und dasselbe wie emit ("\3502")
// Das Leerzeichen zwischen WURZEL und "2" ist nicht erforderlich.

Damit <code>"√2"</code> ''im Programmquelltext'' funktioniert, ist 1. der Quelltext in UTF-8 zu schreiben und 2. eine UTF-8-zu-HD44780-Konvertierroutine zu schreiben. Das kommt allenfalls für größere Mikrocontroller in Frage.

=== Benutzerdefinierte Sonderzeichen ===
* Benutzerspezifische Zeichen für den HD44780 mit dem [http://www.mugui.de/bin/menu.php?link=hd44780_demo&lang=de Font and Bitmap Generator] erstellen
* http://www.parallax.com/ProductInfo/Microcontrollers/BASICStampSoftware/LCDCharacterCreator/tabid/482/Default.aspx

Mit den benutzerdefinierten Sonderzeichen steht für 8 Zeichenpositionen Vollgrafik zur Verfügung,
so dass sich bspw. einfache Signalverläufe in einem 40×8-Pixel-Feld darstellen lassen.

== Siehe auch ==

* [[AVR-GCC-Tutorial/LCD-Ansteuerung]]
* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Forumsbeitrag]: Ermittlung der Startadresse der einzelnen Zeilen
* [https://www.mikrocontroller.net/topic/387596?goto=4438017#4438017 Forumsbeitrag]: HD44780 Extender, transparente Serialisierung der Ansteuerung im 4 oder 8 Bit Modus
* [https://omerk.github.io/lcdchargen/ Custom Character Generator for HD44780 LCD Modules]
* [http://blog.riyas.org/2013/12/online-led-matrix-font-generator-with.html Online led matrix font generator with binary and hex codes for Arduino ]

== Weblinks ==

* [http://www.sprut.de/electronic/lcd/ Ausführliche Beschreibung des HD44780]
* [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Ansteuern des HD44780 mit den XC8/C18-Libraries - PIC]
* [http://www.fonts2u.com/hd44780-regular.font TTF Matrix Pixel Font]

[[Category:Bauteile]]
[[Category:Displays und Anzeigen]]
[[Category:LCD]]

Erweiterte LCD-Ansteuerung

2019-10-30T21:09:15Z

Pfleury: /* Weblinks */

== Einleitung ==

Die folgende Software beruht zum größten Teil auf dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|Tutorial zur LCD-Ansteuerung]]. Eine Anpassung war jedoch nötig, weil in der Tutorial-Vorlage die vier LCD-Datenleitungen DB4 bis DB7 immer mit den unteren vier Portleitungen PIN0 bis PIN3 des Ausgabeports verbunden sein müssen. Die hier vorgestellte Lösung ermöglicht es, die als Datenleitung verwendeten Pins innerhalb des Ausgabeports freier zu konfigurieren. D.h.

* Die vier Datenleitungen können als Bus beliebig an einem Port gelegt werden
* Allerdings muss die Reihenfolge immer noch eingehalten werden, sprich, DB4-DB7 in aufsteigender Reihenfolge!
* Die beiden anderen Steuersignale ''E'' und ''RS'' sind auf den übrigen vier Pins eines Ports frei wählbar
* Das Signal ''RW'' muss am LCD fest auf GND gelegt sein, es werden nur Schreibzugriffe ausgeführt
* Das Busy-Flag wird '''nicht''' genutzt
* Wer die ultimativ freie Zuordnung von Pins über Portgrenzen hinweg haben will, muss die bekannte Bibliothek von Peter Fleury nutzen, siehe Links am Ende des Artikels

Ansonsten sind einige [[Strukturierte Programmierung auf Mikrocontrollern|kosmetische Änderungen]] gemacht worden, die den Code etwas leichter lesbar machen sollen. So sind sämtliche Kommandos und Kommandooptionen als #defines ausgeführt. Gegenüber dem Original sind folgende Änderungen bzw. Erweiterungen gemacht worden:

* konfigurierbare Datenleitungen, z.B. zum Anschluss von DB4-DB7 an PD4-PD7
* Funktionsname lcd_setcursor() statt set_cursor() (einheitliche Namenskonvention)
* einheitliche Verwendung von uint8_t
* neue Funktion lcd_out() für eine 4bit-Operation
* alle Kommandos und Kommandooptionen des LCD als #defines ausgeführt
* neue Funktion lcd_generatechar() und lcd_generatechar_P() zum [[Pseudo-Graphische_LCD-Ansteuerung|Generieren eines Zeichens im Character Generator RAM]]
* ein Demoprogramm, in dem alle Funktionen der Bibliotek in ihrer Nutzung dargestellt sind

Alle Dateien sind als [[media:LCD_Tutorial.zip | ZIP-Archiv]] hier verfügbar. Das Programm wurde komplett auf einem ATmega8515 getestet. Es ist auf ein 4x16 LCD ausgelegt. Wenn man das Programm auf seiner eigenen Hardware testen will, müssen folgende Dinge angepasst werden

* in main.h das #define F_CPU für die Taktfrequenz
* in lcd.h die Port- und Pinzuordnung mit LCD_PORT, LCD_DDR etc.

Der Quelltext ist ausgiebig kommentiert und sollte die Funktionen gut erklären.

== Die erweiterten LCD-Routinen ==

Datei '''lcd.h'''
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//

#ifndef LCD_ROUTINES_H
#define LCD_ROUTINES_H

#include <avr/pgmspace.h>

////////////////////////////////////////////////////////////////////////////////
// Pinbelegung für das LCD, an verwendete Pins anpassen
// alle Pins müssen in einem Port liegen
// die 4 Bit für die Daten müssen zusammenliegen, können aber an einer
// beliebigen Postion anfangen

#ifndef LCD_PORTS
#define LCD_PORTS

#define LCD_PORT PORTC
#define LCD_DDR DDRC

// 4 Bit LCD Datenbus DB4-DB7, das unterste Bit DB4 kann auf den Portbits 0..4 liegen

// LCD DB4-DB7 <--> PORTC Bit PC0-PC3
#define LCD_DB PC0

// LCD Steuersignale RS und EN

// LCD RS <--> PORTC Bit PC4 (RS: 0=Data, 1=Command)
#define LCD_RS PC4

// LCD EN <--> PORTC Bit PC5 (EN: 1-Impuls für Daten)
#define LCD_EN PC5

#endif // LCD_PORTS

////////////////////////////////////////////////////////////////////////////////
// LCD Ausführungszeiten (MS=Millisekunden, US=Mikrosekunden)

#ifndef LCD_TIMINGS
#define LCD_TIMINGS

#define LCD_BOOTUP_MS 15
#define LCD_ENABLE_US 1
#define LCD_WRITEDATA_US 46
#define LCD_COMMAND_US 42

#define LCD_SOFT_RESET_MS1 5
#define LCD_SOFT_RESET_MS2 1
#define LCD_SOFT_RESET_MS3 1
#define LCD_SET_4BITMODE_MS 5

#define LCD_CLEAR_DISPLAY_MS 2
#define LCD_CURSOR_HOME_MS 2

#endif // LCD_TIMINGS

////////////////////////////////////////////////////////////////////////////////
// Zeilendefinitionen des verwendeten LCD
// die Einträge hier sollten für ein LCD mit einer Zeilenlänge von 16 Zeichen passen
// bei anderen Zeilenlängen müssen diese Einträge angepasst werden

#define LCD_DDADR_LINE1 0x00
#define LCD_DDADR_LINE2 0x40
#define LCD_DDADR_LINE3 0x10
#define LCD_DDADR_LINE4 0x50

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void );

////////////////////////////////////////////////////////////////////////////////
// LCD löschen
void lcd_clear( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor in die erste Zeile, erste Spalte (Position 0,0)
void lcd_home( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor an eine beliebige Position
void lcd_setcursor( uint8_t x, uint8_t y );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines einzelnen Zeichens an der aktuellen Cursorposition
void lcd_data( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an der aktuellen Cursorposition
// String liegt im RAM
void lcd_string( const char *data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an einer bestimmten Cursorposition
// String liegt im RAM
void lcd_string_xy( uint8_t x, uint8_t y, const char *data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe einer Zahl an der aktuellen Cursorposition
// Zahl liegt im RAM
void lcd_number( uint8_t number, uint8_t len, uint8_t fill );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe einer Zahl an einer bestimmten Cursorposition
// Zahl liegt im RAM
void lcd_number_xy( uint8_t x, uint8_t y, uint8_t number, uint8_t len, uint8_t fill );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an der aktuellen Cursorposition
// String liegt im Flash
void lcd_string_P( PGM_P data );

////////////////////////////////////////////////////////////////////////////////
// Definition eines benutzerdefinierten Sonderzeichens.
// data muss auf ein Array mit den Zeilencodes des zu definierenden Zeichens
// zeigen, Daten liegen im RAM
void lcd_generatechar( uint8_t code, const uint8_t *data, uint8_t lines );

////////////////////////////////////////////////////////////////////////////////
// Definition eines benutzerdefinierten Sonderzeichens.
// data muss auf ein Array mit den Zeilencodes des zu definierenden Zeichens
// zeigen, Daten liegen im FLASH
void lcd_generatechar_P( uint8_t code, PGM_P data, uint8_t lines );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Kommandos an das LCD.
void lcd_command( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// LCD Befehle und Argumente.
// zur Verwendung in lcd_command

// Clear Display -------------- 0b00000001
#define LCD_CLEAR_DISPLAY 0x01

// Cursor Home ---------------- 0b0000001x
#define LCD_CURSOR_HOME 0x02

// Set Entry Mode ------------- 0b000001xx
#define LCD_SET_ENTRY 0x04

#define LCD_ENTRY_DECREASE 0x00
#define LCD_ENTRY_INCREASE 0x02
#define LCD_ENTRY_NOSHIFT 0x00
#define LCD_ENTRY_SHIFT 0x01

// Set Display ---------------- 0b00001xxx
#define LCD_SET_DISPLAY 0x08

#define LCD_DISPLAY_OFF 0x00
#define LCD_DISPLAY_ON 0x04
#define LCD_CURSOR_OFF 0x00
#define LCD_CURSOR_ON 0x02
#define LCD_BLINKING_OFF 0x00
#define LCD_BLINKING_ON 0x01

// Set Shift ------------------ 0b0001xxxx
#define LCD_SET_SHIFT 0x10

#define LCD_CURSOR_MOVE 0x00
#define LCD_DISPLAY_SHIFT 0x08
#define LCD_SHIFT_LEFT 0x00
#define LCD_SHIFT_RIGHT 0x01

// Set Function --------------- 0b001xxxxx
#define LCD_SET_FUNCTION 0x20

#define LCD_FUNCTION_4BIT 0x00
#define LCD_FUNCTION_8BIT 0x10
#define LCD_FUNCTION_1LINE 0x00
#define LCD_FUNCTION_2LINE 0x08
#define LCD_FUNCTION_5X7 0x00
#define LCD_FUNCTION_5X10 0x04

#define LCD_SOFT_RESET 0x30

// Set CG RAM Address --------- 0b01xxxxxx (Character Generator RAM)
#define LCD_SET_CGADR 0x40

#define LCD_GC_CHAR0 0
#define LCD_GC_CHAR1 1
#define LCD_GC_CHAR2 2
#define LCD_GC_CHAR3 3
#define LCD_GC_CHAR4 4
#define LCD_GC_CHAR5 5
#define LCD_GC_CHAR6 6
#define LCD_GC_CHAR7 7

// Set DD RAM Address --------- 0b1xxxxxxx (Display Data RAM)
#define LCD_SET_DDADR 0x80

#endif // LCD_ROUTINES_H
</syntaxhighlight>

Datei '''lcd.c'''
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/HD44780
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//
// Die Pinbelegung ist über defines in lcd.h einstellbar

#include <avr/io.h>
#include "main.h"
#include "lcd.h"
#include <util/delay.h>

/////////////////////////////////////////////////////////////////////////////////
// Erzeugt einen Enable-Puls

static void lcd_enable( void ) {
LCD_PORT |= (1<<LCD_EN); // Enable auf 1 setzen
_delay_us( LCD_ENABLE_US ); // kurze Pause
LCD_PORT &= ~(1<<LCD_EN); // Enable auf 0 setzen
}

////////////////////////////////////////////////////////////////////////////////
// Sendet eine 4-bit Ausgabeoperation an das LCD
static void lcd_out( uint8_t data ) {
data &= 0xF0; // obere 4 Bit maskieren
LCD_PORT &= ~(0xF0>>(4-LCD_DB)); // Maske löschen
LCD_PORT |= (data>>(4-LCD_DB)); // Bits setzen
lcd_enable();
}

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void ) {
// verwendete Pins auf Ausgang schalten
uint8_t pins = (0x0F << LCD_DB) | // 4 Datenleitungen
(1<<LCD_RS) | // R/S Leitung
(1<<LCD_EN); // Enable Leitung
LCD_DDR |= pins;

// initial alle Ausgänge auf Null
LCD_PORT &= ~pins;

// warten auf die Bereitschaft des LCD
_delay_ms( LCD_BOOTUP_MS );

// Soft-Reset muss 3mal hintereinander gesendet werden zur Initialisierung
lcd_out( LCD_SOFT_RESET );
_delay_ms( LCD_SOFT_RESET_MS1 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS2 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS3 );

// 4-bit Modus aktivieren
lcd_out( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT );
_delay_ms( LCD_SET_4BITMODE_MS );

// 4-bit Modus / 2 Zeilen / 5x7
lcd_command( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT |
LCD_FUNCTION_2LINE |
LCD_FUNCTION_5X7 );

// Display ein / Cursor aus / Blinken aus
lcd_command(LCD_SET_DISPLAY |
LCD_DISPLAY_ON |
LCD_CURSOR_OFF |
LCD_BLINKING_OFF);

// Cursor inkrement / kein Scrollen
lcd_command( LCD_SET_ENTRY |
LCD_ENTRY_INCREASE |
LCD_ENTRY_NOSHIFT );

lcd_clear();
}

////////////////////////////////////////////////////////////////////////////////
// Sendet ein Datenbyte an das LCD
void lcd_data( uint8_t data ) {
LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_WRITEDATA_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet einen Befehl an das LCD
void lcd_command( uint8_t data ) {
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4); // dann die unteren 4 Bit senden

_delay_us(LCD_COMMAND_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl zur Löschung des Displays
void lcd_clear( void ) {
lcd_command( LCD_CLEAR_DISPLAY );
_delay_ms( LCD_CLEAR_DISPLAY_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl: Cursor Home
void lcd_home( void ) {
lcd_command( LCD_CURSOR_HOME );
_delay_ms( LCD_CURSOR_HOME_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Setzt den Cursor in Zeile y (0..3) Spalte x (0..15)

void lcd_setcursor( uint8_t x, uint8_t y ) {
uint8_t data;

switch (y) {
case 0: // 1. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;
break;
case 1: // 2. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;
break;
case 2: // 3. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE3 + x;
break;
case 3: // 4. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE4 + x;
break;
default:
return; // für den Fall einer falschen Zeile
}

lcd_command( data );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt einen String auf das LCD

void lcd_string( const char *data ) {
while( *data != '\0' )
lcd_data( *data++ );
}

void lcd_string_xy( uint8_t x, uint8_t y, const char *data ) {
lcd_setcursor( x, y );
lcd_string( data );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt eine Zahl auf das LCD

void lcd_number( uint8_t number, uint8_t len, uint8_t fill ) {
uint8_t digit1 = 0;
uint8_t digit2 = 0;
while (number >= 100) {
digit1++;
number -= 100;
}
while (number >= 10) {
digit2++;
number -= 10;
}
if (len > 2) lcd_data( (digit1 != 0) ? digit1+'0' : fill );
if (len > 1) lcd_data( ((digit1 != 0) || (digit2 != 0)) ? digit2+'0' : fill );
lcd_data( number+'0' );
}

void lcd_number_xy( uint8_t x, uint8_t y, uint8_t number, uint8_t len, uint8_t fill ) {
lcd_setcursor( x, y );
lcd_number( number, len, fill );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt einen String auf das LCD
// String liegt direkt im Flash Speicher

void lcd_string_P( PGM_P data ) {
uint8_t tmp;

tmp = pgm_read_byte( data );
while( tmp != '\0' ) {
lcd_data( tmp );
data++;
tmp = pgm_read_byte( data );
}
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt ein Zeichen in den Character Generator RAM
// Daten liegen direkt im RAM

void lcd_generatechar( uint8_t code, const uint8_t *data, uint8_t lines ) {
uint8_t i;

// Startposition des Zeichens einstellen
lcd_command( LCD_SET_CGADR | (code<<3) );
// Bitmuster übertragen
for ( i=0; i<lines; i++ ) {
lcd_data( *data++ );
}
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt ein Zeichen in den Character Generator RAM
// Daten liegen direkt im Flash-Speicher

void lcd_generatechar_P( uint8_t code, PGM_P data, uint8_t lines ) {
uint8_t i;

// Startposition des Zeichens einstellen
lcd_command( LCD_SET_CGADR | (code<<3) );
// Bitmuster übertragen
for ( i=0; i<lines; i++ ) {
lcd_data( pgm_read_byte(data) );
data++;
}
}
</syntaxhighlight>

== Weblinks ==

* [http://www.peterfleury.epizy.com/avr-software.html#libs Sehr flexible Bibliothek zur HD44780 Ansteuerung (AVR)] (P. Fleury)
* [http://www.mikrocontroller.net/topic/316826#3431235 Ermittlung der Startadresse der einzelnen Zeilen]
* [http://pic-projekte.de/wordpress/?p=908 Lib zur Ansteuerung des HD44780 (PIC)]

[[Kategorie:LCD]]

AVR Bootloader in C - eine einfache Anleitung

2019-10-30T21:03:26Z

Pfleury: /* Schritt 2 - Einbinden der UART Library von Peter Fleury */

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://homepage.hispeed.ch/peterfleury/avr-software.html 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ändnis 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 besonderen 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 entspricht 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://www.peterfleury.epizy.com/avr-software.html UART-Library] von [http://www.peterfleury.epizy.com 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:

'''Achtung! Bitte unbedingt die Bezeichnung des SFRs für das Umschalten der Interruptvektoren beachten: bei Atmega88: MCUCR, bei Atmega8: GICR (s. auch etwas weiter unten)'''

<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 wie 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'' kennzeichnet 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 vom 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>

== Fehler bei Flash > 64k ==
Neuere avr-gcc optimieren den oben beschriebenen Bootloader mit so genannten "table jumps". Darin verwendet der Compiler LPM Instruktionen. Laut dem "AVR Instruction Set" kann dieser Befehl aber nur für Adressen bis 64k verwendet werden. Liegt nun der Bootloader am Ende eines 128k Flashs kann dies zum Absturz resp. Neustart des Controllers führen. Abhilfe schafft z.B. die Optimierungsoption "-fno-jump-tables".

= 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]]

AVR-GCC-Tutorial/LCD-Ansteuerung

2019-10-30T20:59:11Z

Pfleury: /* Weblinks */

==Das LCD und sein Controller==

Die meisten Text-LCDs verwenden den Controller [[HD44780]] oder einen kompatiblen (z. B. KS0070) und haben 14 oder 16 Pins. Hier ist die häufigste Anschluss-Belegung angegeben.

;Achtung: Es gibt Displays mit abweichender Anschluss-Belegung, z.B. TC1602E (Pollin 120420). Falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen. Einzelheiten unter Artikel zum Controller [[HD44780]].

{| class="wikitable"
! Pin # || Bezeichnung || Funktion
|-
! 1
| Vss || GND (beim TC1602E Vdd=Vcc)
|-
! 2
| Vdd/Vcc || 5V (beim TC1602E Vss=Gnd)
|-
! 3
| Vee || Kontrastspannung (0V bis 5V)
|-
! 4
| RS || Register Select (Befehle/Daten)
|-
! 5
| RW || Read/Write
|-
! 6
| E
| Enable
|-
! 7
| DB0 ||rowspan="8"| Datenbits 0−7
|-
! 8
| DB1
|-
! 9
| DB2
|-
! 10
| DB3
|-
! 11
| DB4
|-
! 12
| DB5
|-
! 13
| DB6
|-
! 14
| DB7
|-
! 15
| A || LED-Beleuchtung, Anode
|-
! 16
| K || LED-Beleuchtung, Kathode
|}

{{Warnung|
;Achtung: Unbedingt von der richtigen Seite zu zählen anfangen! Meistens ist neben Pin 1 eine kleine 1 auf der LCD-Platine. Ansonsten im Datenblatt nachschauen! Oft ist Pin 1 auch durch ein rechteckiges statt rundes Pad gekennzeichnet.

:Bei LCDs mit 16-poligem Anschluss sind die beiden letzten Pins für die Hintergrundbeleuchtung reserviert. Hier unbedingt das Datenblatt zu Rate ziehen, die beiden Anschlüsse sind je nach Hersteller oft anders beschaltet. Falls kein Datenblatt vorliegt, kann man mit einem Durchgangsprüfer feststellen, welcher Anschluss mit Masse (GND) verbunden ist.
}}

Vss wird ganz einfach an GND angeschlossen und Vcc an 5V. Vee kann man testweise auch an GND legen. Wenn das LCD dann zu dunkel sein sollte muss man ein 10k-Potentiometer zwischen GND und 5V schalten, mit dem Schleifer an Vee:

[[Bild:LCD_Vee.gif]]

Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.
* Für den '''8-bit-Modus''' werden (wie der Name schon sagt) alle acht Datenleitungen zur Ansteuerung verwendet, somit kann durch einen Zugriff immer ein ganzes Byte übertragen werden.
* Der '''4-bit-Modus''' verwendet nur die oberen vier Datenleitungen ('''DB4-DB7'''). Um ein Byte zu übertragen braucht man somit zwei Zugriffe, wobei zuerst das höherwertige '''"Nibble"''' (= 4 Bits), also Bit 4 bis Bit 7 übertragen wird und dann das niederwertige, also Bit 0 bis Bit 3. Die unteren Datenleitungen des LCDs, die beim Lesezyklus Ausgänge sind, lässt man offen (siehe Datasheets, z. B. vom KS0070).

Der 4-bit-Modus hat den Vorteil, dass man 4 IO-Pins weniger benötigt als beim 8-bit-Modus, weshalb ich mich hier für eine Ansteuerung mit 4bit entschieden habe.

Neben den vier Datenleitungen (DB4, DB5, DB6 und DB7) werden noch die Anschlüsse '''RS''', '''RW''' und '''E''' (ist in manchen Unterlagen auch '''EN''' für ''Enable'' abgekürzt) benötigt.

* Über '''RS''' wird ausgewählt, ob man einen Befehl oder ein Datenbyte an das LCD schicken möchte. Ist RS Low, dann wird das ankommende Byte als Befehl interpretiert, ist RS high, dann wird das Byte auf dem LCD angezeigt.
* '''RW''' legt fest, ob geschrieben oder gelesen werden soll. High bedeutet lesen, low bedeutet schreiben. Wenn man RW auf lesen einstellt und RS auf Befehl, dann kann man das '''Busy-Flag''' an DB7 lesen, das anzeigt, ob das LCD den vorhergehenden Befehl fertig verarbeitetet hat (diese Methode u.a. in der LCD-Library von Peter Fleury verwendet). Ist RS auf Daten eingestellt, dann kann man z. B. den Inhalt des Displays lesen - was jedoch nur in den wenigsten Fällen Sinn macht. Deshalb kann man RW dauerhaft auf low lassen (= an GND anschließen), so dass man noch ein IO-Pin am Controller einspart. Der Nachteil ist, dass man dann das Busy-Flag nicht lesen kann, weswegen man nach jedem Befehl vorsichtshalber ein paar Mikrosekunden warten sollte, um dem LCD Zeit zum Ausführen des Befehls zu geben. Dummerweise schwankt die Ausführungszeit von Display zu Display und ist auch von der Betriebsspannung abhängig. Für professionellere Sachen also lieber den IO-Pin opfern und Busy abfragen.
* Der '''E''' Anschluss schließlich signalisiert dem LCD, dass die übrigen Datenleitungen jetzt korrekte Pegel angenommen haben und es die gewünschten Daten von den Datenleitungen bzw. Kommandos von den Datenleitungen übernehmen kann.

== Anschluss an den Controller ==

Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden:

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

Einzelheiten unter [http://www.mikrocontroller.net/articles/HD44780 Artikel zum Controller HD44780]

{| class="wikitable"
!Pin #-LCD || Bezeichnung-LCD || Pin-µC
|-
!1
| Vss || GND
|-
!2
| Vcc || 5V
|-
!3
| Vee || GND oder Poti (siehe oben)
|-
!4
| RS || PD4 am AVR
|-
!5
| RW || GND
|-
!6
| E || PD5 am AVR
|-
!7
| DB0 ||rowspan="4"| offen (unbenutzt)
|-
!8
| DB1
|-
!9
| DB2
|-
!10
| DB3
|-
!11
| DB4 || PD0 am AVR
|-
!12
| DB5 || PD1 am AVR
|-
!13
| DB6 || PD2 am AVR
|-
!14
| DB7 || PD3 am AVR
|}

Wenn man die Steuerleitungen EN und RS auf Pins an einem anderen Port legen möchte, kann man so wie in diesem [http://www.mikrocontroller.net/topic/88543#751982 Forumsbeitrag] oder wie im Artikel [[Erweiterte LCD-Ansteuerung]] vorgehen.

Ok, alles ist verbunden, wenn man jetzt den Strom einschaltet sollten ein oder zwei schwarze Balken auf dem Display angezeigt werden. Erscheint trotz korrektem Anschluss nichts auf dem Display, so kann das auch am Kontrast des LCDs liegen. Die Balken werden dann zwar theoretisch angezeigt, sind aber nicht sichtbar, weil die Kontrastspannung zu hoch ist. Abhilfe schafft es hier, wenn man die Spannung am Schleifer des Potis nachmisst und in Richtung 0V verstellt. Zwischen 1V und 0V treten die Balken dann meist hervor.
Doch wie bekommt man jetzt die Befehle und Daten in das Display?

== Programmierung ==

=== Die LCD Routinen ===

Der folgende Satz von Ansteuerroutinen für ein Text-LCD ist in der Datei '''lcd-routines.c''' zusammengefasst. Diese Datei muss man beim Einrichten zusätzlich zum eigenen Hauptprogramm in sein Projekt aufnehmen. Dies geschieht beim AVR Studio unter Source Files im Fenster AVR GCC oder bei WinAVR im Makefile (z. B. durch SRC += lcd-routines.c).

Wichtig ist außerdem, dass die Optimierung bei der Compilierung eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us() und _delay_ms() nicht und der Code wird wesentlich länger (Siehe Dokumentation der libc im WinAVR).

Als weitere Datei ist die Includedatei '''lcd-routines.h''' notwendig, die im Hauptprogramm und in '''lcd-routines.c''' eingebunden wird. Die Anpassung der Pinbelegung etc. macht man in dieser Datei.

==== Datei '''lcd-routines.h''' ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//

#ifndef LCD_ROUTINES_H
#define LCD_ROUTINES_H

////////////////////////////////////////////////////////////////////////////////
// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

#ifndef F_CPU
#define F_CPU 8000000
#endif

////////////////////////////////////////////////////////////////////////////////
// Pinbelegung für das LCD, an verwendete Pins anpassen
// Alle LCD Pins müssen an einem Port angeschlossen sein und die 4
// Datenleitungen müssen auf aufeinanderfolgenden Pins liegen

// LCD DB4-DB7 <--> PORTD Bit PD0-PD3
#define LCD_PORT PORTD
#define LCD_DDR DDRD
#define LCD_DB PD0

// LCD RS <--> PORTD Bit PD4 (RS: 1=Data, 0=Command)
#define LCD_RS PD4

// LCD EN <--> PORTD Bit PD5 (EN: 1-Impuls für Daten)
#define LCD_EN PD5

////////////////////////////////////////////////////////////////////////////////
// LCD Ausführungszeiten (MS=Millisekunden, US=Mikrosekunden)

#define LCD_BOOTUP_MS 15
#define LCD_ENABLE_US 20
#define LCD_WRITEDATA_US 46
#define LCD_COMMAND_US 42

#define LCD_SOFT_RESET_MS1 5
#define LCD_SOFT_RESET_MS2 1
#define LCD_SOFT_RESET_MS3 1
#define LCD_SET_4BITMODE_MS 5

#define LCD_CLEAR_DISPLAY_MS 2
#define LCD_CURSOR_HOME_MS 2

////////////////////////////////////////////////////////////////////////////////
// Zeilendefinitionen des verwendeten LCD
// Die Einträge hier sollten für ein LCD mit einer Zeilenlänge von 16 Zeichen passen
// Bei anderen Zeilenlängen müssen diese Einträge angepasst werden

#define LCD_DDADR_LINE1 0x00
#define LCD_DDADR_LINE2 0x40
#define LCD_DDADR_LINE3 0x10
#define LCD_DDADR_LINE4 0x50

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void );

////////////////////////////////////////////////////////////////////////////////
// LCD löschen
void lcd_clear( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor in die 1. Zeile, 0-te Spalte
void lcd_home( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor an eine beliebige Position
void lcd_setcursor( uint8_t spalte, uint8_t zeile );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines einzelnen Zeichens an der aktuellen Cursorposition
void lcd_data( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an der aktuellen Cursorposition
void lcd_string( const char *data );

////////////////////////////////////////////////////////////////////////////////
// Definition eines benutzerdefinierten Sonderzeichens.
// data muss auf ein Array[8] mit den Zeilencodes des zu definierenden Zeichens
// zeigen. Später können diese mit lcd_data(0-7) aufgerufen werden
void lcd_generatechar( uint8_t startadresse, const uint8_t *data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Kommandos an das LCD.
void lcd_command( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// LCD Befehle und Argumente.
// Zur Verwendung in lcd_command

// Clear Display -------------- 0b00000001
#define LCD_CLEAR_DISPLAY 0x01

// Cursor Home ---------------- 0b0000001x
#define LCD_CURSOR_HOME 0x02

// Set Entry Mode ------------- 0b000001xx
#define LCD_SET_ENTRY 0x04

#define LCD_ENTRY_DECREASE 0x00
#define LCD_ENTRY_INCREASE 0x02
#define LCD_ENTRY_NOSHIFT 0x00
#define LCD_ENTRY_SHIFT 0x01

// Set Display ---------------- 0b00001xxx
#define LCD_SET_DISPLAY 0x08

#define LCD_DISPLAY_OFF 0x00
#define LCD_DISPLAY_ON 0x04
#define LCD_CURSOR_OFF 0x00
#define LCD_CURSOR_ON 0x02
#define LCD_BLINKING_OFF 0x00
#define LCD_BLINKING_ON 0x01

// Set Shift ------------------ 0b0001xxxx
#define LCD_SET_SHIFT 0x10

#define LCD_CURSOR_MOVE 0x00
#define LCD_DISPLAY_SHIFT 0x08
#define LCD_SHIFT_LEFT 0x00
#define LCD_SHIFT_RIGHT 0x04

// Set Function --------------- 0b001xxxxx
#define LCD_SET_FUNCTION 0x20

#define LCD_FUNCTION_4BIT 0x00
#define LCD_FUNCTION_8BIT 0x10
#define LCD_FUNCTION_1LINE 0x00
#define LCD_FUNCTION_2LINE 0x08
#define LCD_FUNCTION_5X7 0x00
#define LCD_FUNCTION_5X10 0x04

#define LCD_SOFT_RESET 0x30

// Set CG RAM Address --------- 0b01xxxxxx (Character Generator RAM)
#define LCD_SET_CGADR 0x40

#define LCD_GC_CHAR0 0
#define LCD_GC_CHAR1 1
#define LCD_GC_CHAR2 2
#define LCD_GC_CHAR3 3
#define LCD_GC_CHAR4 4
#define LCD_GC_CHAR5 5
#define LCD_GC_CHAR6 6
#define LCD_GC_CHAR7 7

// Set DD RAM Address --------- 0b1xxxxxxx (Display Data RAM)
#define LCD_SET_DDADR 0x80

#endif
</syntaxhighlight>

==== Datei '''lcd-routines.c''': ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/HD44780
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar

#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>

////////////////////////////////////////////////////////////////////////////////
// Erzeugt einen Enable-Puls
static void lcd_enable( void )
{
LCD_PORT |= (1<<LCD_EN); // Enable auf 1 setzen
_delay_us( LCD_ENABLE_US ); // kurze Pause
LCD_PORT &= ~(1<<LCD_EN); // Enable auf 0 setzen
}

////////////////////////////////////////////////////////////////////////////////
// Sendet eine 4-bit Ausgabeoperation an das LCD
static void lcd_out( uint8_t data )
{
data &= 0xF0; // obere 4 Bit maskieren

LCD_PORT &= ~(0xF0>>(4-LCD_DB)); // Maske löschen
LCD_PORT |= (data>>(4-LCD_DB)); // Bits setzen
lcd_enable();
}

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void )
{
// verwendete Pins auf Ausgang schalten
uint8_t pins = (0x0F << LCD_DB) | // 4 Datenleitungen
(1<<LCD_RS) | // R/S Leitung
(1<<LCD_EN); // Enable Leitung
LCD_DDR |= pins;

// initial alle Ausgänge auf Null
LCD_PORT &= ~pins;

// warten auf die Bereitschaft des LCD
_delay_ms( LCD_BOOTUP_MS );

// Soft-Reset muss 3mal hintereinander gesendet werden zur Initialisierung
lcd_out( LCD_SOFT_RESET );
_delay_ms( LCD_SOFT_RESET_MS1 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS2 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS3 );

// 4-bit Modus aktivieren
lcd_out( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT );
_delay_ms( LCD_SET_4BITMODE_MS );

// 4-bit Modus / 2 Zeilen / 5x7
lcd_command( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT |
LCD_FUNCTION_2LINE |
LCD_FUNCTION_5X7 );

// Display ein / Cursor aus / Blinken aus
lcd_command( LCD_SET_DISPLAY |
LCD_DISPLAY_ON |
LCD_CURSOR_OFF |
LCD_BLINKING_OFF);

// Cursor inkrement / kein Scrollen
lcd_command( LCD_SET_ENTRY |
LCD_ENTRY_INCREASE |
LCD_ENTRY_NOSHIFT );

lcd_clear();
}

////////////////////////////////////////////////////////////////////////////////
// Sendet ein Datenbyte an das LCD
void lcd_data( uint8_t data )
{
LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_WRITEDATA_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet einen Befehl an das LCD
void lcd_command( uint8_t data )
{
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_COMMAND_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl zur Löschung des Displays
void lcd_clear( void )
{
lcd_command( LCD_CLEAR_DISPLAY );
_delay_ms( LCD_CLEAR_DISPLAY_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl: Cursor Home
void lcd_home( void )
{
lcd_command( LCD_CURSOR_HOME );
_delay_ms( LCD_CURSOR_HOME_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Setzt den Cursor in Spalte x (0..15) Zeile y (1..4)

void lcd_setcursor( uint8_t x, uint8_t y )
{
uint8_t data;

switch (y)
{
case 1: // 1. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;
break;

case 2: // 2. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;
break;

case 3: // 3. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE3 + x;
break;

case 4: // 4. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE4 + x;
break;

default:
return; // für den Fall einer falschen Zeile
}

lcd_command( data );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt einen String auf das LCD

void lcd_string( const char *data )
{
while( *data != '\0' )
lcd_data( *data++ );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt ein Zeichen in den Character Generator RAM

void lcd_generatechar( uint8_t startadresse, const uint8_t *data )
{
// Startposition des Zeichens einstellen
lcd_command( LCD_SET_CGADR | (startadresse<<3) ); //Startadressen: 0;1;2;3;4;5;6;7

// Bitmuster übertragen
for ( uint8_t i=0; i<8; i++ )
{
lcd_data( data[i] );
}
lcd_command(LCD_SET_DDADR); //DRAM auf 0 setzen
}
</syntaxhighlight>

=== LCD Beispiel 1 ===
Ein Hauptprogramm, welches die LCD Funktionen benutzt, sieht zb. so aus:

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"

int main(void)
{
// Initialisierung des LCD
// Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
// verschwunden sein
lcd_init();

// Text in einzelnen Zeichen ausgeben
lcd_data( 'T' );
lcd_data( 'e' );
lcd_data( 's' );
lcd_data( 't' );

// Die Ausgabemarke in die 2te Zeile setzen
lcd_setcursor( 0, 2 );

// erneut Text ausgeben, aber diesmal komfortabler als String
lcd_string("Hello World!");

while(1)
{
}

return 0;
}
</syntaxhighlight>

=== LCD Beispiel 2 ===
Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.
Mittels der itoa() Funktion (itoa = Integer To Ascii ) wird von einem Zahlenwert eine textuelle Repräsentierung ermittelt (sprich: ein String erzeugt) und dieser String mit der bereits vorhandenen Funktion lcd_string ausgegeben. Das Einrichten des Projekts ist wie in Beispiel 1.

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include <stdlib.h>
#include "lcd-routines.h"

// Beispiel
int variable = 42;

int main(void)
{
lcd_init();

// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)
// http://www.code-knacker.de/ascii.htm
lcd_data( variable );

lcd_setcursor( 0, 2 );

// Ausgabe der Variable als Text in dezimaler Schreibweise
{
// ... umwandeln siehe FAQ Artikel bei http://www.mikrocontroller.net/articles/FAQ
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h>
char Buffer[20]; // in diesem {} lokal
itoa( variable, Buffer, 10 );

// ... ausgeben
lcd_string( Buffer );
}

while(1)
{
}

return 0;
}
</syntaxhighlight>

== Siehe auch ==

* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Ermittlung der Startadresse der einzelnen Zeilen]
* [http://www.mikrocontroller.net/topic/350554#3899961 LCD-Ansteuerung mit freier Wahl von Pins und Portregistern am Controller]

== Weblinks ==

* [http://www.peterfleury.epizy.com/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Lib zur HD44780 Ansteuerung (PIC)]
* [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Using the standard IO facilities] - Demoprojekt zur Text-LCD Ansteuerung (HD44780 komp.) in der avr-libc

[[Kategorie:Avr-gcc Tutorial]]
[[Kategorie:LCD]]

AVR TWI

2019-10-30T20:57:36Z

Pfleury: /* Bibliotheken */

''von Alexander Starke''

== Grundlagen ==

Das TWI (Two Wire Interface), ursprünglich von Philips als [[I2C]] bezeichnet, ist begründet durch seinen Aufbau ideal auf typische Mikrocontroller-Anwendungen zugeschnitten. Durch seinen 7 Bit breiten Adressraum können bis zu 128 (27 = 128) Geräte miteinander verschaltet werden. Im Gegensatz zum SPI ([[Serial Peripheral Interface]]) werden nur zwei Busleitungen benötigt. Eine dient der Bereitstellung des Taktes (SCL) und die andere dem Datentransport (SDA). Die einzige zusätzlich benötigt Hardware besteht aus zwei Pull-Up-Widerständen, welche von jeweils einer Busleitung gegen Vcc (5V) geschaltet werden. Da alle Bustreiber mit offenem Kollektor bzw. Drain am Bus anliegen, ergibt sich eine logische UND-Verknüpfung. D.h., sobald irgendein Gerät auf einer der Busleitungen Low-Pegel anlegt, liegt automatisch die gesamte Busleitung auf Low. Der Bus hat nur High-Pegel, wenn alle angeschlossenen Geräte auch High-Pegel an ihrer entsprechenden Schnittstelle haben.

Genau wie beim SPI initiiert auch beim TWI der Master den Datentransfer und beendet selbigen auch wieder. Gestartet wird eine Übertragung durch eine Start-Bedingung und entsprechend beendet durch eine Stop-Bedingung. Während einer Übertragung gilt der Bus als "busy" (beschäftigt) und kein anderer Master darf versuchen, Kontrolle über ihn zu erlangen. Einzige Ausnahme bildet hier der Fall, dass vor einer Stop-Bedingung durch den gerade aktiven Master noch eine zusätzliche Start-Bedingung auf den Bus gegeben wird. Dieser Fall tritt normalerweise dann ein, wenn der Master noch weitere Daten zu versenden hat und nicht die Kontrolle über den Bus verlieren möchte. Nach solch einem wiederholten Start (Repeated Start) ist der Bus wieder bis zum nächsten Stop beschäftigt.
Start- und Stop-Bedingungen werden signalisiert, indem der Pegel der SDA-Leitung wechselt, während SCL High-Pegel hat.

Alle Adresspakete auf dem TWI-Bus haben eine Länge von 9 Bit. Davon beinhalten 7 Bit wie bereits eingangs erwähnt die Adresse der angesprochenen Komponente. Ein weiteres Bit bestimmt, ob ein Lese- oder ein Schreibzugriff durchgeführt werden soll (R/W=1 -> Lesen; RW=0 -> Schreiben). Das 9. Bit dient der Bestätigung. Wenn ein Slave bemerkt, dass er angesprochen wird, so bestätigt er dies, indem er mit dem 9. Taktzyklus (ACK) von SCL die SDA-Leitung auf Low-Pegel legt. Sollte der angesprochene Slave aus irgendwelchen Gründen nicht antworten können, so sollte SDA auf High-Pegel bleiben. Der Master hat dann die Wahl, ob er ein Stop sendet oder einen wiederholten Start durchführt.

* SLA +R --> Adresspaket mit einer Slave-Adresse und einem Lese-Bit
* SLA +W --> Adresspaket mit einer Slave-Adresse und einem Schreib-Bit

Das höchstwertige Bit wird prinzipiell zuerst übertragen (MSB: Most Significant Bit). Die Slave-Adressen können durch den Anwender frei gewählt werden, nur 0000 000 ist reserviert, hiermit werden alle Slaves angesprochen. Wird ein solcher Zugriff durchgeführt, so sollten alle Slaves im ACK-Zyklus SDA auf Low-Pegel legen.
Benutzt wird diese Aktion, wenn der Master die selben Daten an mehrere Slaves senden möchte. Sinn ergibt die Verwendung nur in Verbindung mit dem Schreib-Bit. Ein Setzen des Lese-Bits hätte zur Folge, dass verschiedene Slaves ja verschiedene Daten auf den Bus stellen könnten, was zu einem Durcheinander führen würde. Wird das Schreib-Bit gesetzt, so setzen im ACK-Zyklus alle Slaves SDA auf Low-Pegel, welche den allgemeinen Adressaufruf erhalten und ausgewertet haben (also die nicht beschäftigt waren). Die folgenden Datenpakete werden dann von allen Slaves empfangen, welche SDA auf Low-Pegel gelegt hatten.

Alle Datenpakete auf dem TWI-Bus haben analog zu den Adresspaketen 9 Bit. Hiervon sind 8 Datenbits. Das 9. dient der Bestätigung. Während einer Datenübertragung ist es Aufgabe des Masters, den Takt, das Start- und das Stopzeichen bereitzustellen. Aufgabe des Empfängers ist die Bestätigung der erhaltenen Daten, indem er die SDA-Leitung während des 9. SCL-Zyklus auf Low-Pegel legt. Dieses wird als ACK bezeichnet (Acknowledge). Bleibt SDA auf High-Pegel, so wird dem Sender signalisiert, dass die gesendeten Daten nicht empfangen wurden (NACK). Das MSB wird zuerst übertragen.

Wenn man nun Adress- und Datenpakete kombiniert, hat man schon eine fertige Übertragung. Diese besteht aus:

* START --> SLA R/W --> ein oder mehr Datenpakete --> STOP

Ein START gefolgt von einem STOP ist nicht zulässig. Wenn der Takt des Masters für den Slave zu schnell ist oder er noch mehr Zeit zur Bearbeitung braucht, so kann er SCL einfach länger auf Low-Pegel halten. Die Verlängerung der Low-Phase von SCL hat allerdings keinen Einfluss auf die Länge der High-Phase, da diese vom Master zur Verfügung gestellt wird. Dadurch kann es allerdings zu einer Reduzierung des Datentransfers kommen.

== Multi-Master-Bussysteme ==

Das TWI-Bussystem erlaubt den Multi-Master-Betrieb. Es wurden spezielle Vorkehrungen getroffen, so dass auch wenn mehrere Master zur selben Zeit eine Transmission beginnen wollen keine Probleme auftreten und der Bus normal funktioniert. Nur die zwei folgenden Probleme sollten beachtet werden:

# Es ist Sache des Anwenders, seine Algorithmen so auszulegen, dass in diesem Fall nur ein Master seine Transmission fortsetzt. Alle anderen Master sollten ihre Transmission sofort abbrechen. Diesen Auswahlprozess zwischen den Mastern nennt man Arbitrierung (Entscheidung). Wenn ein Master bemerkt, dass er den Entscheidungsprozess (die Arbitrierung) verloren hat, sollte er sofort in den Slave-Modus gehen, da es sein kann, dass der Master, welcher den Prozess gewonnen hat, ihn adressieren will. Die Tatsache, dass mehrere Master versucht hatten, eine Übertragung zu starten, sollte für die Slaves nicht feststellbar sein, die Daten auf dem Bus dürfen nicht beschädigt sein.
# Da verschiedene Master mit verschiedenen Taktfrequenzen auf dem Bus arbeiten könnten, ist eine Festlegung zu treffen, wie man diese synchronisiert. Dieses erleichtert auch den Arbitrierungsprozess.

Die Lösung dieses Problems stellt die schon oben angesprochene Und-Verknüpfung aller Komponenten auf dem Bus dar. So werden alle seriellen Taktraten der einzelnen Master "und" verknüpft. Somit ergibt sich ein High-Pegel entsprechend dem des Masters mit dem kürzesten High-Pegel, der Low-Pegel ist durch den Master mit der geringsten Taktrate gegeben.

Da der Multi-Master-Betrieb für meine Anwendung keinen Belang hat, werde ich hier nicht näher darauf eingehen.

==Aufbau des TWI==

Der SCL- und der SDA-Pin stellen die Schnittstelle des einzelnen MC mit dem Bus dar. Zusätzlich ist intern vorgesehen, dass Spannungsspitzen, welche kürzer als 50ns sind, herausgefiltert werden. Es besteht bei manchen Konfigurationen die Möglichkeit, die internen Pull-Up Widerstände zu verwenden, dies kann die Verwendung der externen überflüssig machen.

Zusätzlich verfügt der ATmega über einen Bitraten-Generator, welcher im Masterbetrieb das entsprechende Signal auf SCL gibt. Die Taktrate wird durch das TWBR (TWI Bit Rate Register) und TWSR (TWI Status Register) festgelegt. Zu beachten ist, dass die interne Taktfrequenz der einzelnen Slaves mindestens 16 mal höher als die Taktrate des Bus ist. Diese ergibt sich nach folgender Formel:

http://www.mikrocontroller.net/mc-project/Pages/AVR/TWI/twi_formel.gif

* TWBR - TWI Bit Rate Register
* TWPS - TWI Prescaler Bits im TWI Status Register

Des weiteren verfügt der MC über je ein Daten- und Adressschieberegister, einen START/STOP Controller und die Arbitrierungslogik. Das TWDR (TWI Data Register) beinhaltet entweder die Adresse und Daten welche gesendet werden sollen oder die empfangene Adresse samt Daten. Zusätzlich existiert noch ein Register, welches das (N)ACK-Bit enthält, das aber nicht direkt zugänglich ist. Jedoch kann es im Empfangsmodus durch verändern von TWCR (TWI Control Register) bzw. im Empfangsmodus durch verändern von TWSR manipuliert werden.

Der START/STOP Controller ist wie sein Name bereits sagt, dafür verantwortlich, den anderen Teilnehmern am Bus mitzuteilen, dass der entsprechende Master eine Übertragung plant bzw. beendet. Zusätzlich führt er auch den bereits erwähnten REPEATED START durch. Eine Besonderheit ist, dass er solche START/STOP-Zeichen auf dem Bus sogar detektieren kann, wenn sich der Controller in einem der Sleep-Modi befindet. Er kann somit "aufgeweckt" werden, wenn er von einem Master adressiert wird.

Ein weiterer Bestandteil des TWI ist die "Adress Match Unit". Diese überwacht, ob die empfangenen Adress-Bytes mit denen im TWAR (TWI Adress Register) übereinstimmen. Wenn TWGCE (TWI General Call Recognition Enable) in TWAR gesetzt ist, werden alle eingehenden Adress-Bytes zusätzlich noch daraufhin überprüft, ob ein allgemeiner Ruf (0000 000) vorliegt. Sollte eine Übereinstimmung vorliegen, wird die Kontrolleinheit informiert, eventuelle Korrekturmaßnahmen können durchgeführt werden. Die TWI-Logik kann nun die Anforderung bestätigen, je nach dem welche Einstellungen in TWCR getroffen wurden. Wie bereits oben angesprochen wurde, arbeitet die Adress-Vergleichs-Logik sogar, wenn sich der MC in einem der Sleep-Modi befindet. Man kann den MC somit per TWI reaktivieren. Einzige Ausnahme bildet der Fall, dass der Controller zuvor durch einen anderen Interrupt reaktiviert wurde. Danach geht die TWI-Logik sofort in den Leerlauf. Sollte das bei der vorgesehenen Problemstellung zu Problemen führen, bleibt nur der Ausweg sämtliche anderen Interrupts in der Hinsicht zu sperren, dass sie den Controller nicht mehr reaktivieren können.

Die Kontrolleinheit des TWI beobachtet ständig den Bus und antwortet auf Anfragen entsprechend den Einstellungen in TWCR. Tritt ein Ereignis ein, auf welches die angesprochene Einheit reagieren soll, so wird automatisch TWINT (TWI Interrupt Flag) gesetzt. Im nächsten Taktzyklus wird dann TWSR aktualisiert, in ihm steht jetzt ein Code mit welchem das Ereignis spezifiziert werden kann. TWSR beinhaltet nur relevante Informationen, wenn TWINT gesetzt wird, andernfalls beinhaltet es bloß einen Statuscode, welcher aussagt, dass keine relevanten Informationen vorliegen. Solange TWINT gesetzt ist, wird SCL auf Low Pegel belassen. Dies gibt dem angesprochenen MC die Chance, alle Anwendungen erst zu beenden, bevor er sich der Transmission widmet. TWINT wird gesetzt wenn:

* wenn das TWI START/REPEATED START gesendet hat
* wenn das TWI SLA +R/W gesendet hat
* wenn das TWI ein Adress-Byte gesendet hat
* wenn das TWI seine "Vormacht" auf dem Bus verloren hat
* wenn das TWI durch seine eigene Slave-Adresse bzw. einen allgemeinen Ruf (general call) adressiert wurde
* wenn das TWI ein Datenbyte empfangen hat
* wenn ein STOP oder REPEATED START empfangen wurde, während es immer noch als Slave angesprochen ist
* wenn ein Busfehler durch einen illegalen START bzw. STOP aufgetreten ist

== Benutzung des TWI ==

Das TWI ist wie bereits ausführlich dargestellt wurde, byte- bzw. interruptbasiert. Dadurch ist es der Anwendersoftware möglich, parallel zum Datenversand bzw. -empfang auf dem TWI Bus noch weitere Anwendungen (Operationen) auszuführen. Die Ausführung einer ISR ist allein durch das Setzen von TWIE (TWI Interrupt Enable) in TWCR bedingt (die Interrupts müssen natürlich auch global freigegeben sein). Es ist Sache des Anwenders, ob das Setzen von TWINT einen Interrupt verursachen soll. Ist TWIE nicht gesetzt, so ist es dem Programm selbst überlassen, ständig TWINT zu prüfen, um sämtliche Ereignisse auf dem Bus mit zu bekommen.

Bei jedem Setzen von TWINT ist eine Operation auf dem Bus abgeschlossen worden und es wird eine Antwort erwartet. In diesem Fall beinhaltet TWSR einen Wert, welcher ein direktes Maß für den aktuellen Status des Bus ist. Die Software legt nun fest, welche Aktion mit dem nächsten Buszyklus durchgeführt werden soll, indem sie TWCR und TWDR entsprechend verändert. Im folgenden wird schrittweise ein Beispiel für den Ablauf einer Übertragung gegeben.

Um die entsprechenden Statusmakros (''TW_*'') verwenden zu können wird die entsprechende Headerdatei eingebunden.

<syntaxhighlight lang="c">
#include <util/twi.h>
</syntaxhighlight>

Zuerst muss vom Master ein START-Signal auf den Bus gegeben werden. Dies erfolgt durch Schreiben eines speziellen Wertes in TWCR. Nach Abschluss der Operation wird TWINT gesetzt. Die Logik wartet nun so lange, bis durch den Anwender das Flag wieder gelöscht wurde (durch Schreiben einer '1'). Unmittelbar nach dem Löschen von TWINT beginnt die Logik damit das START-Signal zu senden.

<syntaxhighlight lang="c">
TWCR = _BV(TWINT) | _BV(TWSTA) | _BV(TWEN); //TWSTA = TWI START Condition Bit
</syntaxhighlight>

Nach dem Senden des START wird sofort wieder TWINT in TWCR gesetzt. Zusätzlich beinhaltet TWSR jetzt den entsprechenden Status Code, welcher mitteilt, dass START erfolgreich gesendet wurde.

<syntaxhighlight lang="c">
while (!(TWCR & (1<<TWINT)));
</syntaxhighlight>

Nachdem durch die Applikation TWSR daraufhin überprüft wurde, dass START erfolgreich gesendet wurde, kann es nun weitergehen. Im Fehlerfall könnte beispielsweise eine vom Anwender definierte Fehlerroutine greifen.

Nun muss SLA_W in TWDR geladen werden. Ist dies abgeschlossen, muss wiederum ein spezieller Wert in TWCR geschrieben werden, um der TWI-Logik mitzuteilen, dass die Adresse und der Schreibbefehl aus TWDR gesendet werden können. Unmittelbar nachdem durch den Anwender dann TWINT in TWCR gelöscht wurde (Schreiben einer '1') sendet das TWI das Adresspaket.

<syntaxhighlight lang="c">
if ((TWSR & 0xF8) != TW_START)
ERROR(); //Fehlerbehandlung
TWDR = SLA_W;
TWCR = (1<<TWINT) | (1<<TWEN);
</syntaxhighlight>

Nach Abschluss der Sendung wird wiederum TWINT gesetzt und in TWSR steht der entsprechende Statuscode, welcher über Erfolg bzw. Misserfolg der Sendung urteilt. In ihm ist auch das ACK-Bit des angesprochenen Slaves enthalten (oder auch nicht, was dann einen Fehler bedeuten würde).

<syntaxhighlight lang="c">
while (!(TWCR & (1<<TWINT)));
</syntaxhighlight>

Nach der Prüfung von TWSR ob bei der Sendung keine Fehler aufgetreten sind, kann das Datenpaket in TWDR geladen werden. Erneut muss ein spezieller Wert in TWCR geschrieben werden, welcher der Logik sagt, dass ein Datenpaket aus TWDR versendet werden soll. Nach dem Löschen von TWINT wird dieses automatisch versendet.

<syntaxhighlight lang="c">
if ((TWSR & 0xF8) != TW_MT_SLA_ACK)
ERROR();
TWDR = DATA;
TWCR = (1<<TWINT) | (1<<TWEN);
</syntaxhighlight>

Nachdem TWINT gesetzt wurde kann mit Hilfe von TWSR überprüft werden, ob das Datenpaket erfolgreich gesendet und vom angesprochenen Slave angenommen wurde (ACK-Bit).

<syntaxhighlight lang="c">
while (!(TWCR & (1<<TWINT)));
</syntaxhighlight>

Nachdem bis hierhin alles funktioniert hat (angenommen), muss nun nur noch ein STOP gesendet werden. Dies erfolgt analog zu den obigen Ausführungen durch Schreiben eines speziellen Wertes in TWCR. Nach dem Löschen von TWINT wird dieses gesendet. Allerdings wird danach TWINT nicht automatisch wieder gesetzt, wie es zuvor immer der Fall war.

<syntaxhighlight lang="c">
if ((TWSR & 0xF8) != TW_MT_DATA_ACK)
ERROR();
TWCR = (1<<TWINT)|(1<<TWEN)|
(1<<TWSTO);
</syntaxhighlight>

Anmerkung: Selbstverständlich muss zuvor beim anzusprechenden Slave in TWAR (TWI Adress Register) eine Adresse festgelegt werden, damit er auch gezielt angesprochen werden kann.

== Übertragungsmodi ==

Das TWI kann prinzipiell in vier verschiedenen Modi arbeiten: Master Transmitter (MT), Master Receiver (MR), Slave Transmitter (ST), Slave Receiver (SR). Diese können natürlich alle in einer Anwendung verwendet werden, je nachdem, wie sie es erfordert.

=== Master Transmitter Mode ===

Im MTM wird eine Abfolge von Bytes (Daten) an einen SR gesendet. Um ihn zu benutzen, muss das Adresspaket nach dem gesendeten START eine bestimmte Form aufweisen. Wird SLA+W gesendet, liegt der MTM vor, für SLA+R wäre es der MRM.
Das Senden eines START gestaltet sich wie folgt (TWCR):

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

* TWEN: Aktivierung des TWI
* TWSTA: Senden des START
* TWINT: um TWINT zu löschen

Das TWI wartet nun solange, bis der Bus frei ist und sendet dann START. Danach wird TWINT wieder gesetzt und TWSR aktualisiert. Es sollte jetzt 0x08 enthalten. Beim Auslesen des Status-Code müssen die Prescaler-Bits mit Null maskiert werden. Um den MTM zu benutzen, muss SLA+W in TWDR geschrieben werden. Nachdem TWINT gelöscht wurde, wird dies gesendet. TWCR muss dazu die folgende Form haben:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |0 |X |1 |0 |X
}}

Nachdem SLA+W gesendet und das ACK-Bit empfangen wurde, wird TWINT erneut gesetzt. Der Statuscode in TWSR kann nun unter anderem folgende Formen haben: 0x18, 0x20, 0x38.

Nachdem bis hierhin alles erfolgreich funktioniert hat, kann jetzt ein Datenpaket versendet werden. Dies erfolgt durch Schreiben der Daten in TWDR. TWDR kann nur aktualisiert werden, wenn TWINT gesetzt ist, andernfalls kommt es zu einem Fehler, TWWC (TWI Write Collision Bit) wird gesetzt. Um die Daten zu senden, muss TWINT erneut gelöscht werden. TWCR sollte so aussehen:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Dieses Schema wiederholt sich nun solange, bis alle Daten versendet wurden und ein STOP gesendet werden kann. Dies erfolgt folgendermaßen:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |1 |X |1 |0 |X
}}

Ein erneuter Start (REPEATED START) erfolgt durch Schreiben der folgenden Werte in TWCR:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Nach einem REPEATED START kann der Master denselben Slave erneut kontaktieren oder auch einen anderen, ohne ein STOP zu senden. Der REPEATED START erlaubt dem Master das Wechseln zwischen Slaves, MTM und MRM ohne die Kontrolle über den Bus zu verlieren.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.176 zu entnehmen.

=== Master Receiver Mode ===

Im MRM empfängt der Master Daten von einem ST. Zunächst muss wieder START gesendet werden. Das folgende Adresspaket sollte dann SLA+R enthalten.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

* TWEN: Aktivierung des TWI
* TWSTA: Senden des START
* TWINT: um TWINT zu löschen

Das TWI wartet nun solange, bis der Bus frei ist und sendet dann START. Danach wird TWINT wieder gesetzt und TWSR aktualisiert. Es sollte jetzt 0x08 enthalten. Beim Auslesen des Status-Code müssen die Prescaler-Bits mit Null maskiert werden. Um den MRM zu benutzen, muss SLA+R in TWDR geschrieben werden. Nachdem TWINT gelöscht wurde, wird dies gesendet. TWCR muss dazu die folgende Form haben:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |0 |X |1 |0 |X
}}

Nachdem SLA+R gesendet und das ACK-Bit empfangen wurde, wird TWINT erneut gesetzt. Der Statuscode in TWSR kann nun unter anderem folgende Formen haben: 0x38, 0x40, 0x48.
Die empfangenen Daten können aus TWDR gelesen werden, so denn TWINT gesetzt ist. Dieses Schema kann sich bis zum Empfang des letzten Bytes immer wieder wiederholen. Nachdem das letzte Byte empfangen wurde, kann der Master dem Slave durch senden von NACK klar machen, dass keine Daten mehr erwartet werden. Beendet wird der Transfer durch senden von STOP oder REPEATED START.
Für STOP muss folgendes in TWCR geschrieben werden:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |0 |1 |X |1 |0 |X
}}

Für einen REPEATED START muss folgendes in TWCR geschrieben werden:

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|1 |X |1 |0 |X |1 |0 |X
}}

Nach einem REPEATED START kann der Master denselben Slave erneut kontaktieren oder auch einen anderen, ohne ein STOP zu senden. Der REPEATED START erlaubt dem Master das Wechseln zwischen Slaves, MTM und MRM ohne die Kontrolle über den Bus zu verlieren.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.179 zu entnehmen.

=== Slave Receiver Mode ===

Im SRM werden Daten vom MT empfangen. Um einen Atmega8 im SRM zu betreiben, müssen TWAR und TWCR die folgende Form haben:

TWAR:
Die oberen 7 Bit stellen die Adress dar, an die das TWI antwortet, wenn es von einem Master angesprochen wird. Wenn das LSB (Least Significant Bit) in Form von TWGCE gesetzt ist, antwortet der Slave auch auf allgemeine Rufe (general calls), andernfalls natürlich nicht.

{{ByteWithValues|
|TWA6|TWA5|TWA4|TWA3|TWA2|TWA1|TWA0|TWGCE
|Hier|steht|dann|die|Adresse|des|Slave!|X
}}

TWCR:
TWEN muss zum aktivieren des TWI gesetzt werden. TWEA muss gesetzt werden, damit der Slave antwortet, falls er von einem Master oder gegeben falls durch einen general call angesprochen wird. TWSTA und TWSTO müssen auf Null gesetzt werden.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|0 |1 |0 |0 |0 |1 |0 |X
}}

Wenn TWAR und TWCR initialisiert wurden, wartet der Slave ab, bis er mit seiner Adresse bzw. gegebenen falls durch einen generall call angesprochen wird gefolgt von einem Datenrichtungs-Bit. Hierbei steht eine '0' für Schreiben (SR) und eine '1' für Lesen (ST).
Nachdem die Logik ihre eigene Adresse und ein Schreib-Bit erhalten hat, wird TWINT gesetzt und TWSR beinhaltet den entsprechenden Statuscode. Mit seiner Hilfe kann die Software dann eine sinnvolle Reaktion einleiten. Der Eintritt in den SRM kann auch erfolgen, wenn ein Master sein Vorrecht auf dem Bus verloren hat (0x68, 0x78).

Wenn TWEA während eines Transfers zurückgesetzt wird, wird das TWI ein NACK (Not Acknowledge) auf den Bus nach Empfang des nächsten Bytes geben. Dies kann verwendet werden, wenn der Slave nicht mehr in der Lage ist, mehr Bytes zu empfangen. Solange TWEA '0' ist, reagiert das TWI nicht mehr auf seine eigene Slave-Adresse. Jedoch wird der Bus weiterhin beobachtet und das TWI ist nach dem Setzen von TWEA sofort wieder einsatzbereit. Somit kann dieses Feature verwendet werden, um einen Baustein für eine bestimmte Zeitspanne vom Bus zu nehmen.

In sämtlichen Sleep-Modi (außer Idle Mode) ist der Systemtakt des TWI inaktiv. Dessen zu trotz kann das TWI durch setzen von TWEA allein mit Hilfe des Bustaktes erfassen, wenn es mit seiner Adresse bzw. durch einen general call angesprochen wird. Somit kann das TWI den Controller aufwecken. Während der Aufweck-Phase kann SCL auf L-Pegel gehalten werden wenn TWINT gelöscht ist (Schreiben einer '1'). Der Datenempfang kann wieder im Normalbetrieb stattfinden. Zu beachten ist, dass solange SCL auf L-Pegel ist keine anderen Transmissionen stattfinden können. Wichtig ist, dass TWDR nach dem Aufwecken nicht mehr das letzte Byte, welches auf dem Bus war, enthält.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.182 zu entnehmen.

=== Slave Transmitter Mode ===

Im STM werden Daten an einen MR gesendet. Um den Controller im STM zu betreiben, müssen TWAR und TWCR wie folgt initialisiert werden.

TWAR:
Die oberen 7 Bit stellen die Adress dar, an die das TWI antwortet, wenn es von einem Master angesprochen wird. Wenn das LSB (Least Significant Bit) in Form von TWGCE gesetzt ist, antwortet der Slave auch auf allgemeine Rufe (general calls), andernfalls natürlich nicht.

{{ByteWithValues|
|TWA6|TWA5|TWA4|TWA3|TWA2|TWA1|TWA0|TWGCE
|Hier|steht|dann|die|Adresse|des|Slave!|X
}}

TWCR:
TWEN muss zum aktivieren des TWI gesetzt werden. TWEA muss gesetzt werden, damit der Slave antwortet, falls er von einem Master oder gegeben falls durch einen general call angesprochen wird. TWSTA und TWSTO müssen auf Null gesetzt werden.

{{ByteWithValues|
|TWINT|TWEA|TWSTA|TWSTO|TWWC|TWEN|–|TWIE
|0 |1 |0 |0 |0 |1 |0 |X
}}

Nach der Initialisierung wartet das TWI auf eine Anfrage gefolgt von einem Datenrichtungsbit. Wird das TWI angesprochen wird TWINT gesetzt und TWSR beinhaltet den Statuscode. Mit seiner Hilfe kann das weitere Vorgehen festgelegt werden. Ein Controller kann auch in den STM gelangen, wenn er die Hoheit auf dem Bus an einen anderen Master verliert (0xB0).

Wird TWEA während eines Transfers gesetzt, wird das aktuelle Byte noch fertig gesendet und Status 0xC0 oder 0xC8 tritt ein, je nachdem ob der Master ACK oder NACK nach dem letzten Byte gesendet hatte. Das TWI wird in einen Blockierzustand gehen, unabhängig davon, ob der Master den Transfer fortsetzt. So erhält der Master nur noch '1' auf dem seriellen Bus. Status 0xC8 tritt ein, wenn der Master weitere Daten fordert (durch Senden von ACK), obwohl der Slave bereits das letzte Byte gesendet hat (TWEA '0' und erwartet NACK).

Trotz des Blockierzustandes wird der Bus weiter beobachtet und das TWI kann durch setzen von TWEA jederzeit wieder daran teilnehmen. Somit kann der Slave mit Hilfe von TWEA kurzzeitig vom Bus isoliert werden.

In sämtlichen Sleep-Modi (außer Idle Mode) ist der Systemtakt des TWI inaktiv. Dessen zu trotz kann das TWI durch setzen von TWEA allein mit Hilfe des Bustaktes erfassen, wenn es mit seiner Adresse bzw. durch einen general call angesprochen wird. Somit kann das TWI den Controller aufwecken. Während der Aufweck-Phase kann SCL auf L-Pegel gehalten werden wenn TWINT gelöscht ist (Schreiben einer '1'). Der Datenversand kann wieder im Normalbetrieb stattfinden. Zu beachten ist, dass solange SCL auf L-Pegel ist keine anderen Transmissionen stattfinden können. Wichtig ist, dass TWDR nach dem Aufwecken nicht mehr das letzte Byte, welches auf dem Bus war, enthält.

Eine Tabelle mit sämtlichen Status-Codes und den zugehörigen Ereignissen ist dem Datenblatt S.185 zu entnehmen.

Zusätzlich zu den Betriebsart bezogenen Statuscodes gibt es noch zwei, welche davon unabhängig sind.
Status 0xF8 bedeutet, dass keine relevanten Informationen vorhanden sind, da TWINT nicht gesetzt ist. Dieser Fall tritt bei einem Statuswechsel ein oder wenn TWI im Moment nicht am Bus beteiligt ist.

Status 0x00 steht für einen Busfehler während einer Übertragung. Ursache kann das Senden von START oder STOP zu einem nicht zulässigem Zeitpunkt sein. Bei solch einem Fehler wird TWINT automatisch gesetzt. Um die Fehlerroutine zu verlassen, muss TWSTO gesetzt und TWINT gelöscht werden. Dieses führt dazu, dass das TWI in den nicht adressierten Slave-Modus geht und SDA und SCL wieder freigegeben werden. Es wird kein STOP gesendet.



== Bekannte Bugs ==
Bei einigen ATMEGA Varianten (z.B. ATMEGA8) hat die TWI Implementierung einen Bug. Nach dem Aufwachen aus einem Sleep Modus funktioniert der TWI nicht mehr. Erst ein Reset mit
<syntaxhighlight lang="c">
TWCR &= ~((1 << TWSTO) | (1 << TWEN));
TWCR |= (1 << TWEN);
</syntaxhighlight>
nach dem Aufwachen löst das Problem.

Nach dem senden eines "Stop" muß vor erneutem "Start" das TWSTO Bit im TWCR Register auf "0" abgefragt werden.
Wenn dies noch eins enthält ist der Stop nicht am Bus wirksam.
Ein erneuter Start innerhalb dieser Situation bringt statt der "Start" Rückmeldung "$08" die "Restart" Rückmeldung "$10".

== Siehe auch ==

* [[I2C]]

== Weblinks ==
Weitere gefundene Probleme :
* [https://www.mikrocontroller.net/topic/456827#5518419]
=== Application notes ===

* [https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591792 AVR311: Using the TWI module as I2C slave (AN_2565) und Beispielcode]

* [https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591794 AVR315: Using the TWI module as I2C master (AN2480) und Beispielcode]

=== Bibliotheken ===

* [http://www.peterfleury.epizy.com/avr-software.html Peter Fleury's AVR I2C Library]

* http://www.mikrocontroller.net/topic/87597

* [http://www.jtronics.de/avr-projekte.html AVR TWI Slave]

* [http://www.mikrocontroller.net/topic/235733#2388116 Hardware TWI-MASTER Interrupt basierend für Mega AVR] (ASM)

[[Category:AVR]]
[[Category:Mc-project.de]]
[[Category:I2C]]

AVR HV-Programmer

2014-10-05T08:09:54Z

Pfleury: Link zu ATtiny Fuse Restore Projekt hinzugefügt

Ein "Hochspannungs"-Programmierer für AVR legt eine Spannung von +12V an den Reset-Eingang. Damit lassen sich auch Fusebits programmieren, die mit dem normalen ISP-Programmer nicht zugänglich sind.

Zu unterscheiden sind das High Voltage Serial Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm HVSP]) und das Parallel Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm PP]). Welche Methode(n) ein AVR unterstützt, steht im jeweiligen Datenblatt des AVRs.

Bekannte HV Programmer sind:
* [[STK500]] (HVSP, PP)
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (HVSP, PP)
* [http://www.der-hammer.info/hvprog/ HVProg von Tobias Hammer] (PP, HVSP)
* [http://www.b-redemann.de/produkte-programmer.shtml Bausatz und Anleitung von Bernhard Redemann] (PP)
* [http://www.obdev.at/products/avrusb/avrdoper.html AVR-Doper] High Voltage '''Serial''' Programmer (HVSP)
* [http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/ Arduino-based AVR High Voltage Programmer] (PP)
* [http://elm-chan.org/works/avrx/report_e.html '''Parallel''' HV-Programmer von ElmChan (ChaN)] (HVSP, PP)
* [http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/?lang=en Atmega fusebit doctor] (HVSP, PP)
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/HVSP-Fusebit-Programmer::63.html HVSP Fusebit Programmer] (HVSP, auch stand-alone ohne PC nutzbar)
* [http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ATtiny Fuse Restore] Anleitung für einen einfach aufzubauenden ATtiny Fuse Resetter mit AVR-GCC Software von Peter Fleury (HVSP)

Hochvolt-Programmer sind ''nur dann'' als '''In-System'''-Programmer verwendbar, wenn die Schaltung mit den 12 V an der Resetleitung zurechtkommt und auch alle anderen Pins genügend hochohmig und ohne schaltungstechnische Nebenwirkungen (etwa einem Brückenkurzschluss) angeschlossen sind. Da dies bei der Menge anzuschließender Pins [im Vergleich zur Gesamtanzahl der Pins des Gehäuses] eher selten der Fall sein wird, werden die Chips fast immer „solo“ (sozusagen „Out-System“) gebrannt. Am ehesten bietet sich HVSP-ISP für 14-beinige SMD-AVRs an; dazu müssen in der Einsatzschaltung ggf. entsprechende Vorkehrungen getroffen werden.

=== Ein Platinenlayout für ElmChans Hochvolt-Programmer ===

Dieser benötigt einen PC mit Parallelport sowie eine externe Stromversorgung von 6..24 V=. USB-Parallel-Konverter (für Drucker) funktionieren ''nicht''. Vorteil: Ein Mikrocontroller wird nicht benötigt.

Wie auch das Original beherrscht dieser PP (parallel programming) als auch HVSP (serial programming).
Für den rein seriellen Gebrauch (HVSP der 8- und 14-Beiner) kann man auf den 74HC299 verzichten.

Schaltplan im Eagle-Format, Bestückungspläne und Platinenlayout: [[Benutzer:Christoph kessler|Christoph Kessler]]

ElmChans Konzept ist eine ausgesprochene „Billiglösung“, die 20-poligen AVRs bevorzugend, dem scheint eine einseitige Platine mit Drahtbrücken im Eagle-Light-Format 80×100 mm² angemessen. Jener verzichtet auf Spannungsregler; einen 78L05 hinzuzusetzen und das Ganze mit stabilisierten 12 V zu speisen sollte jedoch nicht allzu schwer fallen.

Das Foto (unten) zeigt schon die „Luxusversion“, Teilbestückung ist entsprechend denkbar.

[[Media:AVR_HV_Programmer_Eagle.zip | Eagle board / schematic files]]

[[Bild:Schematic.png|600px]]

[[Bild:Components.png|600px]]

[[Bild:AVR_HV_Programmer_Layout.png|600px]]

[[Bild:AVR_HV_Programmer_Foto.jpg]]

===siehe auch===
[http://xray37.de/?Bastelbuch:Lima-SDR:RX Miniatur-Version von ElmChans HV-Programmer]

[[AVR In System Programmer]]

[[Kategorie:AVR-Programmer und -Bootloader]]
[[Kategorie:AVR-Boards]]