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?

API

• [bool ESP8266::wait_reset()](#Hardware Reset)
• [bool ESP8266::reset()](#Software Reset)
• bool ESP8266::start()

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.

bool ESP8266::wait_reset()

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.

Manual Software Reset

If you want to initiate a ESP reset by software and you don't want to use the provided ESP8266::reset() method, you can perform the following manual reset:

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

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

while ( !esp.get_flag_ready() ) {
    esp.receive();
    do_idle_stuff();
}

Make sure that before you use the TCP/UDP methods, that ATE0, AT+CIPMODE=0 and AT+CIPMUX=1. The following sections go into more detail about this.

Disabling Echo

ESP8266 echo mode must be disabled to be used with the ESP8266 class. This is automatically assured by the ESP::reset() and ESP::start() methods. If you need to do it manually, use:

ok = esp.commandok("ATE0");

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

Software Reset

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
3. AT+CIPMUX=1 (multiple TCP/UDP sessions)

The method returns a boolean true, if it fully succeeded. A false return indicates that one of the methods failed to set correctly (normally the fault of AT+CIPMODE=0 or AT+CIPMUX=1).

bool ESP8266::reset()

The method will hang forever, if the "reset" message is never seen. If that happens, check your UART and flow control.

Warm Start

If you plan to use the ESP device in its present state, then it is recommended that you call upon:

bool ESP8266::start()

If it returns true, you can be confident that echo is turned off (ATE0), AT+CIPMODE=0 and AT+CIPMUX=1. These are the prerequisites for this class to function correctly.

Like the software reset() method, if a false is returned, then the method was likely unable to set AT+CIPMODE=0 and/or AT+CIPMUX=1. Start up ./cmdesp and change the saved settings manually. The device is probably in a configured state that will refuse one or both of these settings.