Forum: Mikrocontroller und Digitale Elektronik ESP8266 Flashen ohne Tool


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Chris L. (kingkernel)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Chris L. (kingkernel)


Bewertung
0 lesenswert
nicht lesenswert

von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hat denn sonst keiner jemals ein BinaryFile per direktem UART Zugriff in 
das Modul geflasht oder sind meine Fragen zu trivial?

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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)

von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Oh, ja!
Ich, z.B. kompiliere sie selber, also nicht wirklich ich, sondern mein 
Kompiler.
https://github.com/esp8266/Arduino

: Bearbeitet durch User
von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
...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?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Achso...
Die AT Befehle kenne ich nicht gut genug...

von TestX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ESP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
Guck in die esptool.py rein. Da steht es.

Gruß
Andreas

von ESP (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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
von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
Ε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

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.