DMASPI library needs some (probably breaking) changes to really support multiple SPIs

Status
Not open for further replies.
Hopefully Christoph can give a better answer.

It has been a long time since I played with it... But if my memory was correct, SPI2 worked on T3.6. But you had to remove the comments which removed the code...

As for T3.5 - SPI1 and SPI2 are a lot more interesting. They don't have two DMA sources for the SPI1 and SPI2, they only have one, which can either be to or from SPI but not both... Several posts on that...
The current SPI library does support simple DMA SPI transfers on all of them.
bool transfer(const void *txBuffer, void *rxBuffer, size_t count, EventResponderRef event_responder);
 
Got another question for you guys.
Can the DMA accept odd sized transfers. Im planning to build a PCB for an 18Bit ADC(ADS8698) and to use it you send 16 command/blank bits and then you clock another 18bits back from the ADC.
 
I plan to support all teensy 3.5 SPIs and even ordered the board for just that. Now I just need to find time to do it.

Regarding oddly sized transfers: it would probably make sense to write a totally custom implementation. The DMASPI library can't do it as it is
 
Well it was worth asking, looking a little closer at the datasheet on page 36 figure 75, shows that the CS pin must be toggled to start the next cycle. So its possible to just clock in 24 bits from the ADS8698. So, send the 2 byte command and then clock in 3 bytes and just dump the extra zero's on the 3rd byte.

I guess before bugging you guys I should RTFM a second time lol.
 
christoph/kurtE, got another question. For the ADC i'm working with we have to toggle the CS pin to start the next conversion. If I send 2 bytes and receive 3 bytes, does DMA toggle the CS pin or does the processor have to do it?

Reason I ask is having to stop and toggle the pin up to 400K times a second could get taxing on the micro and could interfere with other tasks.
 
Status
Not open for further replies.
Back
Top