Multiple SPI flash chips on primary SPI - possible?

[mculibrk]

Hi!

Is there any way to add/use additional SPI flash chips connected on the "primary" SPI bus/controller?

The idea would be to use an additional CS pin and (re)use the same SCK/SDI/SDO pins used for primary spi flash used for code execution. Could this be possible? Any way to configure/enable such setup through SDK or directly via registers?

I know I could use the other (H)SPI port but it's currently used for other purposes.

Also, would it be possible to "memory map" this "second" spi flash?

Related to this... could the other (HSPI port) flash mapped directly into memory like the primary one? Any registers available for that?

Is there any support (in SDK or otherwise) for SD cards (on HSPI)?

regards,
mculibrk

[costaud]

Hi!

Is there any way to add/use additional SPI flash chips connected on the "primary" SPI bus/controller?

The idea would be to use an additional CS pin and (re)use the same SCK/SDI/SDO pins used for primary spi flash used for code execution. Could this be possible? Any way to configure/enable such setup through SDK or directly via registers?

I know I could use the other (H)SPI port but it's currently used for other purposes.

Also, would it be possible to "memory map" this "second" spi flash?

Related to this... could the other (HSPI port) flash mapped directly into memory like the primary one? Any registers available for that?

Is there any support (in SDK or otherwise) for SD cards (on HSPI)?

regards,
mculibrk

this topic shows a case that the primary spi port connect to the flash as well as a spi screen.
viewtopic.php?f=15&t=56
We can provide a more detailed documentation later.

HSPI port flash can be mapped directly into memory like the primary one. But the chip have to boot from the primary SPI port, that means this can be applied in this kind of situation: esp8266 connect to a sdio master MCU , waiting for the mcu bootup esp8266, then run map to the HSPI flash and run the wifi stack with it.

[rudi]

Hi!
Is there any way to add/use additional SPI flash chips connected on the "primary" SPI bus/controller?

Yes it is, SPI is bus system -
you can connect over cs or device adress

feel free to watch
https://www.youtube.com/watch?v=RzduRWkV2LM

shows a SPI Device MCP23S17 connected to the ESP8266 by SPI
this is the example and answere:
Do SPI work at ESP8266

I test it great with it

With this chip MCP23S17
you can have 2 full 8 bit ports more

you can add 8 devices same type and can connect over adress
you can add more devices and managed this by cs
you can use the Port for LCD and other to
and so on..

The idea would be to use an additional CS pin and (re)use the same SCK/SDI/SDO pins used for primary spi flash used for code execution.
Could this be possible? Any way to configure/enable such setup through SDK or directly via registers?

Yes you are right, CS pin is your friend and if you can manage, device adress same like other SPI devices in other MCU

I know I could use the other (H)SPI port but it's currently used for other purposes.

You can make multiple (H) SPI , same way like SPI - only pair pin more and manage by your self

Also, would it be possible to "memory map" this "second" spi flash?

Yes - why not?

Related to this... could the other (HSPI port) flash mapped directly into memory like the primary one? Any registers available for that?

Yes it could.
You do not need registers.

Is there any support (in SDK or otherwise) for SD cards (on HSPI)?

Not documented in the API
but you can make simple by use SPI and use SD protokoll by yourself
like this:

http://elm-chan.org/fsw/ff/00index_e.html

others:
http://henningkarlsen.com/electronics/library.php?id=37
http://developer.mbed.org/cookbook/SD-Card-File-System

regards,
mculibrk

[mculibrk]

this topic shows a case that the primary spi port connect to the flash as well as a spi screen.
viewtopic.php?f=15&t=56
We can provide a more detailed documentation later.

Perfect! I was searching through the forums and somehow missed this original topic.

HSPI port flash can be mapped directly into memory like the primary one. But the chip have to boot from the primary SPI port, that means this can be applied in this kind of situation: esp8266 connect to a sdio master MCU , waiting for the mcu bootup esp8266, then run map to the HSPI flash and run the wifi stack with it.

Understandable... but in this case I need the additional spi memory for "data storage only" so the boot-from-flash requirement is more than acceptable.

One question though. I suppose the spi flash chip can be memory mapped for reading only right?

But anyway, if the chip can handle the CS lines automatically and there is no special considerations for the library or other code "running" at the same time from the primary flash on the same bus it's awesome!

Thanks!

[mculibrk]

Yes it is, SPI is bus system -
you can connect over cs or device adress

Yes... I know that.. but my question or concern was more about "will the sdk library and running code/chip handle that transparently"...
If I just put another device on the primary spi bus and use a gpio for CS this would cause a lot of "problems" for the "normal, memory mapped spi usage" (during code execution, library access...)

feel free to watch
https://www.youtube.com/watch?v=RzduRWkV2LM

shows a SPI Device MCP23S17 connected to the ESP8266 by SPI

nice one!

Yes you are right, CS pin is your friend and if you can manage, device adress same like other SPI devices in other MCU

You can make multiple (H) SPI , same way like SPI - only pair pin more and manage by your self

sure... but I was not talking about 'bit-banging'... I need HW assisted SPI

Also, would it be possible to "memory map" this "second" spi flash?

Yes - why not?

You do not need registers.

Can you explain your statement a little?
How could one just attach a spi (flash) memory to the controller and have memory mapped access to it "just like that"?
I think there must be a way to tell the CPU where the chip memory should be mapped, how big it is, which hw cs will be used, which kind (speed, data bits...) and only after that one could access its content transparently/memory mapped - I mean do something like this:
(pseudo code, for reference)

Code: Select all

unsigned char *spimemory;
unsigned i;

spimemory = (unsigned char *)0x84001000;     // let's say teh spi flas is mapped at this address

for (i=0;i++;i<2000) {
    os_printf("Byte from flash: %02x\n", *spimemory);
    spimemory++;
}


Is there any support (in SDK or otherwise) for SD cards (on HSPI)?

Not documented in the API
but you can make simple by use SPI and use SD protokoll by yourself

sure, sure... but I was wondering if that was hw and/or library assisted by any chance.

Probably I was not clear enough that I need/require hardware SPI access only, so any form of bit-banging is not what I need. I know it can be done that way but I need hw support (for speed and cpu usage/blocking as low as possible)



Thanks for all!

[rudi]

Yes it is, SPI is bus system -
you can connect over cs or device adress

Yes... I know that.. but my question or concern was more about "will the sdk library and running code/chip handle that transparently"...
If I just put another device on the primary spi bus and use a gpio for CS this would cause a lot of "problems" for the "normal, memory mapped spi usage" (during code execution, library access...)

yes you are right, if you use a gpio for cs.. there you must before 'controlled deactivate' the primaster SPI

costaud gave a nice tip in this here too for overlap mode
the hardware toogle cs itself in the sdk iot example

Code: Select all


void ICACHE_FLASH_ATTR
    hapi_overlap_init()
{
   //hspi overlap to spi, two spi masters on cspi
   SET_PERI_REG_MASK(HOST_INF_SEL, reg_cspi_overlap);
   
   //set higher priority for spi than hspi
   SET_PERI_REG_MASK(SPI_EXT3(SPI),0x1);
   SET_PERI_REG_MASK(SPI_EXT3(HSPI),0x3);
  SET_PERI_REG_MASK(SPI_USER(HSPI), BIT(5));

 //select HSPI CS2 ,disable HSPI CS0 and CS1
 CLEAR_PERI_REG_MASK(SPI_PIN(HSPI), SPI_CS2_DIS);
 SET_PERI_REG_MASK(SPI_PIN(HSPI), SPI_CS0_DIS |SPI_CS1_DIS);

 //SET IO MUX FOR GPIO0 , SELECT PIN FUNC AS SPI CS2
//IT WORK AS HSPI CS2 AFTER OVERLAP(THERE IS NO PIN OUT FOR NATIVE HSPI CS1/2)
 PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO0_U, FUNC_SPI_CS2);
}



sure... but I was not talking about 'bit-banging'... I need HW assisted SPI

HW Pins are descripted too and in api is descripted the reference,
i think i can not follow the problem you will clear.

ESP8266 have MOSI, MISO, CLK and other -
nice description in Doku.

Can you explain your statement a little?
How could one just attach a spi (flash) memory to the controller and have memory mapped access to it "just like that"?

and where is the problem for this doing?
if you attach new spi / ( Flash ) in the bus, you must know the adress or managed this by cs.
if you managed this by cs, so use a gpio for this if you want make more or use the cs of esp8266 for this and call by adress

I think there must be a way to tell the CPU where the chip memory should be mapped, how big it is, which hw cs will be used, which kind (speed, data bits...) and only after that one could access its content transparently/memory mapped - I mean do something like this:

yes - you are right!
this i wrote lines over yours.
you must managed your hw by self, no body no know what people connect to esp8266,
but the interfaces are given , example (H)SPI, SPI, I²C, PWM and more..

Is there any support (in SDK or otherwise) for SD cards (on HSPI)?
...

sure, sure... but I was wondering if that was hw and/or library assisted by any chance.

Probably I was not clear enough that I need/require hardware SPI access only, so any form of bit-banging is not what I need.
I know it can be done that way but I need hw support (for speed and cpu usage/blocking as low as possible)
Thanks for all!

mhm..
you do not neet bit-banging - you can use hw spi too, esp8266 have spi pins.

can i ask you, which language you speak, perhabs we can talk in same and for reason difference english

i will make next time video of my use with sd card for data and boot with HW PINS not bit-banging.

what is the problem exactly?
do you not know how sd card is support at Mikrocontroller's?
do you not know how sd card code must code for esp8266 and not know how to connect?
( pins at ESP8266 are to use, that you can use / support a sd card by hw pins. )

is it difference bitbanging / hw support for you?
Most SD Card holder are SPI

SPI are
MOSI
MISO
CLK
CS
..

SPI API for read and write is in the api.
for more commands for sd commands you can make a sd_card.h and define your "OWN" sd command there fine.
This user command - sure - can not be in the API document or api calls - you must code this by your self.
the base, spi command are fine in document.

cheers

rudi


PS

Please have a look here:
viewtopic.php?f=7&t=85
read the SPI_REG.XLS
Read the Register for HW SPI
Read the ESP8266HSPI Doc
study the Example SPI_CODE
all question are fine ansered after
i think - i hope

[mikewang]

Hi!

Is there any way to add/use additional SPI flash chips connected on the "primary" SPI bus/controller?

The idea would be to use an additional CS pin and (re)use the same SCK/SDI/SDO pins used for primary spi flash used for code execution. Could this be possible? Any way to configure/enable such setup through SDK or directly via registers?

I know I could use the other (H)SPI port but it's currently used for other purposes.

Also, would it be possible to "memory map" this "second" spi flash?

Related to this... could the other (HSPI port) flash mapped directly into memory like the primary one? Any registers available for that?

Is there any support (in SDK or otherwise) for SD cards (on HSPI)?

regards,
mculibrk

this topic shows a case that the primary spi port connect to the flash as well as a spi screen.
viewtopic.php?f=15&t=56
We can provide a more detailed documentation later.

HSPI port flash can be mapped directly into memory like the primary one. But the chip have to boot from the primary SPI port, that means this can be applied in this kind of situation: esp8266 connect to a sdio master MCU , waiting for the mcu bootup esp8266, then run map to the HSPI flash and run the wifi stack with it.

u know ,i recently come to the situation that a additional flash is need to be added to hspi bus sharing bus pins with primary spi by overlap mode, it is relly bothering me a lot So the reference mentioned above about flash attach operation is really expected ，i actually wonder if this document is available or not . it is really kind of urgent anyway ，long for ur prompt reply。，thanks！！