SPI Library - protocol flexibility

Rocker
Posts: 24
Joined: Fri Apr 21, 2017 10:30 pm

SPI Library - protocol flexibility

Postby Rocker » Mon Sep 18, 2017 9:10 pm

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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: SPI Library - protocol flexibility

Postby ESP_Sprite » Tue Sep 19, 2017 1:09 am

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
Posts: 24
Joined: Fri Apr 21, 2017 10:30 pm

Re: SPI Library - protocol flexibility

Postby Rocker » Tue Sep 19, 2017 2:41 am

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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: SPI Library - protocol flexibility

Postby ESP_Sprite » Tue Sep 19, 2017 3:51 am

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
Posts: 24
Joined: Fri Apr 21, 2017 10:30 pm

Re: SPI Library - protocol flexibility

Postby Rocker » Wed Sep 20, 2017 1:03 pm

Thanks - and it sounds like a good plan.

Who is online

Users browsing this forum: Corand and 110 guests