Device Initialization

This is can be a bit of a thorny issue for embedded applications. The ESP8266 can be reset and come up with saved settings. This is ideal, if the settings match your needs. Some applications may want to reset the device and initialize the settings each time for full control. Is the ESP reset procedure under your MCU's control? By that, I mean does your MCU control the ESP8266 /RESET pin?

Hardware Reset

If your MCU has full control, you can determine when the ESP8266 is released from it's reset state. To use the ESP8266 class with a hardware reset, follow this recommended procedure:

1. Ready the UART
2. Instantiate the ESP8266 class (say as esp)
3. Release the ESP device from the hardware reset state
4. Wait for the reset to occur: esp.wait_reset()

The ESP8266::wait_reset() method returns true if this succeeded. Two things happen in that method:

1. A loop waits for the "ready" message flag (invoking the idle() procedure as necessary)
2. Invokes and returns the value from ESP8266::start()

If this procedure hangs, it is because of step # 1. The wait_reset() method must see the message "ready" before it proceeds. If you have a hang in this procedure check baud rate and serial parameters (including flow control).

TCP/UDP Requirements

In order to use the TCP/UDP facility provided by this class, the following ESP8266 modes must be in force or established:

1. Echo off (ATE0, this is automatically performed by the class)
2. Normal communication mode (AT+CIPMODE=0, set if required by the class)
3. Multiplex mode (AT+CIPMUX=1, set if required)

The ESP8266::reset() and ESP8266::start() both set these up, if possible. However, AT+CIPMODE=0 can fail, if the device is currently in mode 1, with the error:

CIPMUX and CIPSERVER must be 0
ERROR

Likewise, setting AT+CIPMUX=1 can be a problem if the device is in the wrong state. To avoid this problem, both reset() and start() queries the setting and leaves it alone if it is already AT+CIPMODE=0. If this isn't true, an attempt is made to set AT+CIPMODE=0 (or AT+CIPMUX=1), but that can fail. The best defence is to set the device to use mode 0 manually (using cmdesp) and leave it that way. Likewise for AT+CIPMUX=1.

Initiating Reset

If you want to initiate a ESP reset by software, you can alter the above procedure slightly:

ESP8266 esp(writeb,readb,rpoll,idle);

esp.clear_flat_ready();     // Clear ready flat
esp.commandok("AT+RST");    // Issue ESP reset command

while ( !esp.get_flag_ready() )
    esp.receive();

Disabling Echo

ESP8266 echo mode must be disabled to be used with the ESP8266 class. To disable echo, use the manual API:

ok = esp.commandok("ATE0");

The returned boolean will indicate that an "OK" response was received.

void reset(bool wait_wifi);

This method takes care of issuing the reset request and waiting for the "ready" message. In addition it sets:

1. ATE0 - Echo off
2. AT+CIPMODE=0 (to allow AT+CPIMODE=1 next)
3. AT+CIPMUX=1 (multiple TCP/UDP sessions)

(finish me)