Announcement: there is an English version of this forum on 
Oft ist ein in ein Gerät eingebauter STM32 schlecht erreichbar, um ein Firmware-Update durchzuführen. Mit dem STM32-OTA-Flasher kann man einen angeschlossenen STM32 über WLAN flashen. Damit vermeidet man nicht nur unnötigen Kabelsalat, sondern es erübrigt sich auch, das Gerät, in dem der STM32 eingebaut ist, erst komplett auseinanderzunehmen. Außerdem kann man den STM32-OTA-Flasher verwenden, um Protokoll-Ausgaben des STM32 über UART per telnet (über das WLAN) mitzulesen. Auch kann der STM32 ferngesteuert resettet werden. Das Flashen geschieht über eine Web-Oberfläche, welche der ESP8266 bereitstellt, siehe anhängende Bilder. Diese Oberfläche kann auch vom Entwickler erweitert werden, um den STM32 über einen Browser zu steuern oder Messwerte/Protokolle abzufragen. Dabei kann der STM32-OTA-Flasher sowohl als WLAN-AP als auch als Wifi-Client eines bestehenden WLAN-Netzwerkes arbeiten. Die Firmware des ESP8266 kann natürlich auch über WLAN aktualisiert werden. Verwendet wird ein NodeMCU für eine Handvoll Euro. Es kann aber auch ein "nackter" ESP8266 ESP12-E oder ESP12-F verwendet werden - dann aber mit etwas Hühnerfutter drumherum. Das NodeMCU-Board hat den Vorteil, dass ein USB-UART-Umsetzer (i.d.R. ein CP2102) bereits On-Board ist, um den ESP8266 einmalig zu flashen. Einfach ein USB-Kabel anschließen, einmal den ESP8266 flashen und fertig. Danach geht alles über WLAN. Das Flashen des am ESP8266 angeschlossenen STM32 geschieht mit folgenden Schritten: - Upload HEX-File - Flash STM32 - Reset STM32 Optional kann man die hochgeladene HEX-Datei auch vorab vom ESP8266 prüfen lassen, ob die CRCs soweit korrekt sind - okay, das macht der nachfolgende Flash-Vorgang sowieso, aber sicher ist sicher :-) Ich habe das Projekt bei github eingestellt: https://github.com/ukw100/STM32-OTA-Flasher Die Arduino-Sources sind bereits komplett bei Github abgelegt. Für Nicht-Arduino-User werde ich auch eine fertige BIN-Datei zur Verfügung stellen, die einfach durch ein gängiges ESP-Flash-Programm einmalig geladen werden muss. Die Dokumentation wird in den nächsten Tagen nachgereicht, vermutlich am kommenden Wochenende.
Angehängte Dateien:
-
network.png
4,9 KB -
update.png
3,8 KB -
upload.png
7,3 KB -
flash.png
11 KB
:
Bearbeitet durch Moderator
wow.... das werde ich in der Tat ausprobieren. Ich bin jetzt mal über den Code "geflogen" und sehe, dass du den STM32 über den seriellen Bootloader flasht (sehe ich doch richtig). Ich bin sehr gespannt ob ich das so an's laufen bekomme. Gruß, Ralph
Es gibt auch BMP für den ESP32, damit kann man per Wifi flashen und debuggen.
Ralph S. schrieb: > Ich bin jetzt mal > über den Code "geflogen" und sehe, dass du den STM32 über den seriellen > Bootloader flasht (sehe ich doch richtig). Ja, das ist korrekt. > Ich bin sehr gespannt ob ich das so an's laufen bekomme. Ja, ich muss endlich die Doku dafür fertigmachen. Ich versuchs in den nächsten Tagen.
Hallo, danke dass du deinen Code publiziert hast, genau danach habe ich gesucht. Leider habe ich das Problem, dass scheinbar meine Hex Datei, die ich aus dem Arduino IDE Temp Verzeichnis heraus kopiere, den Fehler hat dass kein EOF enthalten sei. Diese Files lassen sich nicht flashen... Ich steh da komplett aufm Schlauch und weiß nicht weiter. Hast du oder habt ihr mir vielleicht einen Tipp was ich falsch mache? lg stefan
Stefan schrieb: > Leider habe ich das Problem, dass scheinbar meine Hex Datei, die ich aus > dem Arduino IDE Temp Verzeichnis heraus kopiere, den Fehler hat dass > kein EOF enthalten sei. Erzeugst Du die Hex-Datei für den STM32 mittels Arduino? Kannst Du so eine hier mal anhängen?
ja, ich habe einen F429ZI Nucleo, den ich mit der Arduino IDE programmiere. Normalerweise lade ich den Sketch direkt per eingebautem ST-Link hoch, jedoch möchte ich mit Hilfe deinem Projekt die Firmware auch per Web aktualisieren. Im besten Fall beide, die vom ESP und die vom STM... Die hex Datei wird beim kompilieren automatisch mit erstellt und liegt dann in dem besagten Temp Verzeichnis. P.s. kann es sein dass du die Aktualisierung des ESP selbst nicht umgesetzt hast? Da kommt bei mir die Meldung dass er die Webseite "/update" nicht findet... Danke schon mal fürs helfen
Stefan schrieb: > Die hex Datei wird beim kompilieren automatisch mit erstellt und liegt > dann in dem besagten Temp Verzeichnis. Ist ein wirklich fettes Teil, mehr als 1MB... Ich habe Deine Hex-Datei in den OTA-Flasher hochgeladen und anschließend einen Check (per Check-Button) drüberlaufen lassen. Die Datei wird als korrekt eingestuft, Ergebnis siehe Anhang. Allerdings muss ich sagen, dass ich mittlerweile eine weiter entwickelte Version benutze - auch nicht mehr das obsolete SPIFFS, sondern den Nachfolger davon. Es kann durchaus sein, dass SPIFFS solche großen Dateien gar nicht unterstützt und deshalb u.a. der EOF-Datensatz in der Hex-Datei gar nicht mehr gespeichert werden konnte. > P.s. kann es sein dass du die Aktualisierung des ESP selbst nicht > umgesetzt hast? Da kommt bei mir die Meldung dass er die Webseite > "/update" nicht findet... Auch das scheint ein Bug in der ca. 1 Jahr alten Version zu sein - ist schon seit längerer Zeit gefixt. Ich lade gleich mal die aktuelle Version hoch und melde mich dann nochmal.
Frank M. schrieb: > Ich lade gleich mal die aktuelle > Version hoch und melde mich dann nochmal. Ich habe das github-Repository https://github.com/ukw100/STM32-OTA-Flasher aktualisiert. Im wesentlichen sind es zwei Änderungen: - Wechsel von SPIFFS auf LittleFS (aktuelle IDE verwenden!) - Fix ESP8266-Update @Stefan: Ich denke, dass damit beide Probleme behoben sein sollten. Viel Spaß, Frank
Hallo Frank, vielen Dank für die schnelle Hilfe! Ich hatte es schon mit mehreren OTA Bespielen von Anderen versucht gehabt und bin fast verzweifelt. Dein Projekt ist das erste was ich bei mir dann richtig ans Laufen bekommen habe. Dein Code ist starker Tobak für mich, sehr schlank geschrieben aber für mich als Laie extrem schwer durch zu steigen. Ich versuche die neue Version... lg stefan
Hallo Frank, das Flashen des STM funktioniert tadellos! Beim Update des ESP bekomme ich noch die gleiche Meldung im Webbrowser "not found: /update" nachdem ich den Update Button gedrückt habe. Die bin Datei habe ich mit der Arduino IDE erzeugt, muss ich daran noch was ändern oder liegt es noch an einer anderen Stelle?
Angehängte Dateien:
-
Update-ESP8266.png
3,8 KB -
Welcome-ESP8266.png
2,4 KB
Stefan schrieb: > Beim Update des ESP bekomme ich noch die gleiche Meldung im Webbrowser > "not found: /update" nachdem ich den Update Button gedrückt habe. Ich flashe den ESP per OTA immer so: - Menü "Update ESP8266" anklicken - Die URL wechselt auf http://x.x.x.x/upd - nicht update! - Es erscheint dann im Browser der anhängende Screenshot (1) - Datei mit "Durchsuchen" auswählen - Button "Update" klicken - Der Browser lädt die Bin-Datei rauf.... - Es erscheint die Meldung "Update Success! Rebooting..." - Gleichzeitig wechselt die URL auf http://x.x.x.x/update - Nach einigen Sekunden erscheint "Welcome to STM32 OTA Flasher!" (2) - Gleichzeitig wechselt die URL auf http://x.x.x.x/ Bei welchem dieser Schritte hakts bei Dir?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Stefan schrieb: >> Beim Update des ESP bekomme ich noch die gleiche Meldung im Webbrowser >> "not found: /update" nachdem ich den Update Button gedrückt habe. > > Ich flashe den ESP per OTA immer so: > > - Menü "Update ESP8266" anklicken > - Die URL wechselt auf http://x.x.x.x/upd - nicht update! > - Es erscheint dann im Browser der anhängende Screenshot (1) > - Datei mit "Durchsuchen" auswählen > - Button "Update" klicken > - Der Browser lädt die Bin-Datei rauf.... > - Es erscheint die Meldung "Update Success! Rebooting..." > - Gleichzeitig wechselt die URL auf http://x.x.x.x/update > - Nach einigen Sekunden erscheint "Welcome to STM32 OTA Flasher!" (2) > - Gleichzeitig wechselt die URL auf http://x.x.x.x/ > > Bei welchem dieser Schritte hakts bei Dir? Ich mache die ersten 5 Schritte und nach dem Klick auf Update kommt binnen 2 Sekunden die Browsermeldung "not found: /update". Es scheint dass die .bin Datei nicht hoch geladen wird und dadurch alle weiteren Schritte nicht abgearbeitet werden. Ich habe die Datei firmware.bin benannt, zumindest habe ich das so im Sketch gelesen, leider ohne Erfolg. Ich generiere die .bin Datei ebenfalls mit der Arduino IDE. Muss ich dort noch etwas besonderes machen? Sorry wenn ich dir da noch so lästig bin...
Hallo, Das Projekt gefällt mir sehr, nur dummerweise Flashe ich die meisten Projekte von mir über die swd / jtag pins. Die sio ist meistens nicht erreichbar, oder das ganze funktioniert nicht richtig (f407). Hast du mal dran gedacht die anderen Schnittstellen einzubauen?
Hallo Frank, könntest du mir vielleicht deine .bin Datei exemplarisch zukommen lassen, so dass ich ausschließen kann dass ich beim Erstellen der Datei einen Fehler mache. Zudem die Frage bzw. eine nähere Info: Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der Flash heißt)... lg stefan
Stefan schrieb: > könntest du mir vielleicht deine .bin Datei exemplarisch zukommen lassen Siehe Anhang. Stefan schrieb: > Zudem die Frage bzw. eine nähere Info: > Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese > Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch > irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der > Flash heißt)... Keine Ahnung. Ich dachte, NodeMCU heißt NodeMCU? Der Flash-Button ist normal. Diesen aktiviert die Arduino-IDE beim Flashen über den RTS-Pin des UARTs. Wenn man ein Flash-Programm benutzt, welches zwar den UART benutzt aber den RTS-Pin nicht bedienen kann, muss man den Button selber drücken. Schlag mich nicht, wenns CTS und und nicht RTS ist. So genau weiß ich das auch nicht, was da die Arduino-IDE beim Flashen über den UART genau macht.
Peter schrieb: > Hast du mal dran gedacht die anderen Schnittstellen einzubauen? Der OTA-Flasher nutzt den internen Bootloader des STM32. Ein Flashen über SWD/JTAG ist eine komplett andere Geschichte. Ist das Flashen über SWD überhaupt irgendwo öffentlich dokumentiert?
Ich denke schon das das Protokoll bekannt ist. Denn irgendwie müssen die ganzen open-source Debugger es ja auch gefunden haben. Wie gesagt für mich wäre es die beste Lösung weil ich selten an die sio komme, eigentlich nur ein Projekt von gut 27 und das ist dann auch noch ein f407 der Probleme mit dem bootloader hat. Ist halt bei mir so gebaut und nicht unbedingt so bei den meisten anderen.
Frank M. schrieb: > Ist das Flashen über > SWD überhaupt irgendwo öffentlich dokumentiert? Im CoreSight Kern der Cortex-M, da gibt es dicke Dokumente bei ARM. Im Prinzip ist das auch in BMP drin: https://github.com/blackmagic-debug/blackmagic Das ist mit libopencm3 gebaut, aber nicht so modular das die Logik einfach in andere Projekte einzubauen ist. Ich habe mir mal einen Remote Debugger auf Basis von Mbed gebaut und die Quellen entsprechend geändert. Das war aber zuviel um das einfach in den main branch zu mergen. Immerhin ist ein low level Teil als Treiber mit Funktionszeigern drin und libopencm3 wird nicht verwendet wenn es als 'Hosted' Version kompiliert wird, dann wird aber auch einiges andere umgestellt. Also ziemliche Fummelei. Das lesen der Binärdatei übernimmt bei BMP der gdb, und der sendet dann die zu programmierenden Blöcke an den gdbserver in BMP. Das sind überschaubare Kommandos die eine eigene SW dann aufrufen muss. Komplizierter ist das Debuggen, da gibt es doch jede Menge Sonderbehandlung für die verschiedenen Cortex Kerne und Derivate. Es gibt wie Anfangs geschrieben auch eine ESP32 Portierung, damit läuft BMP dann wireless. Hatte ich auch mal probiert und es funktionierte gut. BMP ist aber gerade aktuell bei V 1.9, der ESP Port benutzte noch eine V1.7.x. Auch das ist nicht im original Repo sondern in einem Fork, wie aktuell das jetzt ist weiß ich nicht. https://github.com/Ebiroll/esp32_blackmagic sieht nicht sehr lebendig aus. Meinen Remote Debugger habe ich bisher nicht mehr gebraucht, ich habe an dem Remote Platz jetzt einen PC und arbeite von meinem Windows PC über VSCode remote auf einem Linux PC an dem die HW steckt. Das funktioniert absolut transparent und zuverlässig.
:
Bearbeitet durch User
Frank M. schrieb: > Stefan schrieb: >> könntest du mir vielleicht deine .bin Datei exemplarisch zukommen lassen > > Siehe Anhang. > > Stefan schrieb: >> Zudem die Frage bzw. eine nähere Info: >> Ich verwende eine Amica NodeMCU und bin mir nicht sicher ob diese >> Hardware kompatibel zu deinem Projekt ist bzw. ob ich hier noch >> irgendeinen Pegel manuell setzen muss (auf dem Board ist ein Button der >> Flash heißt)... > > Keine Ahnung. Ich dachte, NodeMCU heißt NodeMCU? > > Der Flash-Button ist normal. Diesen aktiviert die Arduino-IDE beim > Flashen über den RTS-Pin des UARTs. Wenn man ein Flash-Programm benutzt, > welches zwar den UART benutzt aber den RTS-Pin nicht bedienen kann, muss > man den Button selber drücken. Schlag mich nicht, wenns CTS und und > nicht RTS ist. So genau weiß ich das auch nicht, was da die Arduino-IDE > beim Flashen über den UART genau macht. Hallo Frank, ich hab meinen Fehler gefunden... Ich verwende an meinem Rechner den Opera Browser und scheinbar geht bei dem der Update des ESP mit deinem Sketch nicht. Ich hab das aber leider erst fest gestellt als ich die Beispiele der Bibliothek getestet habe. Beim Edge Browser funktioniert der Update wunderbar und auf anhieb. Danke dir nochmals für deine Unterstützung! lg stefan
Stefan schrieb: > Ich verwende an meinem Rechner den Opera Browser und scheinbar geht bei > dem der Update des ESP mit deinem Sketch nicht. Gut zu wissen. > Beim Edge Browser funktioniert der Update wunderbar und auf anhieb. Nicht nur da. Auch bei Firefox und Chrome funktioniert es.
Hallo, das ist genau das, was ich suche. Ich habe es zur Probe mit einem STM32F0Discovery Board versucht und mit einem F767ZINucleo. Leider bekomme ich bei beiden dasselbe Ergebnis. Sobald ich auf Flashen drücke, startet mein Programm sofort wieder (Blinkende LED) und danach erst kommt das: Start Bootloader Trying to enter bootloader mode... Timeout Trying to enter bootloader mode... Timeout Trying to enter bootloader mode... Timeout Trying to enter bootloader mode... Timeout End Bootloader Ich habe Boot0, NRst, PC13 & PC14 angeklemmt und die ST-Link Jumper herausgezogen.
Anatol G. schrieb: > Ich habe es zur Probe mit einem STM32F0Discovery Board versucht und mit > einem F767ZINucleo. > .... > Ich habe Boot0, NRst, PC13 & PC14 angeklemmt und die ST-Link Jumper > herausgezogen. Wenn ich das richtig sehe, ist auf dem STM32F0Discovery Board ein STM32F051xx. Laut AN2606 von STM bietet dieser als Bootloader-Pins lediglich folgende Pins an: - USART 1: TX=PA9, RX=PA10 - USART 2: TX=PA14, RX=PA15 Der Der STM32F767 bietet folgende Pins an: - USART 1: TX=PA9, RX=PA10 - USART 2: Keine - USART 3: TX=PB10, RX=PB11 - USART 3: TX=PC10, RX=PC11 Über PC13 und PC14 als mögliche USART-Bootloader-Pins finde ich da nichts. > Sobald ich auf Flashen drücke, startet mein Programm sofort wieder Das sieht nach falsch angeschlossenem BOOT0-Pin aus. Oder ist der gar per Jumper auf dem Board auf einen fixen Pegel festgezurrt?
:
Bearbeitet durch Moderator
Uff mein Fehler, aber PA9 und PA10 habe ich zuvor auch schon getestet. Und jetzt nochmal (auch PA14 und PA15). Leider keine Änderung. Oder muss ich beim ST vorher bei UART 1 was einstellen?
PA9/10 sind fest mit dem UART vom STLink verbunden, bzw. über eine SBxx (solder bridge). Findet sich im Manual vom Nucleo welche da benutzt sind.
Angehängte Dateien:
CubeMX hat PA13 und PA14 festgelegt. Aber auch da das Problem
Anatol G. schrieb: > Leider keine Änderung. Zum Nucleo STM32F767 finde ich in UM1974: "Default state of BOOT0 is 0. It can be set to 1 when a jumper is plugged on the pins 5-7 of CN11" Ziehe mal bitte das Verbindungskabel BOOT0 -> ESP8266 ab und verbinde BOOT0 mit dem direkt daneben liegenden Pin5 (VDD) per Jumper. Wenn Du nun den Reset-Taster drückst, blinkt dann Deine LED noch? Fall a: Blinkt nicht: Der STM32 ist jetzt im Bootloader-Mode. Deine Verbindung BOOT0 -> ESP8266 ist aber nicht korrekt. Du könntest in diesem Zustand trotzdem mal im Webinterface des ESP das Flashen probieren. Wenn das dann erfolgreich durchläuft, wird Dein STM32 wg. dem Jumper zwar nicht booten, aber zumindest weisst Du dann, dass es nur noch an der Boot0-Verbindung liegt. Zwei mögliche Unterfälle: - Kabelverbindung defekt - Falscher Pin am ESP8266 Fallba: Blinkt immer noch: Du hast evtl. den falschen Pin als BOOT0 auf dem Nucleo ausgemacht. Sonst wäre noch ein Foto Deines Test-Aufbaus sinnvoll.
J. S. schrieb: > PA9/10 sind fest mit dem UART vom STLink verbunden Stimmt das? Bei den STM32F4xx-Nucleos ist es USART2, konkret PB2/PB3. Kann sein, dass das beim STM32F7xx-Nucleo anders ist. Dann fällt PA9/PA10 flach, solange man nicht die Solder-Jumpers zum STLink weglötet.
Angehängte Dateien:
-
IMG_2143.jpg
240 KB
Also mein 767 führt irgendwie keinen Code aus und hat wohl ein anderes Problem. Beim F0 ändert sich nichts, wenn ich BOOT0 auf High oder LOW setze. Kable habe ich schon mehrmals getauscht und die Verbindung ist von D2 -> Boot0.
Angehängte Dateien:
-
usart2-stm32f051.png
80 KB
Anatol G. schrieb: > CubeMX hat PA13 und PA14 festgelegt. Aber auch da das Problem. Okay, Du testest also jetzt mit dem STM32F051. Wir sollten uns da mal auf einen Typ festlegen. Ich habe nochmal AN2606 überprüft. Da steht PA14/PA15. Und ich habe mal im STM32F051 Datenblatt nachgeschaut. Auch da wird PA14 als TX und PA15 als RX für USART2 angegeben. Entweder hat CubeMX eine Macke oder einer von uns ist im falschen Film ;-).
:
Bearbeitet durch Moderator
Ja wir bleiben beim STM32F051. Ich habe nun ESP-RX -> PA14 verbunden und ESP-TX -> PA15. Auch ohne Erfolg. Boot0 auf high oder low macht keinen Unterschied. Wenn NRST auf high ist, blinkt es und auf low nicht mehr. Auf dauerhaft low gehts aber auch nicht.
Ach in deiner Tabelle ist auch zusehen SWDIO und SWCLK sind auf PA13 & PA14 der SWD ist also nicht an den Usart gebunden.
Anatol G. schrieb: > die Verbindung ist von D2 -> Boot0. Hier die notwendigen Verbindungen, nachzulesen in stm32flash.cpp:
1 | STM32 NodeMCU |
2 | RST D2 GPIO 4 |
3 | BOOT0 D1 GPIO 5 |
4 | UART-TX D7 GPIO 13 RXD2 |
5 | UART-RX D8 GPIO 15 TXD2 |
6 | GND GND |
Die Tabelle kennst Du wahrscheinlich bereits. Im Original fehlt GND <->
GND, aber das hielt ich für selbstverständlich. GND ist verbunden?
> Beim F0 ändert sich nichts, wenn ich BOOT0 auf High oder LOW setze.
Dein Blink-Programm läuft nach Drücken von RESET in beiden Fällen
weiter? Dann stimmt was mit Deinem BOOT0-Pin nicht. Zeig mal bitte auf
einem Foto, wo Du ihn ausgemacht hast.
In UM1525 zum STM32F0-Discovery-Board finde ich auf Seite 19/41:
SB2 (BOOT0) - ON:
BOOT0 signal of the STM32F051R8T6 MCU is held low through a
510 Ohm pull-down resistor.
SB2 (BOOT0) - OFF:
BOOT0 signal of the STM32F051R8T6 MCU can be set high through a
10 KOhm pull-up resistor R27 to solder.
Hast Du den Jumper SB2 abgezogen?
:
Bearbeitet durch Moderator
Anatol G. schrieb: > Ach in deiner Tabelle ist auch zusehen SWDIO und SWCLK sind auf PA13 & > PA14 > der SWD ist also nicht an den Usart gebunden. Der STM32-OTA-Flasher benutzt kein SWD, sondern USART.
Frank M. schrieb: > Hast Du den Jumper SB2 abgezogen? Sorry, das ist ja eine Brücke. Naja, der ESP8266 sollte den Pulldown von 512 Ohm auch bei kurzgeschlossener Brücke überwinden, d.h. auf High-Pegel ziehen können. Irgendwas stimmt mit Deinem Boot0-Pin trotzdem nicht. Wenn man ihn manuell auf High zieht, darf der STM32F0 eigentlich nicht mehr starten.
Fehler gefunden, und zwar D1 und D2 vertauscht und RX und TX vom ESP genommen statt D7 und D8. Ich hatte zuerst einen anderen Code, bei dem das so war und habe es verwechselt. Sorry Leute, mein Fehler, aber danke für die Hilfe. So die Tage muss ich mal gucken, ob ich das auch auf mein custom Board mit U599 und einem Code der 2,4 MB groß ist über einen ESP8266 Pro mit 16MB läuft.
Beitrag #7514103 wurde vom Autor gelöscht.
Angehängte Dateien:
-
ESP-STM32.png
120 KB
Wenn ich mir Dein Foto anschaue, benutzt Du am ESP8266 die Pins GPIO1 und GPIO3 für TX/RX. Das ist auf jeden Fall falsch. Es muss aber GPIO13/15 benutzt werden - wie in meiner Tabelle angegeben. Ich sehe auch, dass das kein NODE-MCU ist, sondern ein ziemlich nackter ESP8266-12F (oder -E). Ich habe das mal für das kleine ESP-Modul und den STM32F051 aufgemalt, siehe Anhang. EDIT: Du warst schneller, trotzdem ist das Bild nützlich hier :-) Viel Spaß mit dem OTA-Flasher!
:
Bearbeitet durch Moderator
Kann man eigentlich einstellen, dass ich im Browser nicht die ip eingeben muss, sondern einen festen Namen? Also wie z. B. bei einer fritzbox, da muss man ja auch nur Fritz.box eingeben. Das wäre auch eine nützliche Funktion.
Anatol G. schrieb: > Kann man eigentlich einstellen, dass ich im Browser nicht die ip > eingeben muss, sondern einen festen Namen? Zur Zeit kann man das nicht einstellen, ich weiß aber, dass das mit dem ESP über WiFi.hostname() machbar ist. Ich schreibs mir mal auf die Todo-Liste. Schau mal in der FritzBox nach, welchen Namen die Fritzbox für das verbundene Gerät im WLAN angibt. Es kann sogar sein, dass Du das Gerät dort umbenennen kannst. Der angezeigte Name sollte jedenfalls auch statt der IP im Browser gehen. Ich persönlich ziehe mir die URL einfach in meine Lesezeichenliste und verpasse dann dem Lesezeichen einen passenden Namen.
Anatol G. schrieb: > Gibt es den code auch für ESP32? Nein, gibt es nicht. Die Portierung sollte aber nicht so schwierig sein. Wenn ich mal Zeit habe, kann ich das ja mal anpacken.
hat soweit geklappt bis auf http.cpp und natürlich muss man danach noch die Pins anpassen.
Super, vielen Dank! Das schaue ich mir gleich mal an.
ich habe in der http.cpp das geändert und es hängt jetzt noch am File System
1 | //#include <ESP8266WebServer.h> |
2 | #include <WebServer.h> |
3 | //#include <ESP8266mDNS.h> |
4 | #include <ESPmDNS.h> |
5 | //#include <ESP8266HTTPUpdateServer.h> |
6 | #include "ESP32HTTPUpdateServer.h" |
7 | #include <FS.h> |
8 | #include <LittleFS.h> |
9 | |
10 | #include "STM32OTAFlasher.h" |
11 | #include "http.h" |
12 | #include "eepromdata.h" |
13 | #include "stm32flash.h" |
14 | |
15 | /*---------------------------------------------------------------------------------------------------------------------------------------- |
16 | * global data: |
17 | *---------------------------------------------------------------------------------------------------------------------------------------- |
18 | */ |
19 | static const char * host = "stm32flasher"; |
20 | |
21 | WebServer httpServer(80); |
22 | ESP32HTTPUpdateServer httpUpdater; |
23 | String sResponse; |
1 | void http_loop (void) |
2 | {
|
3 | httpServer.handleClient(); |
4 | //MDNS.update(); |
5 | } |
Okay, alles klar, ich werde mir das nächste Woche mal selbst anschauen. Einen oder zwei ESP32 habe ich schon seit längerem zuhause rumliegen, jedoch hatte ich bisher noch keine Motivation, die Dinger mal auszuprobieren.
Ich bleibe auch weiter dran. Muss noch eine i2C Verbindung zum stm32u5 aufbauen und eine i2S zum DAC für ein Internetradio. Deswegen auch der ESP32, da mir die Pins ausgegangen sind.
Ich habe es nicht mit LittleFS hinbekommen also habe ich SPIFFS eingebunden. So bekomme ich den Code kompiliert und komme auf die seite im Browser. Aber beim Hochladen von einer Datei oder beim Sprung auf die Flash-Seite hängt sich der ESP32 auf. Es wird wohl noch am Dateisystem hängen. Zum Flashen habe ich den Serial2 eingestellt. Pin 16,17 boot0 = 32 nRST = 33 Ich bin jetzt auch auf PlatformIO umgestiegen.
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.