Hallo zusammen, ich bin gerade an einem Projekt mit einem PIC24F32KA304 und möchte diesen mit einem Bootloader versehen. Das Firmwareupdate soll über Bluetooth (über das Modul SIM808 [GSM/GPRS/GPS/Bluetooth]) möglich sein. Doch bevor ich da alles neu erfinde, wollte ich fragen, ob es nicht eine Art Universalbootloader gibt, der nicht an eine bestimmte Schnittstelle gebunden ist. UART und USB Bootloader findet man ja wie Sand am Meer. Ich dachte da jedoch an einen Bootloader, der z.B. bis auf 2 Funktionen komplett fertig ist. Diese beiden Funktionen wären bspw. read_Block() und write_Block(). In diesen Funktionen könnte man den Teil des Bootloaders packen, die für die eigentliche Datenübertragung zuständig ist, also UART, USB, 1-Wire, CAN, .... und eben Bluetooth. Ich denke, dass das gehen sollte, denn der eigentliche Ablauf ist ja immer der selbe: - Initialisieren: Bootloaderprüfung (Ist einer da), Bauteilprüfung (richtiges Bauteil), ggf. verfügbaren Platz zurück geben, ... - Programm übertragen: Block von x Byte senden, Prüfsumme senden, im µC verifizieren und in den Flash schreiben - Endergebnis mitteilen Meine Frage nun: Gibt es soeinen Bootloader (in C) bereits? Idealerweise für den o.g. PIC? Oder sprechen Gründe gegen soeinen Bootloader, die ich gerade nicht sehe? Ich meine mal bei MikroC for PIC was ähnliches gesehen zu haben, allerdings betraf es da die print_f Funktion. Dort konnte man auch festlegen, welche Funktion dahinter stand, die dann nach und nach jedes einzelne Zeichen bekommen hat, nachdem die Variablen eingefügt wurden. So konnte man festlegen, ob es 1:1 per UART rausgeht oder per parralel-Bus oder SPI an ein LCD gesendet werden soll. Vielen Dank schonmal Mischa
Michael S. schrieb: > Art Universalbootloader gibt, der nicht an eine bestimmte Schnittstelle > gebunden ist. UART und USB Bootloader findet man ja wie Sand am Meer. Und ? Uart.Read() (nur als Beispiel) zum Bluetooth.Read() ändern, Uart.Print() (nur als Beispiel) zum Bluetooth.Print() ändern, danach nur noch die beiden Bluetooth Funktionen schreiben und einbinden - fertig ist die Laube. Wo ist dein Problem ?
Die Bootloader, die ich gesehen habe, haben die betreffenden UART-Befehle "überall im Code verstreut" und nicht in einer separaten Funktion gekapselt. Bis auf die Read und write Funktion darf ja nichts mit einer Schnittstelle zutun haben, sondern eher nur "Array lesen" - "Prüfen" - "ggf. Flash beschreiben". Vielleicht kenne ich auch einfach nur keinen Bootloader, wo diese Funktion so gekapselt ist, dass es eine UART.read() Funktion gibt.
Michael S. schrieb: > Die Bootloader, die ich gesehen habe, haben die betreffenden > UART-Befehle "überall im Code verstreut" und nicht in einer separaten > Funktion gekapselt. Bis auf die Read und write Funktion darf ja nichts Und die meisten Compiler die ich kenne besitzen eine "Find&Replace" Funktion...
Wo wir den Beweis haben, dass 3.5h Schlaf für mich deutlich zu wenig sind...
Michael S. schrieb: > Ich dachte da jedoch an einen Bootloader, der z.B. bis auf 2 Funktionen > komplett fertig ist. Diese beiden Funktionen wären bspw. read_Block() > und write_Block(). Damit hast du maximal die Kommunikation des Bootloaders mit dem Host abstrahiert (und auch das wahrscheinlich nur unvollständig...). Der Bootloader selber ist davon aber noch lange nicht universell. Wenn überhaupt, dann ist er auch mit dieser Abstraktion bestenfalls für eine bestimmte µC-Familie "universell", also nicht wirklich universell.
Michael S. schrieb: > Programm übertragen: Block von x Byte senden, Prüfsumme senden, im µC > verifizieren und in den Flash schreiben Ich fürchte, "in den Flash schreiben" ist auch prozessorspezifisch. Am Ende bleibt für die Abstraktion nur noch wenig übrig: die Sicherung der Übertragung. Georg
c-hater schrieb: > Damit hast du maximal die Kommunikation des Bootloaders mit dem Host > abstrahiert (und auch das wahrscheinlich nur unvollständig...). Das ist ja auch das Ziel gewesen. Einen simplen Bootloader zu haben, der einfach nur das Programm bekommt, prüft und in den Speicher schreibt. Die Software am Host muss da natürlich zu passen. Doch ich hab immer nur spezielle Bootloader gefunden. Für UART, für USB, für CAN.. Vom Prinzip immer wieder das selbe, nur eben eine andere Schnittstelle. Daher dachte ich, dass es eine Art Template für einen Bootloader gibt, wo nur noch die eigentliche Kommunikation zwischen µc (PIC) und Host programmiert werden muss. > Der Bootloader selber ist davon aber noch lange nicht universell. Wenn > überhaupt, dann ist er auch mit dieser Abstraktion bestenfalls für eine > bestimmte µC-Familie "universell", also nicht wirklich universell. Ja ok. Das ich einen Bootloader für einen ARM Cortex M4 nicht direkt auf einen PIC24 laufen lassen kann ist ja klar. Aber bei 16bittigen PICs unterscheiden sich die Funktionen i.d.R. kaum. Da dachte ich, dass es das vielleicht schon gibt. Doch ich kann natürlich, wie der Hinweis schon kam, einen UART-Bootloader für PIC24 nehmen und die Lese und Schreibefunktionen "rausziehen" und nach belieben anpassen. Georg schrieb: > Ich fürchte, "in den Flash schreiben" ist auch prozessorspezifisch. Am > Ende bleibt für die Abstraktion nur noch wenig übrig: die Sicherung der > Übertragung. Ja, ich hab mich wohl falsch ausgedrückt. Einen Universellen Bootloader für PIC24 bzw. 16bit PICs
Michael S. schrieb: > Ja, ich hab mich wohl falsch ausgedrückt. Einen Universellen Bootloader > für PIC24 bzw. 16bit PICs So habe ich dich auch verstanden und dein Ansatz ist m.E. auch richtig: Gerüst stehen lassen, nur Funktionen die mit Aussenwelt kommunizieren anpassen. Und die gerade aktuelle Verbindung kann innerhalb von 0,25s - 0,5s festgestellt werden, entsprechendes Flag wird gesetzt und gut isses.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.