ESP8266 und WeMos Board's programmieren

Eigenschaften, Besonderheiten und Probleme bei der Programmierung

ESP8266 und die Verwendung als Microcontroller für eigene Programme

Verwendet man die Arduino-MC's für eigene Programm-Projekte so könnte auch der ESP8266 neben dem WiFi-Zugang genug Platz für eigene Programme bieten. Der eingesetzte Prozessor ist schneller , hat mehr Flash- und RAM-Speicher und läßt sich genau so leicht programmieren wie der Arduino. Eigentlich wäre er damit ein idealer Nachfolger um von den Arduino-Boards auf ESP-Board (z.B. WeMosD1R2 = UNO) umzusteigen. Aber es gibt einige Besonderheiten die unbedingt beachtet werden müssen.

Benutzung der GPIOs 15, 0, 2

Diese GPIOs sind nur eingeschränkt als Eingang bzw. Ausgang nutzbar. Nach einem Reset müssen die GPIOs 15 , 0 und 2 unbedingt auf diesen Spannungslevel stehen :

GPIO 15	GPIO 0	GPIO 2	Mode	Verwendung
LOW	HIGH	HIGH	Flash	Boot vom SPI-Flash (normal)
LOW	LOW	HIGH	UART	Prog. über UART (TX/RX)
HIGH	x	x	SDIO	Boot von der SD Karte

Die Verwendung ist also möglich, nach dem Bootvorgang (im Setup) kann man sowohl Inputs oder Outputs programmieren. Während des Bootvorgang sind zunächst alle GPIOs als Input definiert. Achten sie bei der Verwendung auf entsprechende Pullup- bzw. Pulldown- Widerstände.

Verwendung von Libraries

Es ist unbedingt bei der Verwendung von Libraries darauf zu achten, dass diese ESP8266 kompatibel sind. Die wichtigsten sind bereits in dem ESP-Core enthalten. Bitte informieren sie sich in dieser Core-Beschreibung über die Details.

Programmierung von Schleifen bzw. Polling : Verwendung von delay(0) oder yield()

Bei Schreiben eigener Programme ist folgendes extrem wichtig und muß unbedingt beachtet werden. Der ESPP8266 enthält bereits ein umfangreiches Programm zum WiFi -Management. Das eigene Programm wird nur angebunden bzw. an den internen "WiFi-Loop" angehängt. Der WiFi-Progammteil des 8266 muß nun regelmäßig durchlaufen werden um den Absturz des Programms zu verhindern. Eine Unterbrechung der WiFi-Routinen von ca. 20 msek scheint noch verträglich, alles darüber für zu einem Reboot oder Reset des Programms. Dies ist ein grundsätzliches Problem beim Schreiben eigener Programme, vor allem falls Libraries verwendet werden, deren Programm-Aufbau nicht direkt bekannt ist. Eine Übernahme vorhandener Arduino-Programme ist somit nicht ohne weiteres möglich. Einen Ausweg gibt es durch die Verwendung der delay(0) oder yield() Funktion. Die Funktion gibt dem WiFi-Management Zeit die erforderlichen Aufgaben abzuarbeiten, verzögert jedoch u.U. die eigene Routine. Stürzt das Programm sporatisch ab bzw. wird ein Reboot durch den WDT ausgelöst kann das Einfügen von delay(0) oder yield() Funktionen (z.B. in while-Schleifen) die Situation verbessern. Eine absolut sichere Maßnahme ist das jedoch nicht. Die Suche nach den wirklichen Problemen gestaltet sich demnach schwierig. Treten diese Fälle häufig auf, kann ein debuggen mit dem Monitor zu richtigen Spur führen. In einem eigenen Projekt waren diese Probleme aber eher selten (alle 1-2 Tage) und somit praktisch nicht lokalisierbar.

Hinweise zur internen Speicherverwaltung - Stack/Heap: Verwendung von Strings u.a.

Für die eigene Programmierung stehen (nur) 4kByte Stack zur Verfügung. Lokale Variable dürfen also insgesamt nicht mehr Speichplatz belegen. Variable und Pufferspeicher sollten global deklariert werden. String-Objekte werden im RAM abgelegt, verwenden sie für lange Strings möglichst PROGMEM oder die F() Variante um diese Strings in den Flash-Speicher auszulagern. Die Speicherverwaltung auf dem Heap ist besonders kritisch - bei einer Fragmentierung stürzt das Programm unweigerlich ab. Um die Nutzung des Heap möglichst gering zu halten sollten bestimmte Operatoten nicht benutzt werden: alloc(), malloc() new() und leider auch Strings. Fassen sie Client.print() oder Client.write() Aufrufe zu möglichst langen Ethernet-Paketen zusammen. Die max. Paketgrösse wird immer automatisch ermittelt und gesendet. Der Empfangspuffer über Client.available() und Client.readByte() darf beim Auslesen nicht überladen werden. Interrupt-Routinen sind besoders heikel. Sie sind grundsätzlich möglichst schnell zu beenden und müssen mit einem ICACHE_RAM_ATTR gekenzeichnet werden.

Stabilitätsprobleme und die Hardware

Von den gerade beschriebene Problemen einmal abgesehen, kann auch die verwendete Hardware Einfluß auf die Stabilität des Projektes habe. Erfahrungen zeigen, dass die Versorgungsspannung des ESP8266 stabil und "leistungsfähig" sein muß. Das erreicht man durch "Stütz"- Kondensatoren direkt an den Betriebsspannungs-Pins von min. 470 uF und zusätzlich 100nF. Die oben genannten GPIOs , der CH_PD Pin und der Reset Pin sollte sicher auf dem notwendigen Pegel gezogen werden, hier sind 2,2 k - 4,7K den üblichen 10k vorzuziehen.

Die Reset-Funktion

Der Reset des MC nach dem Einschalten der Betriebsspannung und auch der Reset-Taster funktioniert einwandfrei. Anders sieht es bei einer kurzzeitigen Stromunterbrechung aus. So habe ich festgestellt, dass kurze Unterbrechungen der Betriebspannung den MC nicht sicher rebooten läßt. Das ist für den sicheren Betrieb eines Projektes mit dem ESP8266 aber unerlässlich. Von 10 Versuchen hängte sich das Programm min. 5x auf. Abhilfe würde ein externer Resetbaustein der die Versorgungspannung überwacht bringen - aber wer ist schon bereit diese Zusatzhardware zu spendieren? So etwas sollte bereits integriert sein.

Impressum