Bootloadermodus aus brickv

Hallo Tinkerforge Team,

wäre es vorstellbar, dass ihr in die grafische Benutzerschnittstelle "brickv" die Möglichkeit schafft das Bootloader Modus zu in­i­ti­ie­ren?

Viele Grüße,

Kirill

Von den Bricks? Da gibt es aktuell keine API für, geht also nur per Knopf.

Ja genau, von den bricks (genau gesagt von dem master brick). Inzwischen habe ich eine Insellösung für mich gebaut und die API und die "brickv" Anwendung entsprechend geändert. Ich wollte nur vermeiden, dass ich bei den nächsten Revisionen der API oder "brickv" ständig die Sources mergen muss.

Danke für die schnelle Antwort,

Kirill

Hallo zusammen,

habe ich gerade /Remoteflash/ gelesen? :gruebel:

Der Loetkolben

Hallo zusammen,

 

habe ich gerade /Remoteflash/ gelesen? :gruebel:

 

 

Der Loetkolben

Hallo zusammen,

wenn man in der Lage ist ein Master Brick in das Bootloader Modus zu versetzen, könnte man theoretisch die Einheit via UART auch remoteflashen. Wenn ich richtig die Sources/Layouts lese, läuft die Kommunikation zwischen der WiFi Erweiterung und dem Master Brick via UART. Wahrscheinlich könnte man diese Verbindung zum Flashen verwenden?

Viele Grüße,

Kirill

Das Flashen der Bricks läuft über den internen USB Bootloader (der ist in Hardware) der SAM3S/SAM4S Prozessoren. Das hat den großen Vorteil das man Bricks nicht komplett "bricken" kann, da man über den Erase-Knopf immer in den USB-Bootloader kommt. Das funktioniert auch noch wenn ich ausversehen eine mp3-Datei anstatt einer Firmware flashe .

Hat aber den Nachteil das wir da nichts dran ändern können. D.h. das Flashen geht nur über USB wenn der Brick im Bootloader-Modus ist.

Memories

̶ From 64 to 256 Kbytes embedded Flash, 128-bit wide access, memory accelerator, single plane

̶ From 16 to 48 Kbytes embedded SRAM

̶ 16 Kbytes ROM with embedded bootloader routines (UART, USB) and IAP routines

̶ 8-bit Static Memory Controller (SMC): SRAM, PSRAM, NOR and NAND Flash support

̶ Memory Protection Unit (MPU)

In der Dokumentation zu dem SAM3S4 steht, dass der ROM Bootloader die Funktionen zum Flashen via UART auch hat. Oder verstehe ich es falsch?

Auch dann, was stört uns einen eigenen Bootloader zu implementieren und vor dem ROM Bootloader im Speicher zu setzen und beim Booten von der Adresse des eigenen Bootloaders zu starten ?

Um per UART zu flashen ist das nicht passend angeschlossen. Macht auch keinen Sinn, dann könnte man per WIFI flashen, aber nicht per Ethernet. Das versteht dann am ende des Tages niemand mehr was da funktioniert und was nicht . Die Vorgehensweise wäre denke ich in der Tat "einfach" über unser normales Protokoll zu flashen, wie wir es auch bei den neuen Bricklets machen.

Die einfachste Möglichkeit das zu implementieren ist sicherlich 50% des Flashes nur zum flashen zu nutzen (um dort Zwischenspeichern zu können). Ein unveränderlicher Bootloader der aber trotzdem Ethernet/WIFI/RS485 sprechen kann (damit auch auch darüber flashen kann) ist leider sehr viel Aufwand. 50% flash haben wir leider nicht frei bei allen Bricks.

Blöd ist es auch wenn man dann doch einmal etwas am Ethernet/WIFI/USB Code ändern muss. Dann muss man auf einmal doch wieder über den Atmel-Bootloader flashen. Das macht es dann natürlich komplizierter .

Wenn wir bei der Lösung bleiben, bei welcher wir 50% Speicher für den eigenen Bootloader verwenden, könnte man erwarten, dass ihr sich in der Zukunft für die SAM4S Prozessoren entscheidet mit 1024Kb oder 2x1024Kb Flash? Dann wird das Thema "Over The Air" doch mehr realistischer? Verstehe ich richtig, dass die SAM4S Prozessoren "pin to pin" zu der SAM3S Serie identisch sind und man könnte durch einfaches umlöten und Anpassen der Software ein Brick upgraden?

Apropos "nicht 50% freier Speicher". Eine Idee:

Wenn 80% gefuellt sind, dann koennte man im ERSTEN Schritt einen 5% Loader flashen der uebernimmt, dann im ZWEITEN Schritt wieder eine Firmware bis zu 95% flashen?!

Der Loetkolben.