im Rahmen meines Projektes möchte ich einen ESP32S3 WROOM1 oder Mini1 mit einem Handy kommunizieren lassen. Die Kommunikation nutzt eine USB OTG Schnittstelle. Bislang ist es mir unklar, wie der ESP32 Zugriff auf Handydaten hat bzw. ob das Handy eine Binärdatei direkt auf dem Flash Speicher von ESP schreiben kann. Hintergrund ist es, es soll eine Firmware in Form einer Binärdatei auf dem Handy gespeichert und diese an den ESP32 geschickt werden, sodass der Bootloader sie beim Neustart ausführt und somit ein neues Firmware Image geflasht werden.(Flashen übers Handy und nicht über PC)
Meine Fragen:
kann der ESP32S3 auf die Binärdatei, die auf dem Handy gespeichert ist, zugreifen ? wenn ja, wie ?
Kann das Handy als Host die Datei direkt auf dem Flash Speicher schreiben. Das wäre die günstigste Lösung.
Bislang ist es mir unklar, wie der ESP32 Zugriff auf
Handydaten hat bzw. ob das Handy eine Binärdatei direkt auf dem Flash
Speicher von ESP schreiben kann.
Kommt aufs "Handy" an. Smartphones können üblicherweise auf angeschlossene USB-Massenspeicher zugreifen, das können sogar die sonst recht gut verrammelten iOS-Geräte von Apple.
"Direkt auf den Flash Speicher" des ESP32 aber kann ein Smartphone auch nicht zugreifen, der ESP32 muss sich als USB-Mass Storage Device verkaufen, damit das geht. Und zusätzlich muss der ESP32 einen Dateisystemtreiber haben, über den er dann lesend auf seinen Speicher zugreift.
Kann Dein ESP32 sich als USB-Host verhalten, d.h. könntest Du an den
auch einen USB-Stick anschließen?
Der ESP32 verfügt über eine USB-Host Bibliothek, die man einbinden kann. Zudem hat er eine integrierte USB-OTG Peripherie. D.h. der kann sich als Host verhalten.
Harald K. schrieb:
"Direkt auf den Flash Speicher" des ESP32 aber kann ein Smartphone auch
nicht zugreifen, der ESP32 muss sich als USB-Mass Storage Device
verkaufen, damit das geht. Und zusätzlich muss der ESP32 einen
Dateisystemtreiber haben, über den er dann lesend auf seinen Speicher
zugreift.
Welches Problem willst Du /eigentlich/ lösen?
OK. Dann bleibt die einzige Lösung, dass der ESP32 als Host auf die Datei zugreifen muss, die sich auf dem Smartphone (iOS oder Android) befindet.
Das Problem besteht darin, wie der ESP32 darauf zugreifen kann? Welche Vorgehensweise und weitere Anforderungen gibt es denn ?
Wie ich dich verstanden habe, muss der ESP32 dann die Datei lesen und selbst auf seinen eigenen Flash Speicher schreiben.
Nochmal: Welches Problem willst Du /eigentlich/ lösen?
Wozu soll das ganze gut sein?
Das /Zugriffsproblem/ bzw. das /Sendeproblem/. Wie die Datei von der Seite des Smartphones auf den Flash Speicher des ESP32 gesendet wird und geschrieben wird.
Smartphone als Host, ESP als USB-CDC, die App kommuniziert dann seriell
damit.
Das kann der ESP32-S3 sogar von sich aus; durch Setzen der Strapping-Pins kann man den Bootloader betreten. Das CDC ist auf dem ESP32S3 in Hardware implementiert, keine externe Hardware/VCP nötig. Dann braucht man nur noch eine App, welche dieses Protokoll spricht.
Man kann aber auch ein Custom USB-Protokoll (ohne CDC) implementieren:
ESP32S3 agiert als gewöhnliches Device
ESP32S3 empfängt ein Image über einen USB-Endpoint und flasht sich selbst (das ist dank ESP-IDF überraschend einfach)
Unter Android kann man in der App über android.hardware.usb.UsbManager auf das Gerät zugreifen, Daten austauschen und eben auch das Image senden
Vorteile:
"Sauberer" und schneller (IIRC)
Erspart die Fummelei mit Strapping-Pins und ggf. dafür vorzusehende Buttons
Daher benutzerfreundlicher
Man kann sogar gleichzeitig flashen/updaten und die normale Anwendung/Übertragung laufen lassen
Nachteile:
Größerer Implementationsaufwand
USB VID benötigt
Falls die Anwendung "gebrickt" ist kann man dann so nicht mehr flashen, das ist aber dank A/B-Updates (von ESP-IDF fertig implementiert) sehr unwahrscheinlich
Ganz andere Alternative: ESP32S3 verbindet sich per WiFi mit dem Internet, lädt das Update selbst herunter und updated sich selbst vollautomatisch.
Bei Android kann es möglich sein, auf bestimmte Teile des Dateisystems
zugreifen zu können.
Prinzipiell möglich über MTP, allerdings sehr umständlich. Das Dateisystem kann bei jedem Gerät anders organisiert sein. Kaum benutzerfreundlich, weil der Dateiname- und Ort exakt eingehalten werden muss. Außerdem ist USB-Host auf dem ESP32S3 komplex zu implementieren. Zukünftige Android-Versionen könnten den Zugriff weiter einschränken / unmöglich machen. Außerdem muss der Nutzer dem Gerät weitgehend vertrauen.
Das kann der ESP32-S3 sogar von sich aus; durch Setzen der
Strapping-Pins kann man den Bootloader betreten. Das CDC ist auf dem
ESP32S3 in Hardware implementiert, keine externe Hardware/VCP nötig.
Dann braucht man nur noch eine App, welche dieses Protokoll spricht.
Wenn du auf hilfreiche Quellen referenzieren oder mehr dazu sagen kannst, wäre das sehr nett.
Man kann aber auch ein Custom USB-Protokoll (ohne CDC) implementieren:
Nachteile:
Größerer Implementationsaufwand
USB VID benötigt
Falls die Anwendung "gebrickt" ist kann man dann so nicht mehr
flashen, das ist aber dank A/B-Updates (von ESP-IDF fertig
implementiert) sehr unwahrscheinlich
Wie schaut es aus, wenn man den Flash Speicher in /factory/ und anderer Speicherort aufteilt, sodass man immer eine Reserve auf /factory/ hat und das neue Image auf dem neuen Speicherort geschrieben wird ?
Ganz andere Alternative: ESP32S3 verbindet sich per WiFi mit dem
Internet, lädt das Update selbst herunter und updated sich selbst
vollautomatisch.
Ja das ist mit Abstand die bessere Lösung. Leider ist es als Anforderung, dass der ESP32 über eine USB-Schnittstelle geupdatet wird.
/Wozu/ willst Du Dateien vom µC auf/von ein Smartphone übertragen?
Welches Problem soll das lösen?
Update der Firmware. Das neue Firmware Image wird als Biary Datei auf dem Smartphone gespeichert, sodass ein Update über den Smartphone direkt ohne den Bedarf eines PC möglich wäre.
Update der Firmware. Das neue Firmware Image wird als Biary Datei auf
dem Smartphone gespeichert
Muss es unbedingt eine Datei sein? Ich habe genau so etwas mal mit dem ESP32S3 implementiert, mit einem Custom USB Protokoll wie erläutert. Auf Android-Seite war es eine App, welche das Image aus dem Web heruntergeladen hat in den RAM (einfach ein binäres ByteArray) und dann per USB rausgeschrieben. Erspart die Fummelei mit Dateizugriff-Permissions usw. Die paar Megabyte passen locker in den RAM moderner Smartphones.
Muss es unbedingt eine Datei sein? Ich habe genau so etwas mal mit dem
ESP32S3 implementiert, mit einem Custom USB Protokoll wie erläutert. Auf
Android-Seite war es eine App, welche das Image aus dem Web
heruntergeladen hat in den RAM (einfach ein binäres ByteArray) und dann
per USB rausgeschrieben. Erspart die Fummelei mit
Dateizugriff-Permissions usw. Die paar Megabyte passen locker in den RAM
moderner Smartphones.
Nein muss nicht. Könntest du auch paar Quellen dazu erwähnen ?
Ich danke dir sehr
Muss es unbedingt eine Datei sein? Ich habe genau so etwas mal mit dem
ESP32S3 implementiert, mit einem Custom USB Protokoll wie erläutert. Auf
Android-Seite war es eine App, welche das Image aus dem Web
heruntergeladen hat in den RAM (einfach ein binäres ByteArray) und dann
per USB rausgeschrieben.
Das geht dann aber erst recht nur mit Android. Unter iOS verweigert einem Apple den dafür nötigen Zugriff auf die USB-Schnittstelle.
Was universell möglich wäre, genügend Speicher auf Seiten des ESP32 vorausgesetzt, wäre die Implementierung eines "Mass Storage Device" auf dem ESP32.
Der verhält sich dann wie ein USB-Stick, das bedeutet, jedes beliebige Gerät, mit dem man USB-Sticks verwenden kann, kann darauf zugreifen.
Und das Firmwareupdate besteht dann darin, daß das Gerät, an das man den ESP32 anschließt, einfach eine Datei auf das Dateisystem des ESP32 kopiert.
Das nämlich geht mit Android, mit iOS oder mit jedem beliebigen PC.
Der ESP32 muss dafür halt die USB-Geräteklasse "Mass Storage Device" implementieren, einen ausreichend großen Speicher zur Verfügung stellen, der mit einer passenden FAT-Variante formatiert ist (FAT12 sollte reichen), und in der Lage sein, sich die fertig geschriebene Datei da rauszuholen.
Was universell möglich wäre, genügend Speicher auf Seiten des ESP32
vorausgesetzt, wäre die Implementierung eines "Mass Storage Device" auf
dem ESP32.
Ja, geht grundsätzlich, finde ich aber keine besonders schöne/benutzerfreundliche Lösung. Lässt sich auch nicht gut automatisieren, man bekommt kein Feedback. Ich würde es auch eher als MTP und nicht als MSC machen, weil man sonst ein FAT32 simulieren müsste.
Ich würde es auch eher als
MTP und nicht als MSC machen
Die MTP-Unterstützung von iOS und macOS soll nicht die beste sein.
Was heißt "keine Rückmeldung"?
Mir sind schon Geräte untergekommen, die genauso ihr Firmwareupdate veranstalten, und die eine Textdatei in ihrem Dateisystem ablegen, in der die jeweils aktuelle Firmwareversion drinsteht.
Man kann nicht gut den Erfolg/Misserfolg/Fehlercode/Fortschritt an die Anwendung zurückmelden. Wenn das ganze automatisiert für eine ganze Geräteflotte passieren soll (MDM), wäre das schon eine rechte Frickellösung.
Man kann nicht gut den Erfolg/Misserfolg/Fehlercode/Fortschritt an die
Anwendung zurückmelden.
Wenn man eigens eine Anwendung auf dem Smartphone hat, dann geht das beim Verfahren des Objektivherstellers* sehr wohl, nämlich durch Auswertung der vom Objektiv im Dateisystem erzeugten Textdatei.
Vor dem Versuch des Firmwareupdates wird sie gelesen und die aktuelle Version bestimmt.
Nach dem Versuch des Firmwareupdates wird sie wieder gelesen und die Version bestimmt, die drinsteht.
Wenn man eigens eine Anwendung auf dem Smartphone hat
... kann man auch gleich ein "richtiges" USB-Protokoll implementieren 😄 Auf dem Controller ist das definitiv weniger Aufwand...
Funktioniert das mit MSC überhaupt wenn das Image größer als der RAM vom Controller ist? Der Host kann die Cluster des Dateisystems ja in beliebiger Reihenfolge schreiben und überschreiben, und die Datei beliebig fragmentieren/in verdrehter Reihenfolge ablegen. Das müsste man ja erst puffern bevor und sortieren bevor man es in den Flash schreibt. Oder schreibt man alles in den Flash und sortiert nachträglich?
Funktioniert das mit MSC überhaupt wenn das Image größer als der RAM vom
Controller ist?
Wenn man das Image im RAM ablegen will, geht das natürlich nicht.
Dann muss das Image halt direkt im Flash gespeichert werden.
Wenn man das aber schon mit so Popelcontrollern wie dem ST32F103 in den Griff bekommt, dann sollte es mit so einem Dickschiff wie dem ESP32 erst recht möglich sein.
Der ESP32-S3 hat 512 kB RAM; wie funktioniert das denn beim OTA-Update?
Der ESP32-S3 hat 512 kB RAM; wie funktioniert das denn beim OTA-Update?
Weil das OTA-Update ja garantiert in der richtigen Reihenfolge ankommt, kann man es einfach 1:1 in der Folge in den Flash schreiben. Ist bei MSC halt nicht so.
Ließe sich aber durch Verwendung eines geeigneten Dateiformates lösen; wenn z.B. Intel-Hex o.ä. genutzt wird, dann ist die Adressierung recht eindeutig. Um auf zwei Cluster/Sektoren verteilte Zeilen zu umgehen, wäre auch ein Format denkbar, das Datenblöcke und Adresse in einem 512-Byte-Block unterbringt. Bei 32-Bit-Adressen passen somit 508 Nutzbytes in einen dieser Blöcke, und dann ist es wirklich völlig wurscht, in welcher Reihenfolge der Kram geschrieben wird.
Ganz so einfach sollte man es sich natürlich nicht machen, um Fehlzugriffe abzufangen, zusätzlich zur Adresse sollte noch ein "magic Word", eine Blocklänge und gegebenenfalls eine Prüfsumme verwendet werden, damit nicht jemand versehentlich ein Bild auf den ESP32 kopiert und der damit sein Flash plättet.
Damit ließen sich immer noch um die 500 Nutzbytes pro Block unterbringen.
Damit ließen sich immer noch um die 500 Nutzbytes pro Block
unterbringen.
Und was wenn die Pagesize vom Flash größer als 500 ist, z.B. 512? Die "Sektoren" können ja in x-beliebiger Reihenfolge ankommen - man müsste also die Flash-Pages mehrfach beschreiben wenn die Sektoren, die zu einer Page gehören, mit großem Abstand ankommen. Und in RAM puffern kann man das gesamte Image auch nicht...
Ich würde iOS einfach nicht unterstützen, das ist ja offensichtlich für den professionellen Einsatz nicht geeignet!
Und was wenn die Pagesize vom Flash größer als 500 ist, z.B. 512? Die
"Sektoren" können ja in x-beliebiger Reihenfolge ankommen - man müsste
also die Flash-Pages mehrfach beschreiben wenn die Sektoren, die zu
einer Page gehören, mit großem Abstand ankommen. Und in RAM puffern kann
man das gesamte Image auch nicht...
Da keine einzelnen Sektoren geschrieben werden, sondern i.d.R. mehrere auf einmal (sog. Cluster), sollte das kein wirkliches Problem sein. Das nötige Abstraktionsvermögen traue ich Dir zu.
Ich würde iOS einfach nicht unterstützen, das ist ja offensichtlich für
den professionellen Einsatz nicht geeignet!
Warum eine "App" verwenden, wenn man einfach eine Datei draufkopieren kann?
Weil es den Anwender intellektuell überfordert, sich im Dateisystem den Inhalt einer Textdatei anzusehen? Sind wir schon so weit, daß man sich nach so grunzdummen Leuten richten muss? Die sind dann aber auch zu blöd, die "App" richtig zu bedienen.
Im übrigen halte ich Deine These, daß beim Kopieren einer Datei die Blöcke, aus denen die Datei besteht, in völlig stochastischer Reihenfolge übertragen werden, für ... interessant.
Hast Du das schon mal untersucht, von einem völlig leeren Dateisystem ausgehend?
Da keine einzelnen Sektoren geschrieben werden, sondern i.d.R. mehrere
auf einmal (sog. Cluster),
Naja, "i.d.R." ist keine Garantie. Sich bei sowas auf "i.d.R." verlassen? Cluster existieren nur auf Dateisystemebene, der MSC-Treiber kennt nur einzelne Sektoren.
Hast Du das schon mal untersucht, von einem völlig leeren Dateisystem
ausgehend?
Selbst wenn es bei meinen Experimenten korrekt liefe, gibt es keine Garantie. Ein Produkt auf Hoffnung und "hat bisher immer geklappt" aufzubauen finde ich schwierig.
Warum eine "App" verwenden, wenn man einfach eine Datei draufkopieren
kann?
Die Anforderung riecht sehr nach Enterprise, da geht es eh um Automatisierung, da will man nicht manuell mit Dateien rumfummeln. Eine App kann das Cloud-Gesteuert automatisieren, mit Rückmeldung zum Cloud-Server usw.
Selbst wenn es bei meinen Experimenten korrekt liefe, gibt es keine
Garantie. Ein Produkt auf Hoffnung und "hat bisher immer geklappt"
aufzubauen finde ich schwierig.
Sicher. Gewiss. Aber daß Dateien in stochastischer Reihenfolge geschrieben werden, das ist eine sehr hypothetische Annahme. Um von so etwas auszugehen, würde ich doch gerne mal einen Beleg dafür sehen, daß das /überhaupt/ irgendwo auftritt.
Fragmentierung kann in diesem Betriebsfall übrigens komplett ausgeschlossen werden, das Ziel-Dateisystem ist /leer/.
Also der übliche BWL-Schlipsträger-"Bullshit". Ja, dann kann man nichts machen. Und eine App, die eine Datei kopiert, und vorher bzw. nachher eine andere Datei liest und auswertet, die kann natürlich nichts in eine Cloud melden. Weil das ja klar ist.
Du könntest versuchen, das Esptool auf Android laufen zu lassen und den ESP damit zu flashen, Esptool ist in Python geschrieben und Python für Android gibt es ja.
Um von so
etwas auszugehen, würde ich doch gerne mal einen Beleg dafür sehen, daß
das überhaupt irgendwo auftritt.
Ich weiß dass morgen ein iPhone released wird welches in einer vom Gerät nicht vorhersehbaren aber nicht stochastischen Reihenfolge schreibt (z.B. immer jeder 3. Block).
Aber die ganze Diskussion ist eh' müßig, denn die vom Esp32 verwendeten
Flashpages sind 256 Byte groß
Ja, dann könnte es tatsächlich gehen wenn man pro 512B-Sektor 256B Nutzdaten verpackt und man mit Prüfsummen und Header sicherstellt dass man die Position korrekt erkennt. Ist nicht gerade effizient, was aber bei der Datenmenge relativ egal ist.
Und eine App, die eine Datei kopiert, und vorher bzw. nachher
eine andere Datei liest und auswertet, die kann natürlich nichts in eine
Cloud melden. Weil das ja klar ist.
Wie kann die App eigentlich den FS-Cache invalidieren? Also wenn das Gerät initial angesteckt wird, ist der per Datei vermeldete Zustand auf "alte Firmware". Nach dem Flashen simuliert das Gerät in der Datei einen neuen Zustand. Der Treiber im Host-OS liest die Datei aber gar nicht mehr aus, sondern liefert aus dem Cache immer nur das "alt" an die App. Um das Cache-Invalidate zu forcieren müsste sich das Gerät neu enumerieren. In der App muss man dann genau aufpassen dass man auch wieder exakt das selbe Gerät erwischt und nicht einen USB-Stick der in der Zwischenzeit eingesteckt wurde.
Ja, alles irgendwie möglich, aber schon eine Frickellösung mit vielen "hat bisher immer geklappt"-Hoffnungen.
Wie kann die App eigentlich den FS-Cache invalidieren? Also wenn das
Gerät initial angesteckt wird, ist der per Datei vermeldete Zustand auf
"alte Firmware". Nach dem Flashen simuliert das Gerät in der Datei einen
neuen Zustand.
Ganz einfach: Das Gerät (nicht die App!) trennt sich beim Firmware-Update vom Host. Danach wird eine Neuverbindung ausgeführt, das ist also so, als würde man einen USB-Stick abziehen und wieder dranstöpseln.
Lies die von mir verlinkte Beschreibung der Updateprozedur von Viltrox, die machen das genau so.
