ESP8266 Community Forum

- Sun Dec 29, 2019 6:29 pm #85091 I am just going through future project ideas in my mind and I was wondering if it is possible to just use normal SPI mode for the external flash IC (which only needs two pins for data transfer, not four as usual Quad-SPI flash ICs do)?

The advantage of this would be that two more GPIOs could be used in software. One downside may be that more wait states need to be introduced due to slower interfacing to external flash.

As you can read on page 13 of ESP8266EX documentation: https://www.espressif.com/sites/default ... eet_en.pdf

SPI mode supported: Standard SPI, Dual SPI and Quad SPI. The correct SPI mode should be selected
when flashing bin files to ESP8266.

So, in theory it should be possible. Has anyone ever tried it?

- Mon Dec 30, 2019 8:46 am #85095 Check out https://tech.scargill.net/esp8266-dio-mysteries-solved/

for a discussion on this. Some modules use DIO mode and then normally A GPIO can be freed.

Otherwise to use DIO to get the pin requires cutting tracks which are under the screening can so a bit tricky.

If you want extra GPIO and are using SPI to interface to your own peripherals (e.g display) then it is possible to share the flash pins with this instead of the dedicated HSPI pins normally used. This s called extended SPI mode. You have to use the defined CS pins to allow the arbitration between the flash and other device(s) to work. The flash also gets priority so will impact on the speed of the peripheral access.

- Mon Dec 30, 2019 10:21 am #85097 Thank you so much for your reply.

Otherwise to use DIO to get the pin requires cutting tracks which are under the screening can so a bit tricky.

I am actually planning on developing my own board with an ESP8266EX IC + SPI flash so no track-cutting necessary because I am going to design the PCB myself

This s called extended SPI mode. You have to use the defined CS pins to allow the arbitration between the flash and other device(s) to work. The flash also gets priority so will impact on the speed of the peripheral access.

Is this supported by the (RTOS)-SDK? They are only mentioning CSPI and HSPI. HSPI are Pins 12/13/14/15, don't know about CSPI: https://github.com/espressif/ESP8266_RT ... herals/spi

Furthermore, I am not so sure if I can expect a deterministic behavior from this arbitration? For example: If I want to transmit an image to a display which shares its SPI with the flash - what is the maximum delay in case the ESP8266 CPU is fetching instructions at the moment?
On 4.3.1 (page 19): https://www.espressif.com/sites/default ... eet_en.pdf the table displays IO0/1/11 as CS2/1/0 - so that means I can connect two more devices (besides the already connected flash) to the same SPI?
------------
Edit: Okay, IO1 is U0TX at the same time so that's not going to work as SPI-CS if I want to keep the "debug"-UART
And as far as I remember, GPIO0 (CS2) also has a special role in the boot process - right?
There are just so many things to get right
------------

The article you referred to seems to describe the behavior on an already assembled PCB with an ESP8266 and SPI flash connected in a Quad-SPI fashion.
In case I use "normal" (no Quad-SPI) flash I can also use GPIO9 and GPIO10, right (only GPIO7 and GPIO8 are going to be connected to the flash)?

------------
Edit: Do you know, if any SPI Nor flash can be used? Most of the cheap ones I noticed being used are QSPI factory configured - but because I want to "downgrade" to normal SPI, I can't use them.
------------

- Mon Dec 30, 2019 11:09 am #85098 CSPI can be used with RTOS.

This is also referred to as overlap mode. There is an espressif application guide to overlap mode which explains hardware and software aspects. Search for esp8266 spi overlap guide.

You can use 2 other spi devices in addition to the flash but they must use those CS pins. GPIO01 must be high during normal boot so that is not a problem. You could map the debug out to a different pin if you wanted to use the other CS for another device.

It is difficult to say what the worst case latency is at it depends on the code you are executing. I doubt whether it would be a problem for many devices, particularly things like displays which do not have specific real time dependencies. Program instructions are executed out of the on board cache so once loaded they are executed from there and freeing up the flash until new stuff is needed. So something like display drivers which will have loops to refresh the screen etc should work well.

Don't know about using NOR.