Bootloader
für PIC18 und RS232, USB und CAN
Das Konzept des Bootloaders, ein Programm über eine der integrierten Schnittstellen zu laden, ist nicht gerade neu. Auch für die PIC18 gibt es einige Bootloader im Internet die über die RS232-Schnittstelle laufen und Microchip beschreibt einen USB-Bootloader in einer ApplicationNote. Doch sind alle mir bekannten vom Funktionsumfang eher bescheiden. Da ich zudem einen Bootloader verwenden wollte der über verschiedene Schnittstellen läuft, begann ich selber einen zu schreiben.
Oberfläche
Der Begriff Bootloader bezieht sich streng genommen auf die Firmware im PIC die die Datenblöcke empfängt und in den Speicher brennt. Das Programm auf der (in der Regel) PC Seite hat dagegen "nur" die Aufgabe das compilierte Programm in Form einer HEX Datei an die Bootloader-Firmware zu senden.
Darüber hinaus bietet mein Bootloader Funktionen an um den verwendeten PIC anhand seiner DEVID zu identifizieren und zu überprüfen ob die verfügbaren Speicherbereiche auch vorhanden sind. Es lassen sich damit sowohl FLASH als auch wahlweise EEPROM und CONFIG programmieren und auslesen. Ausserdem besteht die Möglichkeit nur benutzte Blöcke zu programmieren was das Brennen von kleinen Programmen stark beschleunigen kann. Es lässt sich auch manuell auswählen welcher Bereich geschrieben werden soll. Der benutzte und verfügbare Speicher sowie der Brennfortschritt werden grafisch angezeigt.
Zur Kommunikation per USB kommt der MCHPUSB Driver zum Einsatz, für CAN-BUS mein USB2CAN. Geschrieben ist das Programm in C++ mit Borland C++ Builder. Auch wenn inzwischen schon viel Arbeit drin steckt, ist das Programm noch bestenfalls Betaversion. Ich veröffentlich daher auch den SourceCode.
Software:
- Bootloader_PC.rar
Oberfläche
Konzept A
Grundsätzlich gibt es verschiedene Konzepte die Firmware zu implementieren was insbesondere die Plazierung im Programm-Speicher betrifft. Bei den PIC18F liegt der RESET Vektor bei 0x00000 und die Interrupt Vektoren bei 0x00008 und 0x00018.
Ein Konzept sieht vor den Bootloader zu Beginn des Programmspeichers zu platzieren. Die Interruptvektoren müssen dann umgeleitet werden. Beim Start kann anhand der BootCondition überprüft werden ob der Bottloader oder das normale Programm gestartet werden soll.
Ein anderes Konzept sieht vor den Bootloader am Ende des Programmspeichers zu plazieren. Die Architektur der PIC18F legt Konzept A nahe da es hierbei WriteProtections für einen Bootblock gibt der für den Bereich von 0x000 bis 0x7FF geht.. Nachteilig an Konzept A ist das die Interrupt Vektoren weitergeleitet werden müssen, bei Konzept B liegt der Bootloader irgendwo am Ende, was bei PIC-Typen mit unterschiedlichen Speichergrößen äusserst ungünstig ist. Daher verwenden alle meine Bootloader das Konzept A.
Die Bootcondition
Um nun zu wissen ob beim Start der Bootloader ausgeführt werden soll oder das normale Programm, dient die sogenannte BootCondition. Diese kann je nach Gerät eine gedrückte Taste oder ein spezieller Wert im Speicher sein der beim Start überprüft wird. Bei PIC18Fxxxx wird hierfür der EEPROM benutzt. Bei PIC18FxxJxx ein Word im Flashspeicher.
Konzept B
Die USB-Firmware basiert auf einer modifizierten Version der MCHPUSB Referenz Firmware. Alle nicht zwingend notwendigen Funktionen sind entfernt um im den BootBlock bis 0x7FF zu passen. Das Paketformat ist geringfügig anders. Als Hardwareplattform zur Entwicklung benutze ich mein Universal-USB Board. Die untenstehende Firmware ist für das Universal-USB Board mit einem PIC18F4553 geschrieben, aber lässt sich leicht an andere Plattformen anpassen.
Firmware:
- Bootloader_PIC_USB.rar
Firmware:
- Bootloader_PIC_COM.rar
Firmware:
- Bootloader_PIC_CAN.rar
Meine Wetterstation benutzt einen hybriden Bootloader der sowohl RS232 als auch CAN-BUS unterstützt.
Firmware:
- Bootloader_PIC_HYB.rar
Um den Bootloader zu aktualisieren, kann man eine modifizierte Version des Bootloaders benutzen. Es ist im Prinzip die gleiche Software des Bootloaders, ausser das dieser erst bei 0x800 anfängt. Es ist hierbei wichtig das keine Interrupts benutzt werden da ein Interrupt immer an die Adresse 0x0008 oder 0x0018 springt. Wenn dieser Bereich beim Flashen gelöscht wird, läuft der nächste Interrupt ins Leere.