ich möchte eine neue Firmware über LoRa (LoRaWAN) übertragen und sie dann im SPIFFS beim ESP32 speichern. Meine erste Frage lautet:
Im welchem Format schreibe ich in einer Binär-Datei? In Bytes oder nicht?
Dadurch das ich LoRa verwendet wird die Firmware gesplittet und es werden nur 52 Bytes jeweils versendet. Da ich die Daten in er Firmware.bin anhangen muss nutze ich:
Dann solltest Du einfach mal "esp32 base64 decode" in dieSuchmaschine Deiner Wahl eingeben und z.B. das hier finden.
Nur mal nebenbei: Wie prüfst Du, dass Deine Code richtig angekommen ist? Nicht dass nach 1 Jahr Übertragung plötzlich nichts geht.
Ist mir alles bekannt und wird berücksichtigt. Die Einschränkungen von 10 Nachrichten pro Tag, wird nicht mehr so eng gesehen und mehrere Nachrichten sind möglich.
Tommy56:
Dann solltest Du einfach mal "esp32 base64 decode" in dieSuchmaschine Deiner Wahl eingeben und z.B. das hier finden.
Nur mal nebenbei: Wie prüfst Du, dass Deine Code richtig angekommen ist? Nicht dass nach 1 Jahr Übertragung plötzlich nichts geht.
Gruß Tommy
Wird in HEX ausgeben. Ich möchte es aber in Byte haben, weil ich die Daten in einer BIN-File in Bytes sind, oder?
ist eine andere richtige Antwort auf "wie etwas in einer BIN-Datei gespeichert werden muss" ?
Wie du willst. Schreiber und Leser müssen den gleichen Regeln folgen, ansonsten ist es dir freigestellt.
MauFau:
Ist mir alles bekannt und wird berücksichtigt. Die Einschränkungen von 10 Nachrichten pro Tag, wird nicht mehr so eng gesehen und mehrere Nachrichten sind möglich.
naja, mit den 520 Byte wäre eine Firmware 1 - 1 1/2 Jahre, mit der wieviel Message pro Tag willst Du das LoraWAN da zumüllen?
Aber wenn man eben mit dem Kopf durch die Wand will...
Wenn Du Base64 schickst, mußt es eben auf der Empfangsseite wieder mit Base64 dekodieren, dann hast Du Deine Binärdaten und die schreibst Du eben, wie es schon gesaht wurde, mit SPIFFS.write() ins Filesystem.
write erwartet die Daten in einem uint_8 als Datentyp.
Die Frage nach der Verifizierung der empfangenen Daten hat er bisher auch ignoriert. Dabei ist die Wahrscheinlichkeit wohl nahe 1, dass in dem > 1 Jahr mal ein Bit umkippt.
Vor allem, wenn er bereits bei so vergleichsweise einfachen Sachen wie write schon nicht klar kommt, wie will er dann das OTA-System umprogrammieren?
Tommy56:
Die Frage nach der Verifizierung der empfangenen Daten hat er bisher auch ignoriert. Dabei ist die Wahrscheinlichkeit wohl nahe 1, dass in dem > 1 Jahr mal ein Bit umkippt.
Vor allem, wenn er bereits bei so vergleichsweise einfachen Sachen wie write schon nicht klar kommt, wie will er dann das OTA-System umprogrammieren?
Hab Dich doch nicht so
Prüfsumme über alles und eben am Ende feststellen, daß irgendwo Müll ist und von vorn anfangen...
OTA ist eigentlich relativ einfach machbar, Anleihen beim Web Updater dürften am überschaubarsten sein.
Können wir ja nächstes Jahr klären, da wird auch wieder Winter.
Vermutlich aber vergraulen wir ihn aber mit unseren Bemerkungen nur.
Wenn ich in seinem Porjekt nur einen Funken von praktisch nutzbar finden würde, täte ich mir das vielleicht sogar genauer ansehen...
amithlon:
Prüfsumme über alles und eben am Ende feststellen, daß irgendwo Müll ist und von vorn anfangen...
Da wäre ich eher für eine CRC pro Block und eine Rückmeldung, ob er ok war oder nicht. Danach entscheidet das sendende System, ob es den gleichen Block nochmal sendet oder den nächsten.
Tommy56:
Die Frage nach der Verifizierung der empfangenen Daten hat er bisher auch ignoriert. Dabei ist die Wahrscheinlichkeit wohl nahe 1, dass in dem > 1 Jahr mal ein Bit umkippt.
Vor allem, wenn er bereits bei so vergleichsweise einfachen Sachen wie write schon nicht klar kommt, wie will er dann das OTA-System umprogrammieren?
Gruß Tommy
Ich habe meine Frage falsch formuliert. Das ich die Daten mit SPIFFS.write im Flash schreibe, das ist mir bewusst. Meine Frage war, ob ich die Daten in HEX,Byte oder sonstiges reingeschrieben werden. Da ich nachher die BIN-Datei mit dieser Anleitung Flashen möchte.
Tommy56:
Da wäre ich eher für eine CRC pro Block und eine Rückmeldung, ob er ok war oder nicht. Danach entscheidet das sendende System, ob es den gleichen Block nochmal sendet oder den nächsten.
Gruß Tommy
Ich hätte dich noch nach der Prüfsumme gefragt, aber erst eins nach dem anderen.
