I just committed on the trunk a modified SAM7 SPI driver using IRQs and DMAs. It appear to work in the SAM7X FatFs demo but the first "tree" command is slow, subsequent commands have normal speed. I don't see this behavior in the LPC214x and STM32 demos using the same SD card.
I am not sure about the cause, Liam or Alexander, if you have a chance please give a try to the new SPI code. I don't see anything obviously wrong but I not the most experienced with the SAM7…
Great! I'll experiment with it a bit.
The SPI peripheral on the SAM7 is a little particular - chip select management is designed to be handled by the peripheral, so you typically don't need to explicitly call spiSelect() or spiUnselect(). Setting CSAAT in the mode register can ensure the chip select is maintained until the end of the transfer. This diverges from the current driver model, but maybe there's a way to take advantage of this mode of operation.
Also, it looks like it's currently configured to enable and then disable the entire peripheral on each transfer (via AT91C_SPI_SPIEN and AT91C_SPI_SPIDIS in the SPI_CR). Did you find that this was necessary?
It was not that way initially but it seems that without doing this the DMA transfer is not triggered on the second SPI operation. I think this enforces a front on the internal DMA request line. I also verified that the User Manual is wrong about some status bits in the SPI SR register.
About the CS handling, probably it would require a custom driver with a very different API, my idea was to create an HAL-compliant driver. I don't think the performance would be much different unless you need many small transfers done on different chip select lines., all the delay settings would be a nightmare too.
Log in to post a comment.