Hallo, hat schonmal einer ein ESP8266 Modul geflasht, indem einzig die UART Schnittstelle verwendet wird, ohne einen Umweg über den PC zu gehen, also quasi von Mikrocontroller direkt auf das WLAN-Modul? Die *.bin-Datei würde in einem externen Flash liegen und soll dann in das Modul reingeflasht werden. Wie muss man da vorgehen?
An sowas bin ich auch gerade dran. Das Fladshtool für die Arduino IDE ist in Python geschrieben, die wollte ich mir anschauen und dann das Protokoll übernehmen. Das Protokoll ist aber auch irgendwo dokumentiert, da könnte man auch ansetzen
Beitrag #4944461 wurde vom Autor gelöscht.
Du brauchst dazu ein Programm auf dem ESP8266. Dieses muss den Speicher lesen können (z.B. eine SD Karte) Dann muss es Datenwust in einem Bereich des eigenen Flash ablegen. Dann eine wohlbekannte API Funktion aufrufen. Der ESP führt einen Reset aus. Der Bootloader im Rom merkt dass da ein neues Programm liegt Kopiert es an die richtige Stelle im Flash und startet es. Ansonsten ist das alles sowieso auch egal, denn der ESP kann OTA Update. Da ist dann kein Gehampel mit "Seriell" nötig.
Siehe mal hier: http://www.espressif.com/sites/default/files/esp8266-sdk_application_note_firmware_download_protocol_en.pdf
ok, d.h. Schritt 1: GPIO0: low GPIO2: high GPIO15: low Schritt 2: Die Länge meines *.bin-Files bestimmen und durch den 7 Byte langen Header ergänzen. Danach das SLIP Framing Protocol umsetzen, d.h. 0x0C an den Anfang und an das Ende ansetzen, außerdem diese Daten innerhalb meiner Nutzdaten durch 0XDB + 0X0C usw. ersetzen. Meine Daten werden damit länger als sie vorher waren, im Header muss allerdings die ursprüngliche Länge des Originafiles erhalten bleiben. Zwei Fragen an dieser Stelle: 1) Jedes Packet soll mit 0x0C beginnen, der PacketHeader wiederum soll mit 0x00 beginnen. Wie beginne ich denn nun? 2) Kann es sein, dass im Header bereits ein 0X0C auftaucht, welcher ersetzt werden muss, geht man dann genauso vor, d.h. könnte der Header länger werden als die beschriebenen 9 Byte? Weiter im Text, die APNote schreibt: "Encapsulate the Firmware into several Frames and transmit them to the ESP8266" Frage an dieser Stelle: In wieviele Frames muss ich das denn unterteilen? Weiter im Text: Nach dem Header folgt ja irgendwann die Nutzlast, also die eigentliche *.bin Datei, die ja nun zunächst mit einigen Ersetzungen von 0X0C zu 0XDB+0XDC bzw. 0XDB+0XDD etwas länger geworden ist. In der AppNote wird ja noch etwas zu dem FileFormat erklärt. Kann ich da noch irgendeinen Einfluss drauf nehmen, bzw. muss ich an dieser Stelle noch Einstellungen vornehmen? Ich habe aktuell nur das *.bin File vorliegen und dieses scheint tatsächlich mit dem 0xE9 zu beginnen.
hat denn sonst keiner jemals ein BinaryFile per direktem UART Zugriff in das Modul geflasht oder sind meine Fragen zu trivial?
Die Anwendung werden wenige haben. Wenn man "was eigenes" auf den ESP flasht, dann braucht man normalerweise keinen zusätzlichen µC, sondern lässt den ESP selber werkeln. Wenn man den ESP mit der "AT-Kommando"-Firmware an einem µC betreibt, dann muss man ihn eher selten flashen. Und dann hätte der ESP (zumindest die mit genug Flash) auch noch die Option OTA-Updates zu fahren. Ich würde fast behaupten: Der Anwendungsfall einen AVR vom ESP aus zu flashen ist häufiger. (und einfacher, einen AVR-Bootloader kann man ja selber anpassen wie man ihn braucht)
Frage: Kann man beim OTA Update irgendwie Einfluss darauf nehmen, welche Firmwareversin in das Modul gespielt wird und möglicherweise auch woher die Datei genau bezogen werden soll?
Oh, ja! Ich, z.B. kompiliere sie selber, also nicht wirklich ich, sondern mein Kompiler. https://github.com/esp8266/Arduino
...Arduino scheidet leider aus. Die Module verstehen ja den AT+CIUPDATE Befehl, aber ich hatte gehofft, dass man noch irgendwelche Einstellungen vornehmen kann, damit eine ganz bestimmte Datei von eine bestimmten Standort aus gesogen wird. Das funktioniert nicht?
Wo ist denn das Problem? Das esptool.py ist opensource und ist über github erhältlich...das portierst du in die sprache/platform deiner Wahl.
Also, das Transmission Protokoll kennt laut obiger AppNote folgende Befehle: 02: DownloadStart 03: File PacketSend 04: FlashDownloadStop 08: SyncFrameSend Ich habe nun einmal die serielle Kommunikation während dem Flashen mithilfe des Flashtools geloggt und mir angeguckt, welche Befehle dabei gesendet werden. Neben 08 und 02 finde ich auch Befehle mit den Nummern: 09, 10, 05, 07 Wo finde ich denn die Zuordnung dieser Nummern?
Die Seite ist mega lahm... Außerdem muss es doch etwas vom Hersteller des Moduls geben. Kann doch irgendwie nicht sein, dass ich mir die Doku aus dem Sourcecode irgendeines Drittanbieters zusammen schustern muss...
> Kann doch irgendwie nicht sein, dass ich mir die Doku aus dem > Sourcecode irgendeines Drittanbieters zusammen schustern muss... Doch ist so. Vor drei jahren gab es noch viel weniger Doku und das Meiste nur auf chinesisch.
Wir (+TestX) meinen die Datei esptool.py, mit der Du normalerweise den ESP flashst. Das kann doch nicht so schwer sein. Und da muß man auch nichts zusammenschustern. Das steht dort sehr gut dokumentiert drin. Gruß Andreas
:
Bearbeitet durch User
Rein interessehalber: Magst du uns was über deinen doch sehr seltsamen Anwendungsfall erzählen? Wenn du die AT-Firmware benutzt, warum muss die dynamisch vom angeschlossenen µC draufgespielt werden? Vor allem wenn, wie oben angedeutet, der µC dafür viel zu klein ist und externen Zusatzspeicher braucht, der vmtl. teurer ist als der ganze ESP? Hast du zwei Versionen der AT-Firmware, bei der einmal Feature A und einmal B funktioniert, die du dynamisch umflashen willst? => Dann schließ' lieber zwei ESP8266 an den µC an, und verwende jeweils einen. Oder fixe die AT-Firmware, damit A und B gleichzeitig gehen. Wobei mir schon unverständlich ist, warum man sich für eine Neu-Entwicklung überhaupt freiwillig die AT-Firmware antut, wenn man selber C Programmieren kann. Nein, Arduino braucht man dazu nicht, das ESP-SDK läuft auch ohne. Im ESP-Arduino-Plugin ist nur alles schon schön zusammmengepackt, die Installation deshalb einfach. Aber z.B. mit platformio.org ist das ESP-SDK auch fix installiert.
Εrnst B. schrieb: > Rein interessehalber: > Magst du uns was über deinen doch sehr seltsamen Anwendungsfall > erzählen? > > Wenn du die AT-Firmware benutzt, warum muss die dynamisch vom > angeschlossenen µC draufgespielt werden? > > Vor allem wenn, wie oben angedeutet, der µC dafür viel zu klein ist und > externen Zusatzspeicher braucht, der vmtl. teurer ist als der ganze ESP? > Na, wenn man schon nach dem Sinn der ganzen Sache fragt, dann frage ich mal ganz provokativ warum der TO den ESP nicht gleich OTA programmiert. Gruß Andreas
Andreas B. schrieb: > frage ich > mal ganz provokativ warum der TO den ESP nicht gleich OTA programmiert Vermute deshalb: ESP schrieb: > Die Module verstehen ja den AT+CIUPDATE Befehl, aber ich hatte gehofft, > dass man noch irgendwelche Einstellungen vornehmen kann, damit eine ganz > bestimmte Datei von eine bestimmten Standort aus gesogen wird. er wird wohl eine ganz spezielle AT-Firmware-Version brauchen.
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.