Reply To: Suggested refinements

[Michael P. Flaga]

Yes, when streaming data to the Vdsp there is no need to read back the transfer. However, the Due’s AT91SAM’s SPI_TDR is only double buffered and it appears the UNO ATmega’s SPDR is not even. Effectively this means it is possible to overrun the transmission’s DR (buffer). Hence the need to either wait before or after refilling until finished sending the next byte, as not to drop data.

I recall, the Vdsp with the implemented crystal is specified for a max SPI clock speed of approximately 6MgHz, where the default SdCard is 8MgHz. It was found that this over speed is tolerated for sending stream data, but found to be a problem in getting a response, causing unpredictable bit shifted delayed responses. Hence the need for the Vdsp and the SdCard to play together nicely along with other future devices.

Yes, it would be possible to write one’s own SPI equivalent driver. I believe the SdFat did so. Whereas the objectives were successful, using the standard libraries, we have not bothered to create exotic resources, that need maintaining. I had thought about using the SdFat SPI calls, however, this was avoided as not to create dependencies.

It is always a series of give and take with best practices versus best design aka… “Technical Debt versus Technical Cost along with Minimalistic Funcitonal Requirements“