|
|
Elektronik-Dachbude |
|
|
|
Elektronik-Dachbude |
|
Auf
3,3V umgebautes FTDI-Board mit aufsteckten
Steckverbindungen (damit die Kabel passen)
Angesteuert wird das Modul über eine serielle Schnittstelle, ebenfalls mit 3,3-V-Pegeln. Deswegen habe ich ein umgebautes FTDI-Board benutzt, wie auf
dem Bild ersichtlich. Allerdings muss man die einen oder
anderen
Besonderheiten beachten.
Pinbelegung
des Moduls von unten
Dies ist das Pinout
des Moduls von unten (auf meisten
anderen Seiten andersherum!). In meinem ersten Versuch habe
ich das Modul
ganz gewöhnlich mit Spannung versorgt, und RXT
und TXD über kreuzt (RXD mit TXD vom FTDI-Board verbinden und
andersherum)
mit den Pins des FTDI-Boards verbunden. Die rote PowerLED des Boards
hat auch
geleuchtet, allerdings blieben alle Kommunikationsversuche ohne
Reaktion. Nach ein
wenig Recherche fand ich schließlich
raus, dass der PD Pin auf High
geschaltet werden muss. Doch als ich den Pin mit VCC vom FTDI-Board
verbunden
habe, kam der USB-Disconect-Sound und das Modul war Spannungslos. Ich
dachte
zunächst, dass ich den Reset-Pin erwischt hätte. Es hat sich allerdings
rausgestellt, dass die Leistung des
FTDI-Boards in dieser Konstellation tatsächlich nicht ausreichte. Auf einer Seite habe ich
gelesen, dass das
Modul beim Start bis zu 80mA
benötigt.
Also musste ich eine externe
Spannungsquelle dazuschalten.
Nun ist das aufgetreten, was in
mehreren Quellen beschrieben
wurde: Beim Einschalten blinkt die blaue StatusLED kurz auf und die
rote PowerLED
bleibt konstant an. Bei geöffneten Arduino Terminal erscheint zudem
folgende
Meldung:
Ein erster Erfolg: Die Kommunikation steht.
Die erste Verbindung war nun bereits
insofern erfolgreich,
dass Daten die das Modul geschickt hat, ausgelesen werden konnten. Ob
auch
Daten in Form von Befehlen an das WLAN-Modul gesendet werden können
steht also
noch nicht fest. Dazu benötigen Sie nun wieder ein Terminal Programm –
am besten
den Serial Monitor der Arduino Software.
Sie können zwar auch andere Terminals benutzen, allerdings werden die
Befehle
nur erkannt, wenn sie in einem besonderen
Format geschickt werden. Sie müssen nämlich nach
jedem Befehl nicht nur das <CR> (Carriage Return)
Zeichen, sondern
auch das NL (New Line) Zeichen senden. Die meisten
Terminalprogramme senden
CR wenn Sie Enter drücken, allerdings nicht NL. Im Arduino
Terminal lässt sich diese Funktion einstellen, wie Sie auf
dem unteren Bild sehen können.
Die Baudrate
betrug
bei mir übrigens 9600. Auf diversen Seiten habe ich aber auch
von einer Standarteinstellung von 115200 oder
57600 gelesen.
Wenn Sie also Nichts oder
nur Kauderwelsch empfangen, probieren Sie ein bisschen mit der Baudrate
herum.
Wenn Sie beim Einschalten des Moduls den Text empfangen ist das ja
schon ein
gutes Zeichen, dass die Baudrate stimmt. Nun können Sie testen, ob Sie
Befehle
senden können. Bei den Befehlen handelt es sich um sogenannte AT-Befehle (at steht für attention).
Das erste Kommando das Sie ausprobieren können lautet einfach AT. Es sollt ein einfaches OK
zurückkommen. Das Kommando hat keine
Funktion, außer dass Sie nun wissen, dass die Kommunikation einwandfrei
funktioniert.
Sie können nun auch einen der folgenden Befehle ausprobieren:
AT+GMR
Gibt Firmware Version aus
AT+RST
Resetet
den Controller
AT+CIOBAUD=<baudrate>
Stellt neue Baudrate ein (in diskreten
Werten bis 921600)
AT+CIOBAUD?
Fragt die aktuelle
Baudrate ab
Sie sollten immer
auf
die Großbuchstaben achten, sonst kommt ein Error zurück.
Übrigens können
Sie bei fast allen Befehlen ein
Fragezeichen anhängen, um die aktuelle Einstellung abzufragen.
Nun wird es Zeit das Modul mit einem
anderen WLAN-fähigen
Gerät verbunden werden. Es gibt drei
Varianten, wie sich das Modul dabei verhalten soll.
Die erste Variante ist das Modul als AccesPoint zu verwenden. Das
bedeutet, dass das Modul
sozusagen wie ein Router funktioniert
und ein WLAN-Netzwerk bereitstellt.
Andere Geräte, wie z.B. Smartphones können sich dann in dieses Netzwerk
einwählen. Die Verbindung zwischen Modul
und Handy ist also direkt. Der Vorteil
ist vor allem, dass kein Router oder
WLAN vorhanden sein muss.
Die zweite Variante ist, dass das Modul als Client funktioniert. Das
bedeutet, dass das sich das Modul mit einem
bestehenden, z.B. von einem
Router bereitgestellten WLAN, verbindet. Dazu muss natürlich
das WLAN-Passwort vorhanden sein.
Der Vorteil ist hier natürlich,
dass von allen Geräten im WLAN auf das Modul
zugegriffen werden kann. Außerdem kann das Modul über einen
Router der mit
dem Internet verbunden ist, auch auf das Internet zugreifen.
Die dritte Variante ist, dass das
Modul beide oberen Varianten gleichzeitig
zu Verfügung stellt. Es können
Sich also Geräte direkt mit dem Modul als
AP verbinden oder über den Router
eine Verbindung aufbauen.
Um den Controller als reinen
AccesPoint einzustellen müssen Sie den Befehl AT+CWMODE=2
senden. Dies ist meist auch die Standarteinstellung des
Moduls. Nun können Sie ein anderes WLAN-Fähiges Gerät nehmen und das
die SSID
(=WLAN-Name) des Moduls suchen. Auf dem Bild habe ich meinen Rechner
benutzt um
die SSID zu finden. Der Name lautete ESP_9EE10B.
Wenn Sie nun auf das WLAN-Netz
klicken, wird automatisch
eine Verbindung aufgebaut. Ein Passwort
ist nicht nötig, da keins definiert wurde. Mit dem Befehl AT+CWLIF können Sie alle
verbundenen Clients anzeigen
lassen. Über den folgenden Befehl können Sie den Netzwerknamen ändern
und ein
Passwort sowie andere Parameter einstellen:
AT+CWSAP="<ssid>","<pass>"[,<chan>,<enc>]
<ssid>
= SSID
<pass>
= Password
<chan>
= Kanal 1...14
<enc> =
Verschlüsselung: 0 = Offen, 1 = WEP, 2 =
WPA_PSK, 3 = WPA2_PSK, 4 WPA_WPA2_PSK
Wenn Sie das Modul als Client
verwenden möchten, müssen Sie
zunächst die Einstellung CWMODE auf 1
oder 3 (für AP und Client) setzen. Also mit z.B. folgendem
Befehl: AT+CWMODE=1.
Nun können Sie zunächst einmal nach
bestehenden Netzwerken suchen und zwar mit dem Befehl AT+CWLAP. Nach einer kurzen Zeit werden
alle gefundenen
WLAN-Netzwerke aufgelistet.
Sie können sich nun mit folgendem
Befehl mit einem der Netzwerke verbinden:
AT+CWJAP="<ssid>","<pass>"
<ssid>
= SSID
<pass> = Passwort
Wenn der Verbindungsaufbau
erfolgreich war erscheint die
Meldung OK.
Mit dem Befehl
AT+CIFSR kann nun die aktuelle IP ausgegeben werden.
Sollten Sie das Modul im AP und
Client Modus simultan laufen haben, werden hier zwei IPs angezeigt. Die Daten des WLANs sowie die meisten andere Einstellungen bleiben übrigens gespeichert. Das
bedeutet,
dass sich das Modul auch nach
wiederanschließen an eine Spannungsversorgung automatisch mit dem
gespeicherten
WLAN verbindet.
Die Verbindung zu anderen Geräten steht nun, egal ob Sie das
Modul als AP oder als Client benutzen. Doch nun sollten die Geräte auch
miteinander kommunizieren können. Deswegen wird in diesem Teil ein Server
eingestellt. Auf diesen Server kann dann z.B. über ein Handy zugegriffen und
Daten übermittelt werden. Doch der Reihe nach.
Zunächst einmal muss eine Einstellung vorgenommen werden und
zwar die Einstellung AT+CIPMUX=1.
Dies ermöglicht, mehrere Verbindungen
gleichzeitig aufbauen zu dürfen. Ich habe noch nicht genau herausgefunden
warum diese Einstellung nötig ist, Tatsache ist aber, dass sich der Server nicht starten lässt wenn diese
Einstellung nicht gemacht wurde. Ein wichtiger Punkt ist, dass sich diese Konfiguration nicht speichert.
Das bedeutet, Sie müssen diesen Befehl jedes
Mal neu eingeben, wenn Sie das Modul neu eingeschaltet oder resetet haben.
Nun können Sie den Server
mit dem Befehl AT+CIPSERVER=1,80 starten. Der zweite Parameter, also die 80, ist der Port, über den der Server erreicht werden kann. Sie können hier
auch einen anderen Port verwenden. In diesem Beispiel ist der Server aber unter
dem Port 80 zu erreichen.
Nun wird es spannend. Sollte das Starten des Servers mit OK
bestätigt worden sein, können Sie nun versuchen den Server über ein Gerät Ihrer
Wahl zu erreichen. Wenn Sie sich nicht mehr sicher sind, wie die IP des Moduls
lautet verwenden Sie den AT+CIFSR
Befehl. Auf dem Bild unten sehen Sie die beiden IP-Adressen. Die erste ist
gültig, wenn Sie eine direkte Verbindung über den AP benutzen, die zweite gilt,
wenn Sie über den Router das Modul erreichen möchten.
Ich versuche nun also über den PC und den Router das Modul
zu erreichen. Dazu öffne ich einen Browser und gebe die IP-Adresse des Moduls
gefolgt von einem Doppelpunkt und dem Port des Servers ein. In diesem Fall
also:
192.168.178.35:80
Wenn Sie nun Enter drücken versucht der Browser eine Seite
zu laden. Dies hat allerdings kein Erfolgt. Im Serial Monitor können Sie
allerdings sehen, dass Daten empfangen wurden:
Zunächst steht dort Link,
was verdeutlicht, dass eine Verbindung
hergestellt wurde. Dann folgen empfangene Daten. Allgemein werden empfangene Daten durch +IPD gekennzeichnet.
Danach folgen zwei Zahlen. Die erste
Zahl zeigt, welche der bestehenden
Verbindungen die Daten geschickt hat. Da z.Z. nur ein Rechner die Seite
geöffnet hat, steht dort eine 0. Eine zweite Anfrage würde dann den Index 1
bekommen usw. Die zweite Zahl gibt die
Länge der empfangenen Daten an.
Hier wurden also anscheinend 376 Zeichen empfangen. Wer möchte kann ja mal
nachzählen. Nach dem Doppelpunkt stehen nun die eben beschriebenen Daten. Es scheint sich hier um eine Anforderung zu
handeln, die allgemein beim Öffnen einer Seite vom Browser geschickt wird.
Diese Verbindung bleibt nun eine Weile stehen, ohne dass
etwas passiert. Nach in der Regel 180s =
3 Minuten, wird die Verdingung automatisch getrennt. Dies wird durch die
Meldung Unlinked verdeutlicht. Sie können die Zeit bis zur automatischen Trennung übrigens auch Einstellen und
zwar mit dem Befehl AT+CIPSTO=X
wobei X maximal 28800 für 28800s =
8h entsprechen darf.
Falls Sie sich gerade nicht sicher sind, ob und wenn ja wie viele Verbindungen zum Modul
bestehen, können Sie dies mit dem Befehl AT+CIPSTATUS
erfragen. Status 4 scheint zu bedeuten,
dass keine Verbindungen bestehen. Status 3 bedeutet anscheinend Verbindungen und wird mit einer Liste von verbunden Geräten ergänz.
Nun soll aber die Verbindung nicht völlig nutzlos sein,
sondern es sollen Daten an den Browser
geschickt werden. Dazu gibt es den AT+CIPSEND
Befehl. Dieser hat zwei Parameter, die ähnlich dem Empfangsparametern sind. Der
erste Parameter gibt also den Index der Verbindung an, der zweite die Anzahl der zu sendenden Zeichen.
Die einfachste Form von Daten sei nun ein Text. Dieser kann tatsächlich auch so
im Browser angezeigt werden. Wenn Sie also den Server im Browser andressiert
haben und eine Linked Verbindung besteht, können Sie mit AT+CIPSEND=0,5 einen Text senden. Nach eintippen des Befehls ins
Terminal erscheint ein > das
verdeutlichen soll, dass Sie nun den
Text eintippen können. Fünf Zeichen reichen für ein Hallo. Ein Wechsel zu
dem Browser ist aber leider enttäuschend, denn dort wird immer noch das Seite-Laden
Symbol angezeigt. Das liegt scheinbar daran, dass die Verbindung noch nicht
geschlossen wurde. Sie können also nun entweder die 3 Minuten warten, oder Sie schließen mit AT+CIPCLOSE=0 die Verbindung
zu diesem Gerät. Nach dem Schließen sehen Sie nun ein einfaches Hallo im
Browser.
Nach dem Eintippen dem und Senden einer Nachricht mittel CISEND erscheint übrigens oft die
Meldung wrong syntax und ERROR gefolgt von SEND OK. Das scheint vorzukommen, wenn man mehr Zeichen sendet als
vorher angegeben. Ich schätze, dass man zwei Zeichen extra eingeplant werden müssen,
vermutlich wegen dem CR und NL des Terminals. Gelegentlich trifft man aber auch
die richtige Anzahl von Zeichen und die Fehlermeldungen erscheinen nicht. Ich
muss diesbezüglich noch ein wenig rumprobieren, aber des Senden scheint nicht
beeinträchtigt zu sein.
Es gibt auch die Möglichkeit außerhalb eines Browser eine
Verbindung aufzubauen. Dazu kann ein TCP-Client
genutzt werden. Ich habe mir einen solchen Client im Google Playstore heruntergeladen und konnte so eine Verbindung herstellen und Daten hin und her schicken. Der erste
Schritt für eine App wäre also gemacht.
App: TCP-Client im Google PlayStore
Der nächste Schritt ist nun, das Modul mit einem
Mikrocontroller zu verbinden um das ganze portabler zu haben. Meine erste Wahl
war ein Arduino Nano Nachbau aus
China, den ich ebenfalls mitbestellt
habe. Dieser hat einen 3,3 V Pin so dass die Sache auf den ersten Blick ganz
einfach aussah. Tatsächlich hat das Modul aber ähnlich reagiert, wie schon bei
den ersten Versuchen mit der FTDI Platine. Das Modul startete nicht richtig.
Nach einigem Suchen fand ich auch den Grund heraus.
Auf dem Nachbau des Nanos befindet sich ein alternativer USB-To-Serial Chip. Dieser wird mit
geregelten 5 V versorgt, hat aber auch selbst einen 3,3 V Ausgang, der am entsprechenden Power-Pin der Arduino Patine
herausgeführt ist. Das Problem ist allerdings, dass dieser PIN maximal 50 mA liefern kann. Das
WLAN-Modul braucht beim Start bis zu
200mA. Laut Datenblatt kann es sogar bis zu 235 mA benötigen. Der Serial-Chip kann den Strombedarf also nicht
decken. Ein originaler FTDI Chip hätte übrigens genauso wenig genützt. Dieser
liefert ebenfalls maximal 50mA am 3,3 V-Pin.
Eine Möglichkeit das Problem zu lösen wäre, einen Spannungswandler
an den 5V Pin anzuschließen und das Modul darüber zu versorgen. Diese Variante
werde ich noch ausprobieren, doch für meinen ersten Versuch habe ich doch einen
Arduino Uno genommen. Der 3,3 V Pin
des Arduino wird nämlich über einen Spannungswandler
erzeugt und kann den nötigen Strom liefern. Für die ersten Versuche also die
besser Wahl. Der Aufbau des Versuchs sieht folgendermaßen aus:
An die Modul-Pins GND
(grauer Draht) und RXD (weiß) habe ich jeweils kurze Verbindungsdrähte
angelötet. Das Modul selbst ist leicht schräg in ein Steckboard gesteckt, so dass
die beiden oben erwähnten Pins keine Verbindung haben. Dafür kommt man über die
interne Verdahtung des Steckboards gut an die Pins VCC (gelb/orange) und TXD
(braun). Der PD Pin ist direkt
mit einer Drahtbrücke mit VCC
verbunden. RXD ist mit dem Arduino Pin 10 und TXD mit Pin11 verbunden.
VCC wird mit dem 3,3 V-Power-Pin verbunden und GND mit GND.
Wie man sieht sind RXT
und TXT nicht mit dem Serial Pins des Arduino Unos Verbunden, sondern stattdessen
mit den digitalen Pins 11 und 10. Das
liegt daran, dass ich eine softwarebasierte
Serielle Schnittstelle verwende. Dadurch bleibt die Hardwareschnittstelle
fürs Debugging frei und es gibt auch keine Probleme beim Uploaden von
Programmen.
Für den ersten Test hat sich das Beispielprogramm SoftwareSerialExample (Beispiele >
SoftwareSerial) bewährt. Ich musste
lediglich die Baudraten anpassen. Dann war es möglich über das Terminal Befehle
zu schicken und zu empfangen. Im Grunde ist dieser Aufbau in Verbindung mit diesem
Beispielprogramm auch eine gute
Alternative für alle, die kein
passendes FTDI-Board zur Verfügung
haben.
