Use this forum to chat about hardware specific topics for the ESP8266 (peripherals, memory, clocks, JTAG, programming)

User avatar
By bjpirt
#5060 @decibit I thought pins 18-23 were used for the flash chip which would mean that 9,10,12,13 are able to be connected to a micro. At least that's how I read it. I've got my fingers crossed that it's possible to use SPI slave and have the flash working fine.
User avatar
By decibit
#5072 Your contribution to this community is outstanding. Wish you the best. SPI slave mode is/was one major thing that Chinese originated modules were lacking behind. Hope to hear more of your results. Thanks in advance.
User avatar
By decibit
#6002 I had it enough. So much nonsense going on. Thanks for the admin, this board is only way there is to fill the gaps, that which the Chinese manufacturer is unable to provide in one place, namely a sense making datasheet.

1) What is this nonsense: The title says "ESP8266EX SIP Mode" on page 20 in ESP8266_Module Application Design Guide.pdf.
Obviously what they mean is "ESP8266EX SPI Mode". Why can't they just fix such simple typos? Everything else is already too confusing, since we are forced to solve a riddle of the missing complete datasheet to benefit from the cheap price and overcome stupid US export restrictions (even to China) for WiFi modules which do have real good complete datasheet but are too expensive at the 20 USD mark.

2) What is SPI and HSPI?
Makes me so mad. Obviously HSPI does not mean "Hitachi SPI" which is a valid shortcut. Why not say SPI_0 and SPI_1 as example? Why put "H" in front of an ordinary SPI port? There is no info for what the the "H" stands for.
All they mean is there are two SPI ports on the ESP8266 chip. "SPI" is connecting to the flash chip in "standalone mode" and the HSPI pins are GPIO's. And "HSPI" is connecting to flash chip in "SPI mode", while "SPI" pins connect to our master MCU.
The HSPI seems to have less HW power than the fully fledged SPI HW. How are we supposed to know if we can't lecture us from it's missing datasheet?

3) Then there is the confusing statement like:
"The clock rate that HSPI supports can be the same as standard SPI. However, HSPI may be limited by the rate of processing data for there is no link-list and DMA." at
What does this mean there is no "link-list"? How am i supposed to know the internals that this statement is referring to?
For my application i do not need full speed transfer rates for large data volume, i only need occasional packet sending every 30 ms or so for small packets like 256 bytes. HSPI would work for my needs.

4) Also it's said that "The SPI-Mode SDK is still in developing. With regard to the SDK of HSPI-Slave, you can e-mail us to apply for it."
There is a code named "SPI_CODE_141204.rar" at
What is it now? Are there 3 different SW to choose from or to begin with?
a) SPI_CODE_141204.rar
b) HSPI-Mode SDK
c) SPI-Mode SDK
And why must i email someone to get anything?

5) Regarding "SPI slave mode" operation:
ESP8266_Module Application Design Guide.pdf at page 21 shows that our master MCU is to be connected to pins 20,21,22.
The pdf in "SPI_CODE_141204.rar" (of course after online translation) says we need also GPIO0/GPIO2 as signalling to communicate the start/end of data transfers between our MCU master and the slave SPI ESP8266 chip. SD_DATA_3/SPI_SLAVE_CS is not used. Does this only apply to the "SPI_CODE_141204.rar" or are these 5 pins also valid while if we based our design on (H)SPI-Mode SDK's?

Basically what i'm saying is that pinouts are not clearly defined and the SW is not clear in any way. Also "SPI_CODE_141204.rar" does not say what data is to be exchanged. Where do i send AT commandos? Does this mean that i need to wait for the SDK that perhaps actually will show AT commando examples sent via SPI?

Any ready to buy module that exists so far is not designed to be used for SPI slave operation. I must draw my own module (that is the easy part), but i can't do so since i'm very much confused.

I corresponded with Chinese all too many times over many many years. I know that you can't get detailed and non-confusing statements from them. Their internal Chinese thinking expressed outward in English causes the trouble. Therefore i seek logical and clear answers here.

I'm not done yet. We need to manage the different states the ESP8266 can be in:
- Pin states during power on
- Pin states before 1st code was loaded
- Pin states while normal operation
Pages 21,22 in ESP8266_Module Application Design Guide.pdf give details about it, but in very compressed form. The developer Espressif_Kelly referred to this pdf in for us to get more clues about slave SPI operation. But i'm saying this info is not enough. We need clear documentation especially put together for slave SPI operation with working software, PCB design and all. Does the answer lie in the finished SPI-Mode SDK that we still need to wait for?

There are more questions like:
- How do we upload initial code? Using UART ("Uart download mode" see page 22) or through our MCU in SPI port? Where is the example? Or will i need to have my PCB manufacturer pre-program the flash IC prior to assembly to avoid initial code upload by myself?
- What are the toggles that are referred to at pins 14,15,26? What data is being output (debug data ?) at what UART data rate?

You get the idea... There is a dilemma. All available modules are for UART operation and are fully documented. To start testing SPI slave mode, everything is missing, starting with a ready to use SPI slave module. How are we supposed to proceed?