Das IoT Board mit dem ESP8266
« | 23 Jan 2019 | »Da verkauft mir der liebe Conrad doch glatt so einen Chip mit dem Titel “Das IoT Board”. Und dann sitze ich verzweifelt vor einer Firmware, die offenbar schon mehrere Jahre alt und praktisch nicht zu gebrauchen ist.
Firmware-Update?
Ja klar doch. Und dann geht gar nichts mehr.
Die kleinen ESP8266-01 Modelle sind recht kostengünstige Chips, die sich in ein WLAN hängen oder selbst einen Access-Point bereitstellen können.
Da sie aber nur mit 3.3 Volt umgehen können und schwerer zu programmieren sind, als z.B. Arduino Boards, gibt es die Möglichkeit auf dem ESP Chip eine spezielle AT-Firmware zu übertragen und ihn gemeinsam mit einem Arduino zu betreiben.
Der Arduino übernimmt die Programmlogik und Sensorverwaltung und schickt dem ESP8266 über die serielle Schnittstelle AT-Kommandos um Daten ins WLAN zu übertragen.
Das obige IoT Board fasst das alles auf eine Platine zusammen, verbindet
einen Arduino Nano mit einem ESP8266-01 und man könnte meinen:
“Super, alles fix fertig.”
Doch die Firmware auf dem ESP des Boards war offenbar mehr als alt und kannte viele relevante AT-Befehle nicht.
Zum Glück kann man aber die 8 üblichen Pins eines ESP8266-01 anlöten und über einen Programmer eine neuere AT-Firmware hochladen.
Doch hier beginnt das kleine große Chaos.
Denn die vorgefertigten Programmierbeispiele zwischen dem Arduino ATmega328P und dem ESP8266 setzen voraus, dass der ATmega mit dem ESP über das Software-Serial Interface redet, und zwar mit einem fixen Baudrate von 19200.
Wenn man aber neue Firmware-Binaries aus dem Netz herunterlädt, legen diese die Kommunikation auf 115200 Baud fest (also über 8 mal schneller). (Natürlich sind auch andere Werte möglich.)
Die Software-Serial Schnittstelle des ATmega328P ist aber bekannt dafür,
dass sie empfangene Bytes verliert, wenn nicht ständig in einer Schleife auf
neue Bytes geprüft wird.
Und je höher die Baudrate, desto mehr geht verloren.
Kurz zusammengefasst: Mit der neuen Firmware kam keine Kommunikation zwischen den beiden MCUs mehr zustande.
Also, was macht man nun?
Es war schon schwer genug, die richtigen AT-Firmware-Dateien im Netz samt Flash-Tool zu finden und die Quellen für die Firmware selbst zu suchen, aufzusetzen und zu kompilieren war mir einfach zu mühsam.
Lösung
Mein alter Freund, der HEX-Editor half mir weiter.
Ich suchte zuerst gezielt nach dem Zahlenwert 115200 in der Binärdatei.
Die 00 01 C2 00 konnte ich nicht finden, aber 00 C2 01 00 hingegen schon.
Natürlich! Little-Endian! Alles wird verkehrt herum gespeichert.
Um auf Nummer Sicher zu gehen, pflanzte ich an jene Stelle den Wert
80 25 00 00 was 0x00002580 oder 9600 im Dezimalsystem bedeutet.
Nach dem Upload der “gepatchten” Binärdatei war eine Verbindung mit
der Baudrate 9600 möglich und in ersten Tests gingen mir zumindest keine
Bytes verloren.
Außerdem sollte 9600 für einfach Anwendungen mehr als genug sein,
schließlich kann man sich ohnehin keine besonders langen Nachrichten
auf einem Mikrocontroller zusammensetzen lassen.
Für gewöhnlich akzeptiere ich die höheren Preise unserer lokalen Anbieter, weil sie Dokumentation und Support für ihre verkauften bereit stellen.
Doch hier muss ich schon sagen, dass ich mir einen solchen Patch vom Hersteller vor der Auslieferung erwartet hätte und man nicht selbst stundenlang selbst eine Lösung erarbeiten muss.
However … wieder etwas gelernt und einen sonst “nutzlosen” Chip gerettet. Letztendlich freut man sich dann doch über das Erfolgserlebnis mit dem sogenannten “IoT-Board”.