mattico
commented
3 years ago Currently, no. The foundation of the SDMMC driver is the cmd function which blocks waiting for the SDMMC interface to be idle, sends the command, then blocks waiting for the command response (or error/timeout).
Presumably the only functions that need to be non-blocking are the read_block(s) and write_block(s) functions?
Looking through the sdmmc code I can see how it could be made non-blocking. In cmd et. al. rather than block waiting for SDMMC idle, return nb::Error::WouldBlock. Then send the command. Rather than block waiting for the command response, return a token that the caller can block on to wait for the command's completion, or save the state to the SDMMC struct so future calls will know to check for completion first and return error/WouldBlock. The difficulty comes from performing multiple operations sequentially in a non-blocking manner. Perhaps we could return a state machine that the caller has to poll to completion.
I think a more elegant and probably easier method would be to implement DMA for the SDMMC. It appears that DMA operation is rather similar to regular operation. The same commands are sent to begin/end the read/write operation but instead of copying data in/out the FIFO as the operation progresses, the DMA handles all of that. There would still be a blocking period to start/stop the operations but assuming you're reading/writing in large sequential blocks the majority of the time would be spent by the DMA copying data.
pwnorbitals
I'm wondering if the current SDMMC implementation supports non-blocking interrupts?
In my application I'm streaming (both writing and reading back) CSV data to a high speed SDCard. I've based my SDMMC implementation around the current example.
I've had to defer data transfers with the SDMMC to the main thread because it seems its implementation is blocking.
Kind regards, Oliver