SPI Library - protocol flexibility

[Rocker]

I'm trying to access a Micron SPI NAND Flash Memory chip via the SPI library (spi_master). The library looks like it was designed for a protocol where all messages have the same format, i.e. same command bits, address bits and dummy bits for each message. When you set up a device, that's where those variables are defined, rather than the transaction structure.

That is not the case with the Micron protocol. All messages have an 8 bit command field, but some have address fields following, others don't, some have dummy bits, some don't ....

I can handle this for the most part by setting the command bits to 8 and using the transaction length field for the rest of the bits. But there is a 4x page write where the address bits are written out on a single line, but then the page data (~2000 bytes) is written out on all 4 lines (QIO). That would be a very nice message to be able to use - it would reduce write time by a factor of 4.

Is there a good way to handle this scenario? I'm looking at re-writing the SPI driver to do what I want it to, but that's going to be a pain. Then, there's the maintenance issues. I'm looking for another option.

Thanks - Rob

[ESP_Sprite]

Yes, we are aware that this is a limitation of the SPI driver. Would you have any ideas on how you would like to see your requirements implemented in the current one? We're open to suggestions, given they are architecturally sound and preferably do not break existing code.

[Rocker]

In terms of requirements, I need the ability to define address bits and dummy bits on a per message basis not on a per device basis. I'm assuming that the parallel operation (DIO, QIO) starts with the data field and that command, address, and dummy fields are all on a single wire. Another option would be to be able to specify at what point transmit data goes to parallel. I think the first option is better.

I see two options to implement this. The first is that multiple "devices" can use the same chip select line, then you can configure a "device" for each flavor of message. I think that is a hack, but it would at least give the desired result.

I think the better option is to move address bits, dummy bits and command bits to the transaction structure from the device structure. A variant of this would be to define default values in the device structure and override them in the transaction structure as needed. That would mean more flag entries to say whether the default values should be overwritten.

[ESP_Sprite]

Heh, interesting to get confirmation; those actually were the two options I had in mind as well. We'll probably implement one of the two one of these days; I prefer the 2nd one. Can't give you a timeframe for this, however: people are mostly busy on ESP-IDF 3.0 stuff nowadays.

If you need to get this done before we get around to it: if your fix is universal and the quality of the code is good, you can start a pull request on Github to have it merged in esp-idf. If it gets merged this way, at least you don't have to worry about maintenance; we'll take care of this.

[Rocker]

Thanks - and it sounds like a good plan.