Getting Starting - Changes to the Seeed Tutorial

After a 3 or 4 week wait, your ESP8266 Serial Wifi modules have finally arrived from China. Now what?

For a first program, most people head for the short tutorial at seeedstudios

http://www.seeedstudio.com/wiki/WiFi_Serial_Transc...

The Seeed tutorial is written for the version 1 module with a 57600 baud rate serial link. The version 2 module that is currently shipping runs at 115200 bps.

Also, the version 2 module requires 5 connections rather than the 4 shown in the tutorial. You need to pull the chip-enable (CH_PD) pin high - by connecting it to a 3.3V source via a (say) 10k resistor. The CH_PD pin is to the right of the TXD pin shown in the Seeed tutorial. (Be smart and google for an exact match to your module before wiring up.)

The tutorial uses an Arduino UNO variant. Because the module link runs at 115200, you have to use a hardware UART (serial) module to talk to it. On the UNO this is a problem, as the Uno only has one UART module. The tutorial program therefore uses a soft serial port to communicate with the monitoring PC (via an FTDI/Max232 or other TTL/Serial or TTL/USB converter).

The soft serial port can only run up to 19200 bps. You'll very quickly find that if you attempt to suck data from the WiFi module at 115k and blow it to the PC at 19k, the buffers on the WiFi module will rapidly fill and your TCP connection will be dropped.

You can save yourself a lot of hassle by picking up an Arduino Mega 2560 with 4 hardware UART modules. ("Inland" branded clones are available from Microcenter for $20.) This allows you to forward data to the monitoring PC at the same rate as it's received from the WiFi module. (A $20 Teensy 3.1 might be even better - see Conclusions below.)

In this photo you can see pins TX3, RX3,TX2,RX2,TX1,RX1 at the top right of the board. They are the transmit (TX) and receive (RX) connections for hardware UART3, UART2 & UART1. UART0 is connected to the USB port (and is broken out to the left of TX3).

Note also that in the Seeed tutorial the WifiModule is connected directly to the Arduino's TX & RX pins. You might get away with this, but you might not, and then you'll have to wait another 3 or 4 weeks for a new module. I converted the 5V serial signal from my Mega 2560 to 3.3v using a Sparkfun bi-directional level converter module. These cost about $3 and might save you tears.

On the subject of power, you'll need a separate 3.3V power supply. The WiFi module sucks more current that the 3V3 pin of an Arduino can supply.

To be ctd... If I can work out how to embed source code.

void test()
{
  
}

Wiring Up

So, connect the module's VCC pin to the positive rail of your 3.3V power supply, GND to the supply's ground rail, TX to (say) LV1 of your level converter, RX to LV2, and connect CH_PD to one end of a 10k resistor, the other of which is connected to your +3.3V rail.

The LV pin of the level converter is connected to +3.3V, GND to supply ground.

On the other side of the level converter, connect HV to your Arduino's 5V output, GND to an Arduino GND output, HV1 to RX1 and HV2 to TX1. Note that the module's transmit (TX) is the Arduino's receive (RX) and vice versa. We're using the Mega 2560's UART1 ("Serial1") to communicate with the module, so we can use UART0 ("Serial") to communicate with the PC monitor via the Arduino's USB cable.

Fritzing Diagram of Connections

Controling the Module: AT+ Commands

Just like an old-time modem, the ESP8266 is controlled by sending it "AT+" command strings via the serial line and waiting for a text response.

E.g. If you send the string "AT+GMR", module will respond by echoing the command, a blank line, printing the firmware version, another blank line and "OK".

AT+GMR

00150900

OK

A list of the AT+ commands can be found here:

https://drive.google.com/folderview?id=0BwK3EhAfht8uWTdBdG55NEFCakE&usp=sharing

Notes on AT+ Commands

Some of the AT+ commands have quirks and wrinkles. I'll document them as I find them.

AT+CWLAP : Should return a list of wifi networks ("Access Points") visible to the module. Just hangs for me, requiring a reset (by disconnecting CH_EP). I think the firmware may have trouble with "hidden" networks - i.e. those that don't broadcast their SSID. Please leave your experience in the comments for future googlers. (Another possibility is that there are too many networks visible - all my neighbours have WiFi and I have three SSIDs - maybe a buffer is overlowing in the firmware.)

AT+CIFSR : Prints the IP address assigned to the module by the router. Should also return "OK" - which it doesn't. Not a show stopper - just skip output, see below.

AT+CWJAP="linksys","0123456789" : Joins the Access Point (connects to the wifi network). I've only tested this with 64-bit WEP encrypted networks. Please leave a comment (for future googlers) if you try a WPA encryted network.

(From the "Commands" document linked in §4, there's a command AT+SAP - "Setup Access Point" - used to configure the module as an Access Point rather than as a Station. This command recognizes the following "security scheme" arguments: 0-Open, 1-WEP, 2-WPA_PSK, 3-WPA2_PSK, 4-WPA_WPA2_PSK. It seems reasonable to assume that AT+CWJAP should handle these schemes too.)

Software Overview

In pseudo-code, the structure of  the setup routine of our simple test program will be:

setup()
  Initialize "Serial" (UART0) for USB communication with the PC
  initialize "Serial1" (UART1) to link to the module.

  Pause to let the module settle.

  AT+RST: Reset the module.
  AT+GMR: Get the modules firmware ID.
  AT+CWMODE?: Get current access mode.
  AT+CWMODE=1: Set station mode.
  AT+CIPMUX=1: Allow multiple connections (we only use #0).
  
  Try 5 times to connect to the WiFi network.
  If unsuccessful, halt with :Connection Failed." message.

  Otherwise, delay 5 seconds and,
  AT+CIFSR: Display the IP address assigned to us by the router.

The body of the loop will look like:

loop()
  AT+CIPSTART=0,"TCP","192.254.235.21",80:
     Connect to retro.hackaday.com port 80
  Wait for "OK"

  AT+CIPSTATUS: Get the connection status.

  Build our HTTP request:
    "GET / HTTP/1.0\r\n\r\n" and measure the length of this string.

  AT+CIPSEND=0,n: Where n is the length of the request string.
    Tells the module to pass the next n characters through to
    retro.hackaday.com.

  Wait for ">" prompt.

  Send the HTTP request string "GET / HTTP/1.0\r\n\r\n".

  Loop forever:
    Echo everything received from the server, via "Serial1", to the
    PC monitor via "Serial".

(If all goes well, the loop() function will never exit in this simple example.)

Module Communication Routines

The program largely consists of the same sequence of actions:

echoCommand()
  Send AT+ command string to the module.

  Wait for a specific response string OR
  skip the next few lines of module output.

  if the wait times-out and the command is critical
    Halt with an error message .

  Echo all module output to the monitor.

We can impliment this  follows:

boolean echoCommand(String cmd, String ack, boolean halt_on_fail)
{
  Serial1.println(cmd); // Send "AT+" command to module

  // If no ack response specified, skip module output.
  if (ack == "")
    echoSkip();
  else
    // Otherwise wait for ack.
    if (!echoFind(ack)) // timed out waiting for ack string
      if (halt_on_fail)
        errorHalt(cmd+" failed");// Critical failure halt.
      else
        return false; // Let the caller handle it.
  return true; // ack blank or ack found
}

So, for a critical command like our reset of the module, we'd call like so:

echoCommand("AT+RST", "ready", true);

Meaning, send the module a reset command string and wait for a "ready" response.

If the wait times-out (takes more than 5 seconds), log an error message & halt.

For a non-critical query we might call with:

echoCommand("AT+CIFSR",  "",  false); 

Meaning, send a "Get IP Address" command, echo the modules output, and carry on.

Full Listing

The full program, "retroBrowser.ino" is in the files section.

Monitor Output

And the program output is in "output.txt" in the files section.

Conclusions

The ESP8266 is not designed for web browsing!

Our noddy example works fine with a site designed to be slow-client friendly like retro.hackaday.com, but is swamped by responses from "normal" web sites. Even after stripping the echo loop to the bone, the program could barely keep up with the stream of data from the retro site. Using an MCU with a higher clock speed (like a Teensy 3.1), or coding in AVR  C/assembler might allow an attempt to parse the data.

(Try changing the IP address to 173.194.123.5 - google.com - and you'll see that the apparantly minimalist page sends a flood of obfuscated data which swamps the module.)

For my next ESP8266 project I'll try something a little more sensible.