Programmierboard und -software für ATmega16

Transkript

1 Studienarbeit Programmierboard und -software für ATmega16 Markus Schroeder, Universität Koblenz-Landau Betreuer: Dr. Merten Joost c 2005/2006

2 INHALTSVERZEICHNIS 2 Inhaltsverzeichnis 1 Einführung Ziel der Abhandlung Grundlagen AVR-Architektur AVR-Programmierung Das UART Der Bootloader Idee und Anforderungen Die Assembler-Befehle LPM und SPM Quelltext mit Beschreibung Die Flash-Software Idee und Anforderungen Datenformate Das Binärformat Das Intel-Hex-Format Quelltext mit Beschreibung Das Platinenlayout 45 A Anhang 50 A.1 Baudratenregister-Einstellungen A.2 Bootloader-Quelltext A.3 Flash-Software-Quelltext

3 1 EINFÜHRUNG 3 1 Einführung In der heutigen Zeit gewinnen Mikrocontroller immer mehr an Bedeutung. Durch ihre vielfältige Einsetzbarkeit, die Leistungsfähigkeit und die verhältnismäßig geringen Kosten sind sie aus der Steuerungs- und Regelungstechnik nicht mehr wegzudenken. Durch die immer höheren Anforderungen werden dann natürlich auch die Programme immer komplexer und auch eine gewissenhaft programmierte Software bedarf immer eines Praxistests. Da das Debuggen 1 nicht selten bei bereits eingebauter Hardware vonstatten geht, ist es erstrebenswert, die immer wieder nötigen Programmiervorgänge des Mikrocontrollers möglichst kurz zu halten. Trotzdem darf daraus keine Fehlertoleranz entstehen, was nur durch einen Kompromiss zu erreichen ist. Dies zu bewerkstelligen ist Thema dieser Ausarbeitung. 1.1 Ziel der Abhandlung Am Anfang jeden Projektes steht immer die Planung. Es gilt also festzulegen, was erreicht werden soll und was nicht. Da die Arbeit auch praktischen Nutzen haben soll, dient sie dazu, die im Hardwarepraktikum für Informatiker der Universität Koblenz-Landau verwendeten Mikrocontroller-Boards abzulösen. Vorher festgelegt war, dass man auf AVR-8-Bit-RISC-Prozessoren 2 von Atmel umsteigt, da diese preiswert zu beschaffen sind und für alle Modelle ausführliche Dokumentationen frei zur Verfügung stehen. Letzteres ist nicht zu unterschätzen, weil das wissenschaftliche Arbeiten von Studenten unterstützt werden soll. Bei der Modellfrage wären mehrere Typen in Frage gekommen. Hier wird der ATmega16 verwendet (siehe Abb. 1 auf Seite 5). Ebenfalls frei erhältlich ist das AVR-Studio von Atmel, welches als Ent- 1 Fehlerbehandlung und -beseitung bei bereits bestehender Software 2 siehe Kapitel 2.1 auf Seite 6

4 1 EINFÜHRUNG 4 wicklungsumgebung für Mikrocontroller-Applikationen sehr gut geeignet ist. Fehlerbehandlung ist ebenfalls mit dieser Software möglich. Vielmehr war wichtig, dass die bereits beim Vorgänger benutzten Steckmodule (siehe Abb. 2 auf Seite 5) weiter genutzt werden können, was genaue Vorgaben bezüglich der Platinengröße mit sich bringt. Es sollte letztendlich möglich sein, einen analogen Port (bestehend aus 8 Bit), einen digitalen Port (ebenfalls 8 Bit) und 2 externe Interrupts als Schnittstelle zur Verfügung zu haben. Hauptbestandteil der vorliegenden Studienarbeit ist die Entwicklung diverser Software, die das Flashen 3 von Applikationen ermöglicht. Dies soll möglichst unkompliziert, schnell und sicher erledigt werden. Um den Mikrocontroller zu programmieren gibt es mehrere Möglichkeiten, aber dazu später mehr. In diesem Fall wurde ein Softwareprojekt erstellt, dass aus einem Bootloader, der sich auf dem Mikrocontroller befindet, und einer Flash- Applikation, die von einem Host-PC aufgerufen wird, besteht. Auf beigefügtem Datenträger befinden sich die Quelltexte des Bootloaders und der Flash-Software, Schaltplan und Layout der Platine und das Datenblatt des ATmega16. 3 nichtflüchtiges Beschreiben in den Programmspeicher

5 1 EINFÜHRUNG 5 Abbildung 1: Atmel ATmega16 Abbildung 2: Vorhandenes Steckmodul mit C-Control

6 2 GRUNDLAGEN 6 2 Grundlagen Die bereits angesprochene ausführliche Dokumentation zu den AVR-Mikrocontrollern soll hier nicht kopiert werden. Vielmehr wird versucht, die in direktem Bezug zum Projekt stehenden Aspekte möglichst verständlich zu erläutern. Umfassende Informationen zu den hier folgenden Grundlagen-Themen sind auf der Homepage von Atmel 4 erhältlich. 2.1 AVR-Architektur Der für dieses Projekt verwendete ATmega16-Mikrocontroller gehört zu der Familie der 8-Bit-RISC-Controller von Atmel. RISC heißt Reduced Instruction Set Computing und beschreibt eine Architektur, die im Gegensatz zur CISC-Architektur 5 einen wesentlich weniger komplexen Befehlssatz besitzt. Dadurch sind die Befehle schneller auszuführen, was zusammen mit dem ebenfalls zur RISC-Architektur gehörenden Pipelining einen schnelleren Programmablauf ermöglicht (siehe [WS99]). Der Vorteil dieser Architektur ist so groß, dass die meisten Operationen, die im ATmega16-Befehlssatz enthalten sind, in nur einem Taktzyklus ausgeführt werden können. Mit seiner laut Spezifikation maximal möglichen Taktfrequenz von 16MHz können somit bis zu 16 Millionen Instruktionen pro Sekunde verarbeitet werden. Da CISC-Prozessoren für ein Kommando manchmal mehr als 20 Taktzyklen brauchen, ist unter Umständen ein RISC-Prozessor schneller als ein CISC-Prozessor, obwohl dieser eine weit höhere maximale Taktfreqenz zulässt. Entscheidend ist also der MIPS-Wert 6. Der ATmega16 besitzt einen Complex Instruction Set Computing 6 Million Instructions Per Second

7 2 GRUNDLAGEN 7 Kilobyte großen Flash-Speicher, in welchem die Applikationen gespeichert werden. Darüber hinaus noch 1 Kilobyte internen statischen Arbeitsspeicher (SRAM) und ein 512 Byte großes EEPROM 7. Im Gegensatz zu vielen anderen Mikrocontrollern besitzt er keinen Akkumulator, sondern 32 Arbeitsregister, die alle direkt an der ALU 8 angeschlossen sind. Die sechs 8-Bit-Register R26 bis R31 ergeben drei 16 Bit breite Register, den X-, Y- und den Z-Pointer (siehe [Atm05]). Diese haben eine sehr wichtige Aufgabe bei der Adressierung verschiedener Operationen. Ein 8-Bit-Register alleine wäre nur in der Lage 256 (2 8 ) Adressen zu referenzieren. Da sowohl Flash-Speicher als auch SRAM und EEPROM größer sind, wären sie somit nicht vollständig adressierbar. Mit 16-Bit-Registern kann man (2 16 ) Speicherstellen adressieren, was für alle vorhanden Speicher bei weitem ausreicht. Auch in vorliegendem Projekt werden diese Pointer gebraucht, da Arbeitsspeicher und Programmspeicher gelesen und beschrieben werden. Weiterhin stehen 32 I/O 9 -Pins zur Verfügung, die sich auf 4 Ports (A-D) aufteilen. Fast alle Pins des Mikrocontrollers sind doppelt belegt, wobei die gewünschte Funktion am Pin in den entsprechenden Status-Registern eingestellt wird. Der gesamte Port A stellt, sofern richtig konfiguriert, einen 8-Kanal 10-Bit Analog-Digital-Converter dar, der bei diesem Projekt auch als solcher genutzt werden soll. Die benötigten digitalen Ein- und Ausgänge werden durch Port C realisiert. Das hat den Vorteil, dass die anderen Funktionen, die noch genutzt werden sollen (serielle Schnittstelle, externe Interrupts, I/O-Pins für Status-LED s und Taster), auf den beiden anderen Ports liegen. Bei der Wahl der Taktquelle gestaltet sich der ATmega16 flexibel, da er sowohl mit einem internen Oszillator betrieben werden kann, als auch mit verschiedenen externen Taktgebern. Der interne 7 Electrically Erasable Programmable Read Only Memory 8 Arithmetic Logical Unit 9 Input/Output

8 2 GRUNDLAGEN 8 Oszillator lässt sich über bestimmte Konfigurationsbits von 1 MHz bis 8 MHz verstellen, extern sind bis zu 16MHz möglich. Auf dem Programmierboard sollen später dann auch beide Möglichkeiten erhalten bleiben, auch wenn die interne Taktung leistungsmäßig für die Anforderungen des Hardwarepraktikums ausreichend wäre. Vorteilhaft beim ATmega16 ist auch der geringe Stromverbrauch, der je nach Taktung und angeschlossener Peripherie lediglich zwischen 20mA und 400mA liegt. Diese Werte können durch eine Reihe von Stromsparmodi (Standby, Sleep, etc.) noch weiter verringert werden. Unabhängig davon ist auch eine L-Variante des ATmega16 erhältlich, die noch weniger Strom verbraucht, dafür aber auch nicht an die Maximalleistung der normalen Ausführung heranreicht. Das für das Projekt wichtige UART wird separat in Kapitel 2.3 besprochen und erklärt. Abbildung 3: Pinbelegung ATmega AVR-Programmierung Prinzipiell gibt es drei Möglichkeiten Applikationen in den Mikrocontroller zu schreiben bzw. Konfigurationsänderungen vorzunehmen. Zum einen eine

9 2 GRUNDLAGEN 9 parallele Schnittstelle und desweiteren das SPI 10 und das JTAG 11. Bei der parallelen Programmierung werden die Daten bidirektional über Port B verarbeitet. Das bedeutet, dass die Daten sowohl beim Beschreiben, als auch beim Lesen des Mikrocontroller-Speichers über diesen Datenbus laufen. Weiterhin benötigt man bei dieser Methode eine ganze Reihe von Statusbits, die hier nicht näher beschrieben werden. Diese dienen zur Synchronisation und als Handshake-Signale, damit nicht zu schnell gelesen bzw. geschrieben wird. Die Funktionen der einzelnen Signale und auch der Algorithmus zur Nutzung dieser Schnittstelle befinden sich im Datenblatt des ATmega16. Dort findet man auch eine Auflistung der verschiedenen Statussequenzen, die gesendet werden können ([Atm05]). Das SPI hingegen benutzt nur drei Pins des Mikrocontrollers, nämlich SCK für den Takt, MOSI als seriellen Dateninput und MISO als seriellen Datenoutput (jeweils aus Sicht des Mikrocontrollers). Diese Art der Programmierung wird häufig genutzt, da nur wenig Hardware zur Realisierung eines Programmieradapters erforderlich ist. Auch die benötigte Software ist frei erhältlich, wie zum Beispiel das Programm Ponyprog (siehe [Lan05]). Das JTAG bietet neben seiner Funktion als Programmierschnittstelle noch weitere Funktionen, wie zum Beispiel das On-Chip-Debuggen. Dies ermöglicht es mit geeigneter Software einzelne Programmabschnitte gezielt zu steuern oder einzelne Register auszulesen, was es möglich macht, Fehler zu finden, ohne den Mikrocontroller ausbauen oder auch nur abklemmen zu müssen. Auch hierzu finden sich Tabellen mit den Kommandos und Algorithmen im Datenblatt. Neben diesen drei bereits werkseitig zur Verfügung gestellten Program- 10 Serial Programming Interface 11 Joint Test Action Group, Bezeichnung für IEEE-Standard

10 2 GRUNDLAGEN 10 miermethoden kann man sich mit verschiedenen weiteren Softwarelösungen behelfen. Dazu sollte man jedoch den Aufbau des Flash-Speichers etwas genauer kennen, weshalb er hier kurz erläutert werden soll. Der 16 Kilobyte große Flash-Speicher lässt sich durch die zwei Konfigurationsbits BOOTSZ0 und BOOTSZ1 in einen Applikationsspeicher und einen separaten Bootbereich aufteilen (siehe Abb. 4 auf Seite 10 und Abb. 5 auf Seite 11). Abbildung 4: Flash-Speicher des ATmega16

11 2 GRUNDLAGEN 11 Abbildung 5: Konfiguration der Bootbereichgröße Durch Setzen des Konfigurationsbits BOOTRST (was hier bedeutet auf 0 zu setzen!) ist es möglich, nach einem Reset des Mikrocontrollers im vordefinierten Bootbereich zu starten. Dadurch hat man die Möglichkeit einen Bootloader zu implementieren, der dann über ein beliebiges Interface mit Peripherie, wie zum Beispiel einem Host-PC, kommunizieren kann. Somit kann man Applikationen empfangen oder auch senden. Der Befehlssatz hält dafür die beiden wichtigen Befehle LPM und SPM bereit, die im Kapitel 3.2 auf Seite 16 ausführlich beschrieben werden. Das Programm, welches im Bootbereich steht, ist in der Lage, den kompletten Flash-Speicher zu modifizieren, also auch sich selbst. Das hat große Vorteile, kann aber auch zu unerwünschten Nebeneffekten führen, weswegen eine Reihe von Sicherheitsbits existiert, um ungewollte Schreib- und Leseoperationen zu verhindern (siehe Abb. 6 auf Seite 12).

12 2 GRUNDLAGEN 12 Abbildung 6: Konfiguration der Bootlock-Bits Diese Möglichkeit eines Bootloaders soll in diesem Projekt genutzt werden. Weiterhin wird das UART des ATmega16 als Schnittstelle verwendet, da dafür sehr wenig Hardware benötigt wird, und eine serielle Schnittstelle an den meisten Rechnern vorhanden ist. Da das UART ein Hauptbestandteil des Projekts ist, wird es im nächsten Kapitel in seinen Einzelheiten erläutert. Der Bootloader wird dann in Kapitel 3 auf Seite 15 besprochen.

13 2 GRUNDLAGEN Das UART Das UART 12 wird bei diesem Projekt als Schnittstelle zur Peripherie genutzt, welche in diesem Fall ein PC mit der Flash-Software ist, die in Kapitel 4 auf Seite 31 vorgestellt wird. Entscheidend für das UART sind drei Kontrollregister (UCSRA, UCSRB, UCSRC), das Datenregister UDR und das 16 Bit breite Baudratenregister UBRR, welches sich aus den beiden 8-Bit-Registern UBRRH und UBRRL zusammensetzt. Da es sich hier um asynchrone Übertragung handelt, muss vorher eine Übertragungsgeschwindigkeit vereinbart werden. Im Falle der seriellen Kommunikation ist das die Baudrate, welche im UBRR festgelegt wird. Da in dieses Register nur natürliche Zahlen geschrieben werden können, muss man bei der Auswahl der Baudrate einige Faktoren berücksichtigen. Der Wert für das UBRR errechnet sich mit folgender Formel: M ikrocontrollertakt Baudrate/16 Diese Formel gilt allerdings nur für den Fall, dass man das Bit U2X im UCSRA auf 0 gesetzt hat, was standardmäßig auch so eingestellt ist. Setzt man dieses Bit auf 1, hat man eine doppelt so hohe Auflösung des UBRR- Wertes, was einem etwas mehr Freiheiten bei der Auswahl einer taktabhängigen Baudrate lässt, die nahezu fehlerfrei sein soll. Unbedingt beachtet werden muss dann, dass sich die Formel zur Berechnung des UBRR-Wertes dann wie folgt ändert: M ikrocontrollertakt Baudrate/8 Im Anhang ist eine Tabelle mit gebräuchlichen Einstellungen aufgeführt (siehe Kapitel A.1 auf Seite 50). Daraus ist ersichtlich, dass man, um einen geraden Wert für das UBRR zu erreichen, oft einen ungeraden Takt Universal Asynchronous serial Receiver and Transmitter

14 2 GRUNDLAGEN 14 braucht, der den Mikrocontroller speist. Man sieht auch den Vorteil des U2X- Bits. Betrachtet man beispielsweise den Fall mit folgenden Einstellungen Mikrocontrollertakt (f OSC ) = MHz Baudrate = 19.2k so fällt auf, dass diese Einstellungen mit auf 0 gesetztem U2X-Bit nicht realisierbar wären, da die Fehlerrate mit -7.0% viel zu hoch ist. Wahrscheinlich würde nicht ein einziges Byte fehlerfrei ankommen. Setzt man das U2X-Bit jedoch auf 1, liegt die Fehlerrate nur noch bei 0.2%, was auch nach Praxistests kein Problem darstellt. Das UDR ist das Datenregister für das UART. Hier steht entweder ein empfangenes Byte, oder es beinhaltet das Byte, welches als nächstes gesendet werden soll. Für den Fall, dass keine 8-Bit-Kommunikation, sondern nur 5- oder 6-Bit-Kommunikation verwendet wird, werden entsprechend viele Bits ausgeblendet (vom MSB 13 aus gesehen). Dies bedeutet, dass sie beim Empfangen ignoriert und beim Senden mit Nullen aufgefüllt werden. In diesem Projekt wird das aber nicht benötigt, da hier nur volle Bytes transferiert werden. Die schon angeführten Kontrollregister UCSRA, UCSRB und UCSRC beinhalten diverse Einstellungs- und Statusbits, anhand derer die Überwachung des UART stattfindet. Die einzelnen Bits der Register haben zumeist jeweils eigene Funktionen, welche im Kapitel 3 auf Seite 15 besprochen werden, da die Bits dort auch gelesen bzw. gesetzt werden. Darüberhinaus verfügt der ATmega16 über einen 2-stufigen FIFO 14 -Puffer, der dafür sorgt, dass zu schnell gesendete Pakete von der Gegenstelle, aber auch die abgehenden Pakete des Mikrocontrollers, zwischengespeichert werden. 13 Most Significant Bit 14 First In First Out

15 3 DER BOOTLOADER 15 3 Der Bootloader 3.1 Idee und Anforderungen Wie bereits zu Beginn dieser Ausarbeitung erwähnt, ist die Implementierung eines Bootloaders ein Hauptbestandteil des Projekts. Die Idee hinter alledem war, dass der ATmega16 nach einem Reset (Anschalten, Reset-Taster) selbständig feststellen soll, ob eine neue Applikation geflasht wird, oder ob die bereits vorhandene gestartet wird. Dies funktioniert, indem beim Start des Bootloader-Programms abgefragt wird, ob Daten über die serielle Schnittstelle angekommen sind. Dies würde bedeuten, dass eine Neuprogrammierung stattfindet, was genauer im Kapitel 3.3 auf Seite 20 erklärt wird. Die Funktion der Neuprogrammierung reicht allerdings nicht aus, da Fehler beim Flashen erkannt werden müssen. Somit muss, nachdem eine neue Applikation geschrieben worden ist, diese zur Verifikation noch einmal eingelesen und zurückgeschickt werden. Da man in den meisten Fällen bei weitem nicht den vollen Flash-Speicher des ATmega16 verwendet, wäre es unsinnig und sehr zeitaufwendig, jedes Mal den gesamten Speicher sowohl zu beschreiben, als auch danach nochmal zurückzuschicken. Es sollen also, außer den unvermeidbaren, keinerlei redundante Schreib-, Lese- und Datentransferoperationen durchgeführt werden. Zur Anzeige der Aktion, die der Mikrocontroller gerade ausführt, sollen verschiedene Leuchtdioden verwendet werden. Befindet sich der ATmega16 gerade beim Neuprogrammieren einer Applikation leuchtet eine gelbe LED. Eine weitere rote LED zeigt an, dass eine Applikation ausgeführt wird. Wo welche LED s anzuschließen sind, kann man dem Kapitel 5 auf Seite 45 entnehmen.

16 3 DER BOOTLOADER Die Assembler-Befehle LPM und SPM Die beiden Befehle LPM und SPM sind jene, die es ermöglichen, dass der ATmega16 seinen eigenen Flash-Speicher beschreibt bzw. ausliest (siehe [Atm04]). Somit sind sie elementar für dieses Projekt, da ohne diese Funktionen die Realisierung eines Bootloaders, der den Speicher manipuliert, nicht möglich wäre. Allerdings sind diese beiden Operationen nicht so einfach zu benutzen wie beispielsweise LD (load) und ST (store) Befehle, die Datenoperationen mit dem SRAM durchführen. Bei letzteren wird immer ein einzelnes Byte gelesen oder geschrieben, was mit SPM nicht ohne Umwege funktioniert. Dazu muss man wissen, dass der komplette Flash-Speicher, unabhängig von der Aufteilung in Applikations- und Bootbereich, in sogenannte Pages aufgeteilt ist. Jede Page besteht dabei aus 64 Words, also 128 Bytes. Beide dieser Werte werden später von Bedeutung sein, da SPM immer ein Word schreibt, über UART jedoch einzelne Bytes empfangen werden. Die komplette Kommunikation mit SPM funktioniert nur durch einen Pufferspeicher, auf den man wiederum nicht direkt zugreifen kann, sondern nur mit dem SPM-Befehl. Zwischen LPM und SPM muss man nochmal grundlegend folgendes unterscheiden. Der LPM-Befehl ist in der Lage, ein einzelnes beliebiges Byte aus dem Flash-Speicher zu lesen und in ein Register zu speichern. Der SPM- Befehl hingegen speichert zunächst eigentlich gar nichts, sondern dient lediglich als Bestätigungsbefehl für eine im SPMCR 15 eingestellte Aktion. Das SPMCR ist sowohl Konfigurations- als auch Statusregister für SPM- Operationen. Da seine Bedeutung wichtig ist und es im Bootloader häufig verwendet wird, soll die Funktion der einzelnen Bits nun etwas ausführlicher mit folgender Auflistung beschrieben werden. 15 Store Program Memory Control Register

17 3 DER BOOTLOADER 17 Bit 7 - SPMIE: SPM Interrupt Enable Aktiviert Interrupts, falls sie auch global aktiviert sind. Interrupt wird ausgeführt, solange SPMEM (Bit 0) den Wert 0 hat. Bit 6 - RWWSB: Read While Write Section Busy Während ein Zugriff auf den Flash-Speicher stattfindet (Page Erase oder Page Write) wird dieses Bit auf 1 gesetzt. In dieser Zeit kann kein anderer Zugriff erfolgen. Zurückgesetzt wird das Bit durch Setzen des RWWSRE (Bit 4). Bit 5 - Reserved Bit Dieses Bit hat keine Funktion und wird immer als 0 gelesen. Bit 4 - RWWSRE: Read While Write Section Read Enable Das Bit dient dazu, den Zugriff auf den Flash-Speicher wieder freizugeben. Funktioniert nur, wenn SPMEM (Bit 0) auf 0 gesetzt ist. Vorgehensweise: RWWSRE und SPMEM auf 1 setzen und innerhalb von 4 Takten mit SPM ausführen. Bit 3 - BLBSET: Boot Lock Bit Set Dieses Bit ermöglicht das Auslesen und Modifizieren der Boot-Lock- Bits (siehe Abb. 6 auf Seite 12). Vorgehensweise zum Auslesen: Z-Pointer mit 0x01 beschreiben, BLB- SET und SPMEM auf 1 setzen und innerhalb von 3 Takten mit LPM in beliebiges Zielregister laden. Vorgehensweise zum Modifizieren: Konfiguration der Boot-Lock-Bits in R0 laden (siehe Abb. 7 auf Seite 19), BLBSET und SPMEM auf 1 setzen und innerhalb von 4 Takten mit SPM ausführen.

18 3 DER BOOTLOADER 18 Bit 2 - PGWRT: Page Write Das Bit ermöglicht Schreiben einer Page aus dem eigens dafür vorgesehenen temporären Puffer-Speicher in den Flash-Speicher. Page im Flash-Speicher wird adressiert durch Z-Pointer. Da der Z-Pointer ein Byte adressiert und jede Page aus 128 Byte besteht, sind die untersten 7 Bit des Z-Pointers don t care, werden also bei diesem Befehl ignoriert. Vorgehensweise: Z-Pointer mit Adresse eines beliebigen Bytes der zu schreibenden Page laden, PGWRT und SPMEM auf 1 setzen und innerhalb von 4 Takten mit SPM ausführen Bit 1 - PGERS: Page Erase Dieses Bit ermöglicht Löschen einer Page im Flash-Speicher. Die Adressierung erfolgt analog zu der in PGWRT beschriebenen. Vorgehensweise: Z-Pointer mit Adresse eines beliebigen Bytes der zu löschenden Page laden, PGERS und SPMEM auf 1 setzen und innerhalb von 4 Takten mit SPM ausführen Bit 0 - SPMEN: Store Program Memory Enable Das Bit wird mit anderen Bits zusammengesetzt, um deren Operationen zu ermöglichen. Ist auschließlich dieses Bit gesetzt, beispielsweise durch Laden von 0x01 in SPMCR, dient es zum Füllen des temporären Puffer-Speichers, der später eine Page im Flash-Speicher ersetzt. Da das Word (bestehend aus 2 Byte), welches sich in R1:R0 befindet, in den Puffer-Speicher geschrieben wird, und die Byte-Adresse in selbigem durch den Z-Pointer beschrieben wird, ist das LSB 16 des Z- Pointers ohne Bedeutung. Da eine Page (und somit auch der temporäre 16 Least Significant Bit

19 3 DER BOOTLOADER 19 Page-Speicher) 128 Byte enthält, sind die oberen 9 Bit des Z-Pointers ebenfalls don t care. Das SPMEM wird auch als Anzeige dafür verwendet, dass eine SPM-Operation noch läuft. Es kann (und sollte) also gepollt 17 werden, um unerwünschte Seiteneffekte zu verhindern. Vorgehensweise: Daten in R1:R0 schreiben, Z-Pointer auf eine der beiden Byte-Adressen des zu schreibenden Words setzen, SPMEM auf 1 setzen und innerhalb von 4 Takten mit SPM ausführen Abbildung 7: Konfiguration der Bootlockbits mittels R0 Wie bereits in der Beschreibung der Bits erwähnt, bleiben nur vier Takte Zeit, eine ausgewählte Operation im SPMCR mit SPM auch auszuführen. Geschieht das nicht, müsste das SPMCR neu geschrieben werden. Es empfiehlt sich also, das SPMCR erst kurz vor der eigentlichen Ausführung zu konfigurieren. Für eine Neuprogrammierung des Flash-Speichers sind folgende Vorgänge nötig. Schreiben der neuen Daten in den temporären Page-Speicher, Löschen der zu modifizierenden Page im Flash und Aktualisieren der Page mit den neuen Daten im Pufferspeicher. Dazu hat man zwei Möglichkeiten bei der Vorgehensweise: 1. Pufferspeicher füllen = Page löschen = Page schreiben 2. Page löschen = Pufferspeicher füllen = Page schreiben Keine der beiden Methoden hat gravierende Vor- oder Nachteile. In diesem Projekt wurde die erste Vorgehensweise gewählt, da der Verfasser sie für 17 mittels Endlosschleife ständig den aktuellen Wert abfragen

20 3 DER BOOTLOADER 20 übersichtlicher hält. Dadurch ist es zudem möglich zwischen den Aktionen Page löschen und Page schreiben den Z-Pointer unberührt zu lassen, da er in beiden Fällen auf ein beliebiges Byte in der zu aktualisierenden Page im Flash-Speicher zeigen darf. Mit BLBSET kann man auch die sogenannten Fuse-Bits auslesen. Dies wird hier allerdings nicht behandelt, da das Setzen ohnehin nicht durch Software des Flash-Speichers möglich ist. 3.3 Quelltext mit Beschreibung In diesem Kapitel wird der implementierte Bootloader Schritt für Schritt anhand seines Quelltextes erklärt. Dazu werden einzelne Quelltextabschnitte bzw. zusammengehörige Zeilen eingefügt und kommentiert. Der komplette Quelltext ist in Kapitel A.2 auf Seite 52 und auf dem beiliegenden Datenträger zu finden. Die Nummerierung der Zeilen ist identisch, so dass man die Quelltextabschnitte schnell im gesamten Programm wiederfinden kann. Der Bootloader könnte noch weit optimiert werden, was die Ausführungsgeschwindigkeit betrifft. Da dies aber für den angestrebten Verwendungszweck nicht nötig ist, wurde darauf verzichtet, wodurch der Quelltext zudem übersichtlicher bleibt. Vorweg aber noch einige wichtige Bemerkungen. Es war wichtig die Daten nicht nur zu aktualisieren, sondern danach auch zu überprüfen, ob keine Fehler bei der Übertragung aufgetreten sind. Es soll aber weder jedesmal der gesamte Flash-Speicher neu geschrieben werden, noch sollen hinterher die kompletten 16 Kilobyte Speicher überprüft werden. Zu diesem Zweck wird folgendermaßen vorgegangen. Falls eine neue Applikation geschrieben wird, werden diese Daten immer durch die Ankunft eines Index- Bytes angekündigt, welches die Lage der zu schreibenden Page im Flash- Speicher alloziiert. Da der Mikrocontroller nicht wissen kann, wieviele Pa-

21 3 DER BOOTLOADER 21 ges ankommen, arbeiten sowohl der Bootloader als auch die Flash-Software mit Terminate-Bytes, welche stets 0xFF sind. Dadurch weiß der Bootloader, dass nichts weiteres mehr ankommt und beginnt mit der Verifikation. Da er nur aktualisierte Pages auch zum Überprüfen wieder zurückschicken soll, werden alle Indizes im Arbeitsspeicher gespeichert und von dort wieder ausgelesen. Nach Beendigung dieses Vorgangs wird wieder ein 0xFF-Byte als Terminate-Signal gesendet. Die eigentliche Verifikationsoperation wird von der Flash-Software übernommen. 1 ; 2 ; bootloader. asm, uses r16, r17, r18, r19, r20 3 ; r e q u i r e d s e t t i n g s : 4 ;BOOTSZ1=1, BOOTSZ0=0 to s e t boot loader s i z e 5 ;BOOTRST=0 to l e t µc s t a r t from boot l o a d e r a f t e r r e s e t 6 ; be sure to s e t c o n s t a n t s CLOCK and BAUD to match your s e t t i n g s 7 ; to use implemented led r o u t i n e s, i n i t i a l i z e s t a c k p o i n t e r f i r s t 8 ; ( c )2005 Markus Schroeder, schroeder@uni k o b l e n z. d e 9 ; include " m 1 6 d e f. i n c " 12.equ CLOCK = equ BAUD = equ COM_SET = CLOCK/(BAUD 8) 1 15.equ PAGESIZEBYTES = PAGESIZE ; here b e g i n s boot s e c t i o n, 0x1F00 18.org SECONDBOOTSTART c l i ; d i s a b l e i n t e r r u p t s cbi PORTD, PD5 ; red LED o f f 23 cbi PORTD, PD4 ; y e l l o w LED o f f Listing 1: Initialisierung In diesem ersten Abschnitt sind einige wichtige Kommentare, die häufige Fehler verhindern, welche beim Setzen von Mikrocontroller-Parametern entstehen können. Zeile 11 ist wichtig, um die Bezeichnung der Register und Ports verwenden zu können, da man ansonsten nur mit Speicheradressen arbeiten könnte. Die darauf folgenden Konstanten sind Parameter, die eventuell des öfteren geändert werden. Um diese nicht im Programmcode suchen zu müssen, sind sie zu Beginn des Programms deklariert. Zeile 15 ist für spätere Teile des Programms von Bedeutung, da die in der m16def.inc definierte

22 3 DER BOOTLOADER 22 Konstante PAGESIZE die Größe in Words (also 16 Bit) angibt. Zeile 18 definiert, ab welcher Adresse der folgende Code im Flash-Speicher zu stehen hat. Da durch das Setzen von BOOTRST, BOOTSZ0 und BOOTSZ1 ein Reset zum Starten ab der Adresse $0x1F00 führt, muss auch ab dort der Bootloadercode stehen. Erste Aktion des Bootloaders ist, die Interrupts global abzustellen, weil diese nicht verwendet werden und somit nur zu Fehlern im Ablauf führen könnten. Anschließend werden die angeschlossene rote und gelbe LED ausgeschaltet, da weder eine Programmierung stattfindet (gelbe LED), noch eine Applikation läuft (rote LED). 25 ; s e t t i n g s in UART c o n f i g r e g i s t e r 26 u a r t _ i n i t : 27 l d i r16, LOW(COM_SET) 28 out UBRRL, r16 ; c o n f i g u r e s baud rate s e t t i n g 29 l d i r16, HIGH(COM_SET) 30 out UBRRH, r16 ; c o n f i g u r e s baud rate s e t t i n g 31 l d i r16, 0 b ; 8 b i t data, 1 stop b i t, a s y n c. t r a n s f e r mode, no p a r i t y 32 out UCSRC, r16 33 l d i r16, 0 b ; e n a b l e RX and TX 34 out UCSRB, r16 35 l d i r16, 0 b ; s e t s U2X 36 out UCSRA, r l d i r16, 0 b ; d e f i n e PORT D as input, but PINS 4+5 as output 39 out DDRD, r16 40 l d i r16, 0 b ; e n a b l e p u l l up f o r PIN 6 o f PORT D 41 out PORTD, r16 ;PIND 4+5 used f o r LEDs, p u l l e d low 42 ;PIND 6 used f o r p o l l i n g ( jmp to $0000 ) Listing 2: Konfiguration des UART und der Ports Das Listing konfiguriert das UART und die Ports. Die allgemeine Registerbeschreibung zum UART ist im Kapitel 2.3 auf Seite 13 erklärt. Der richtige Wert für das UBRR ist bereits zu Beginn des Programms errechnet worden und wurde in der Konstante COM_SET gespeichert. Zeile 31 lädt die Konfiguration für das UCSRC in R16. Dieser Umweg über ein Arbeitsregister ist immer nötig, da man keine Konstanten direkt in I/O-Register schreiben kann, wird also im folgenden nicht immer wieder erwähnt. Bei den Werten handelt es sich um die Standardwerte für serielle Kommunikation, also 8-Bit-Wortbreite, 1 Stop-Bit und kein Paritäts-Bit. Werden diese Ein-

23 3 DER BOOTLOADER 23 stellungen geändert, muss das auch bei der Flash-Software berücksichtigt werden. Zeile 33 aktiviert die Pins 14 und 15 des ATmega16 in ihrer Eigenschaft als Sende- und Empfangspin für das UART. Somit ist die Funktion der normalen I/O-Pins des Port D überschrieben (siehe Abb. 3 auf Seite 8). Zeile 35 erhöht die Auflösung des UBRR, was weitere mögliche Kombinationen aus Takt und Baudrate zulässt. Zeile 38 legt für den Port D fest, ob dieser Input oder Output ist. Wie zu sehen ist, kann man dies für jeden Pin einzeln einstellen, wobei eine 0 Input und eine 1 Output bedeutet. Zeile 40 aktiviert für PIND6 einen internen Pullup-Widerstand. Dies ist der Pin, an dem später der Start-Taster angeschlossen ist. Beim Drücken des Tasters wird der PIND6 auf Masse gezogen, was das Programm anweist, die Applikation zu starten. 44 ; wait f o r UART data ( r e w r i t e f l a s h ) or jump to $0000 ( s t a r t a p p l i c a t i o n ) 45 p o l l _ s t a r t : 46 sbis PIND, PIND6 47 jmp s t a r t _ a p p l i c a t i o n 48 sbis UCSRA, RXC 49 jmp p o l l _ s t a r t 50 sbi PORTD, PD4 ; y e l l o w LED on 51 jmp init_mc ; i n i t f l a s h and b o o t l o a d e r 54 init_mc : 55 in r16, UDR 56 cpi r16, 0xAA 57 brne p o l l _ s t a r t 58 l d i r16, 0 x55 59 r e s p o n s e : 60 sbis UCSRA, UDRE 61 jmp r e s p o n s e 62 out UDR, r16 63 jmp read_next_index_uart ; s t a r t s a p p l i c a t i o n 66 s t a r t _ a p p l i c a t i o n : 67 cbi PORTD, PD4 ; y e l l o w LED o f f 68 sbi PORTD, PD5 ; red LED on 69 jmp $0000 ; s t a r t s a p p l i c a t i o n Listing 3: Polling-Methode und Initialisierung Dieser Code-Abschnitt dient zum Pollen des PIND6 (Start-Taster) und des RXC-Flags. Wird der Taster gedrückt, springt das Programm in Zeile 66,