Harvey White

An alternate method of reading the ESP8266 WIFI chip

Discussion created by Harvey White on Sep 4, 2017

This is the ESP8266-01 (the 8 pin board).

 

The chip is talked to by a 3.3V TTL level serial data stream at 115Kbps.  You just wire it up appropriately, have control over CE, make sure that GPIO0 and GPIO2 are both high, and for the most part, leave RST high (your choice).

 

Some observations on the chip, just so if you're designing your own board, you know these things.

1) Bypassing 3.3V VCC to gnd with a 100 uf capacitor is a good idea, the board can draw up to 300 MA.  Wire accordingly.

2) labels on the module are with respect to the module.  I wire the USART RX line to the data out on the module, and the USART TX line to the data in on the module.  If in doubt, allow jumpers.

3) when the CE goes active, the chip puts out 16 bit data (or scrambled 8 bit data) that looks like it might be Chinese Unicode about the chip.  This takes some 200 to 300 msec,  allow for that and ignore it.

 

Board used:  F446 Nucleo 64 board with custom daughterboard.

 

USART3 used for ESP system. 

DMA mode used with HAL layer.

Transmit:  Use HAL DMA driver (use usart HAL_TRANSMIT_DMA.) with default DMA and INT settings.  Use default DMA settings and NVIC settings, but be certain to enable both the DMA and INT choices in CUBE32.

Use maximum buffer sizes with receive, message length with transmit.

 

set up the transmit buffer with the command and any arguments.  How you do this is up to you.  Call the transmit routine using DMA.  The advantage with interrupts and DMA is that the message gets sent without having to worry about what the debugger is doing.  This is critical in the receive routines.

Procedure:

1) zero out the receive and transmit buffers.  For just commands, transmit is at 64 characters and receive is at 512  (needed for list of APs)

2) start the receive routine DMA (this enables, but nothing's being sent back now)

3) set transmit done to false, it will be set to true by using the TXcomplete  routine and simply setting the variable

4) transmit using the DMA routine.

5) wait until transmit done is true, then reset it

6) past that (and this is not an elegant solution, but it works) delay for enough MS to let something like get APS to do its job.  Suggest this be on a per command basis.  You are not receiving a known length message, you're shutting down after a time.

7) Abort receive_It (shuts down DMA and interrupt)

8) scan buffer converting CR and LF to spaces

9) evaluate response.  This almost needs a separate section.

10) return result

Interpreting result:

1) using strtok, evaluate the first token in the reply.  It should be either "OK", "ERROR", or "WIFI" or "+COMMAND_NAME"

2) if it's a command name that has embedded strings "xxxxx xxxx", then parse using a delimiter list for the items that have embedded spaces.  This list does not have spaces as a delimiter.  Parse all other entries with a list that does.

3) otherwise, parse with a list that throws away spaces.

4) look for all possible returns, such as OK, WIFI, etc.  Evaluate based on that

5) a valid response can have data then be terminated by "OK"

 

NOTE: you need a DMA/IRQ response because the data coming back has no flow control and you will miss data depending on what your program/operating system is doing.

 

This works under freeRTOS.   Have not made use of the idle time flag, nor have I implemented a timer (needs an extra pin, these boards are already made).

Outcomes