SD driver writers/maintainers, please read - /CS discussion

Bill Henning

Hi Tomas , Jonathan, lonesock, kye and many others I forgot!

With PropCade, C3, and other future boards with multiplexed SPI ports, it is no longer a simple matter of having a /CS pin defined in sysdep.spin in order to properly select/release SD cards.

I've already successfully modified FSRW for PropCade, I think Dave or Andre modified it for C3 - but there will be many future propeller boards, with many more SPI addressing schemes, so I wonder if SD drivers should be changed to use a more generic mechanism - perhaps something like below:

SD_SELECT
' insert SPI device selection code here
SD_SELECT_RET ret

SD_RELEASE
' insert SPI device de-selection code here
SD_RELEASE_RET ret

' then wherever the code currently pulls /CS low, one could simply

  call #SD_SELECT

' and wherever the code currently raises /CS when it is done, one could

  call #SD_RELEASE

This would also allow blocking SD access until the SPI bus was available, in case say an ADC was doing fast sampling.

I'd appreciate your thoughts...

(we may also need a spin function SPI_DEV_INIT, in case any special setup code is needed on a board)

Mike Green

I think you're correct that we need to have a simple way to customize/modify the various SD drivers for different present and future Prop boards. The /CS control is usually scattered throughout the drivers, so centralizing it in a select and deselect subroutine makes sense. The overhead is minimal and /CS timing isn't critical.

I'm ambivalent about an SD card initialization subroutine since this would normally occur in only one place in a given driver. If it's in-line in the driver's initialization code, the SD card initialization needs to be well marked and commented.

Bill Henning

For the initialization, I was thinking of whatever a specific SPI multiplexer might need to have initialized... however that could be done externally.

Mike Green wrote: »

I think you're correct that we need to have a simple way to customize/modify the various SD drivers for different present and future Prop boards. The /CS control is usually scattered throughout the drivers, so centralizing it in a select and deselect subroutine makes sense. The overhead is minimal and /CS timing isn't critical.

I'm ambivalent about an SD card initialization subroutine since this would normally occur in only one place in a given driver. If it's in-line in the driver's initialization code, the SD card initialization needs to be well marked and commented.

rokicki

Well, don't forget that for high performance, you want to read-ahead and write-behind, so what the SD block layer is doing may not be what you expect.

Further, the latency with CS low can be higher than you expect (up to a good fraction of a second), so anyone "waiting" on a shared SPI bus may have a while to wait. (In reality, it is possible for the SD card to *release* the bus while the transaction is going on, and then come back later to check if it's completed---at least, I think that's possible. But it may not be trivial to implement.)

I understand how important pin economy is, but with the highly variable timing that SD cards present, I think sharing an SPI bus for an SD card with any time-sensitive activity could be problematic. Just because you *can*, in principle, share, doesn't mean you *should*.

Now, if performance isn't an issue, and you are willing to use a fully synchronous driver, and deal with the potentially high latency of the SD card, then sure, go ahead and share pins. But you're only going to save three pins at most.

Bill Henning

rokicki wrote: »

Well, don't forget that for high performance, you want to read-ahead and write-behind, so what the SD block layer is doing may not be what you expect.

I was thinking that it should be the lowest layer select/release that should go to subroutines; that way there is no need to modify the low level driver code in umpteen places.

I like the read-ahead and write behind aspects, but in most cases, most of the time, it would not be adversely affected by an extra 100ns to assert /CS, and 100ns to release it - I am aware that some SD cards need an extra 32 or so clocks to fully release the SPI bus, which is a larger - but still managable - delay.

rokicki wrote: »

Further, the latency with CS low can be higher than you expect (up to a good fraction of a second), so anyone "waiting" on a shared SPI bus may have a while to wait.

That is simply the price to be paid for having more devices share the pins. Really, it is no different (other than the time scale) to multiple bus masters sharing PCI. Ok, it is glacial by comparison

rokicki wrote: »

(In reality, it is possible for the SD card to *release* the bus while the transaction is going on, and then come back later to check if it's completed---at least, I think that's possible. But it may not be trivial to implement.)

I forgot about that... if possible, that would actually free most of the bus time during writes!

rokicki wrote: »

I understand how important pin economy is, but with the highly variable timing that SD cards present, I think sharing an SPI bus for an SD card with any time-sensitive activity could be problematic. Just because you *can*, in principle, share, doesn't mean you *should*.

I understand, and for applications where SD speed is paramount, it should have its own bus.

There are however a large number of applications where it is acceptable to share the bus.

Due to the feature set I wanted, I had to share the SPI bus on PropCade. As I wanted to maintain maximum source level compatibility with FSRW, MCP3208 and other objects, I used 7 pins to implement 8 SPI devices - and it works rather well

FSRW was actually very easy to modify for PropCade, however with C3 and other boards coming, I thought it might be more flexible to abstract out SD_SELECT and SD_RELEASE to make it easier to "port" FSRW to different hardware implementations.

Morpheus+ also multiplexes its uSD card with other SPI devices, and so does another board I will be releasing soon.

rokicki wrote: »

Now, if performance isn't an issue, and you are willing to use a fully synchronous driver, and deal with the potentially high latency of the SD card, then sure, go ahead and share pins. But you're only going to save three pins at most.

On my upcoming board, I allocated a separate bus to an ENC28J60, as I considered it more time critical; and I multiplexed the uSD with some less critical I/O. As you note, SD performance is less critical than other factors for some designs.

3 pins is slightly over 10% of the readily available pins on the prop ... and can easily make the difference between being able to fit a design, or having to add a second prop or other microcontroller.

Now if only PropTool supported #define's this discussion would be moot - as one could do:

#define SD_SELECT andn outa,spi_cs_bit
#define SD_RELEASE or outa,spi_cs_bit

or

#define SD_SELECT call #sd_sel_sub
#define SD_RELEASE call #sd_rel_sub

but our pleas for #define/#ifdef/#include et al have yet to be fulfilled...

Kye

So... sharing the SPI bus will require alot of extra work. The new version of my block driver will make this far easier for porting, but in general stuff will work akwardly.

I attached the version of my driver I'm working on. Only the block driver is almost complete. (MMC cards don't work... thought I followed the spec though).

Cluso99

Bill, I agree. My TriBlades, RamBlades and my new designs share the bus. In fact, I share the Ram data bus with the 3 SPI signals.

Also, in a design I have on the drawing board I will be using CS as a high in prop code via an external buffer - I am using the pin in tristate/high/low to select 2 devices while tristate selects neither. I think it was Phil who first suggested this for combining HS & VS on a single pin.

The pins should be individually selectable as well.

This pin shortage is only going to get worse as we see more types of "microcomputers" based on the prop. The floodgates were opened a bit over a year ago and it's full steam ahead :smilewinkgrin:

Bill Henning

Nice clean code, well commented!

I don't think sharing the bus, nor not sharing the bus will require all that much extra work - just replacing the code that selects/releases /CS with subroutine calls, and customizing those subroutines for different platforms. (see first post in this thread for an example)

Kye wrote: »

So... sharing the SPI bus will require alot of extra work. The new version of my block driver will make this far easier for porting, but in general stuff will work akwardly.

I attached the version of my driver I'm working on. Only the block driver is almost complete. (MMC cards don't work... thought I followed the spec though).

Bill Henning

Thanks - and I know what you mean about the steamroller...

My original Morpheus did not share the SPI bus, but PropCade, Morpheus+ and other upcoming boards of mine do share it. Prop pins are a precious resource!

Cluso99 wrote: »

Bill, I agree. My TriBlades, RamBlades and my new designs share the bus. In fact, I share the Ram data bus with the 3 SPI signals.

Also, in a design I have on the drawing board I will be using CS as a high in prop code via an external buffer - I am using the pin in tristate/high/low to select 2 devices while tristate selects neither. I think it was Phil who first suggested this for combining HS & VS on a single pin.

The pins should be individually selectable as well.

This pin shortage is only going to get worse as we see more types of "microcomputers" based on the prop. The floodgates were opened a bit over a year ago and it's full steam ahead :smilewinkgrin: