⇐ zurück zur Hauptseite
Im Bootloader erfolgt der Datenaustausch mit dem Uploader über eine Register-Struktur. Definierte
Inhalte liegen an festgelegten Stellen. Vor jeder Lese- oder Schreiboperation wird ein Index-Wert übertragen.
Dadurch wird festgelegt, bei welcher Byte-Position mit dem Lesen oder Schreiben begonnen werden soll.
struct
{ char Device[8];
//0x00 - 0x07
char Version[8];
//0x08 - 0x0f
uint8_t PageSize;
//0x10
uint8_t unused;
//0x11
uint8_t FreePages;
//0x12
uint8_t LastCommand;
//0x13
uint8_t CommandCount;
//0x14
uint8_t State;
//0x15
uint8_t Reserved[7];
//0x16 - 0x1c
volatile uint8_t PageNo;
//0x1d
volatile uint8_t CommandStart; //0x1e
volatile uint8_t
Command; //0x1f
uint8_t Data[64];
//0x20 - 0x5f
} I2CRegister;
Position |
Breite |
Name |
Bedeutung |
0x00 |
8 |
Device |
Gerätebezeichnung 'BT'1) |
0x08 |
8 |
Version |
Versionsnummer '10' = 1.01) |
0x10 |
1 |
PageSize |
Seitengöße des Flash in Byte2) |
0x12 |
1 |
FreePages |
Anzahl freier Seiten in die das zu ladende Programm übertragen werden kann2) |
0x13 |
1 |
LastCommand |
Der Code des letzten verarbeiteten Kommandos5) |
0x14 |
1 |
CommandCount |
Anzahl bisher verarbeiteter Kommandos5) |
0x15 |
1 |
State |
Statusinformation zum aktuellen Kommando5)6) |
0x1e |
1 |
PageNo |
Seitennummer der vom Kommando betroffenen Seite3). Erste Seite hat Nummer
0 |
0x1e |
1 |
CommandStart |
Sicherheitsbyte3) muss den Wert 0xa5 enthalten |
0x1f |
1 |
Command |
Auszuführendes Kommando3)4) |
0x20 |
64 |
Date |
Seitenpuffer7) |
1) Am Anfang der Struktur stehen —wie bei NXT-Sensoren üblich— Angaben zum Device
und zur Version der Firmware. Der I²C-Master kann hieran erkennen, ob das erwartete Gerät
angeschlossen ist und im richtigen Modus betrieben wird. Auch hier wegen des Speicherplatzes
nur eine spartansiche Befüllung.
2) Informationen über den Flash-Speicher für
den Uploader.
3) Der Bootloader kennt nur zwei Kommandos. Eine Seite aus den Flash auslesen und
eine Flash-Seite beschreiben. Das betroffene Kommando kann ausgelöst werden, indem ab PageNo
drei Bytes in
einem Zug geschrieben werden. CommandStart
muss mit dem Wert 0xa5 beschrieben werden. Dieser Mechanismus soll verhindern, dass versehentlich
ein Kommando ausgelöst wird. Die Seitennummer kann evtl. getrennt belegt werden. Aber CommandStart
und Command müssen in einer Schreibsequenz beschrieben werden.
4) Es gibt die Kommandos
1: Programmiere geladene Seite,
2: Lade Speicherseite ins I2C-Register
zur Verfügung.
5) Es ist schwierig nur anhand eines Ausführungsstatus zu unterscheiden,
ob ein Kommando ausgeführt und nicht übertragenen wurde. Im letzteren Fall
liegen die Statusinformationen eines vorhergehenden Kommandos vor. Zur sicheren Kontrolle der Kommandoausführung
stehen drei Informationen zur Verfügung. Zunächst ist dies der Code des letzten ausgeführten
Kommandos. Dann ein Zähler, der die ausgeführten Kommandos mitzählt. Durch Prüfung
dieser beiden Daten kann man sicher erkennen, ob das erwartete Kommando ausgeführt wurde. Über
das Status-Byte kann der Erfolg der Ausführung abgefragt werden.
6) Folgende Status-Codes
werden verwandt:
0x00: Es wurde noch kein Kommando ausgeführt.
0x01: Das letzte Kommando wurde erfolgreich
ausgeführt.
0x04: Es wurde ein unbekanntes Kommando gesendet.
7) In den Seitenpuffer werden beim Auslesen des Flash der angeforderte Seiteninhalt geladen und kann
von dort abgerufen werden. beim Flashen werden die Daten aus diesem Puffer verwandt.
Typische
Vorgehensweisen beim Uploader sehen wie folgt aus:
- Initialisierung: Die ersten 21 Byte -einschließlich
CommandCount- einlesen und mit den erwarteten Daten vergleichen (Device, Version). PageSize, FreePages
und CommandCount speichern.
- Page lesen: PageNo, CommandStart (=0xa5) und Command
(=0x02) in einer Schreibsequenz beschreiben. Warten bis State ≠ 0xfe. CommandCount und LastCommand
prüfen. Daten aus Seitenpuffer abrufen.
- Page flashen: Seitenpuffer füllen. PageNo, CommandStart
(=0xa5) und Command (=0x01) in einer Schreibsequenz beschreiben. Warten bis State ≠ 0xfe. CommandCount
und LastCommand prüfen.
⇐ zurück zur Hauptseite