MickMad
Well-known member
Hi guys,
I recently had to fiddle with the SPI module on the Teensy 3.6 to be able to interface it in the best possible way with precision ADCs and DACs (600KHz-ish sample rate) and I was wondering if it could be useful to add the following features on the standard Teensy SPI library for anyone to use or if these "advanced" features should just be left out of the public API so that any advanced user can add them on a per-use basis.
Hardware Chip Selects, using CSs to multiplex devices
The first thing is the use of the hardware chip select lines; in particular, there is a REALLY cool feature for SPI0 module (at least on the K66) that goes like this:
SPI0 has 6 PCS lines, PCS[5:0], that can be used as 6 CS lines to (guess what) select up to 6 devices on the same SPI0 bus, BUT! The PCS5 signal can act as a strobe for an external demultiplexer, that is you can connect a 32 bit demultiplexer's control lines to PCS[4:0] and use the PCS5 signal to strobe the update of the demux. This allows for control of up to 32 devices on the same SPI0 module, rather than only 6. I think this feature could come in really handy.
I am also studying a way to implement this on the SPI1 and SPI2 modules (using external glue logic), but that's out of the scope of this thread.
PCS to SCK Delay, After SCK Delay, Delay after Transfer
These three features right here are a time-changer (pun intended because delay). These ADCs and DACs I am using need a specific CS timing sequence, in particular you usually need to keep CS high until the conversion is done (input is sampled or output is settled), then pull CS down, then wait some time before starting clocking data in or out, then stop clocking, then you need to wait some more time before reasserting CS and repeating the process. When I first tried to use these, I had to use digitalWriteFast for the CS lines and nops to wait time with nanoseconds precision, then calling SPI.transfer16(), so I was basically wasting all CPU time just for timings and transferring data. BUT! with the proper settings for these three delay times (they depend on the use of hardware CS lines btw) I was able to get data in and out using DMA with no issues at all. These could come really handy for similar applications that require nanoseconds precision timings.
Please note that all these settings reside in the CTAR register, so maybe the appropriate place for these functions would be the SPISettings class.
Also note that the delay times are calculated in the following way:
delay = F_BUS x prescaler x scaler
The values of prescaler are 1-3-5-7 and the scaler values go from 2 to 65536.
What do you guys think?
I recently had to fiddle with the SPI module on the Teensy 3.6 to be able to interface it in the best possible way with precision ADCs and DACs (600KHz-ish sample rate) and I was wondering if it could be useful to add the following features on the standard Teensy SPI library for anyone to use or if these "advanced" features should just be left out of the public API so that any advanced user can add them on a per-use basis.
Hardware Chip Selects, using CSs to multiplex devices
The first thing is the use of the hardware chip select lines; in particular, there is a REALLY cool feature for SPI0 module (at least on the K66) that goes like this:
SPI0 has 6 PCS lines, PCS[5:0], that can be used as 6 CS lines to (guess what) select up to 6 devices on the same SPI0 bus, BUT! The PCS5 signal can act as a strobe for an external demultiplexer, that is you can connect a 32 bit demultiplexer's control lines to PCS[4:0] and use the PCS5 signal to strobe the update of the demux. This allows for control of up to 32 devices on the same SPI0 module, rather than only 6. I think this feature could come in really handy.
I am also studying a way to implement this on the SPI1 and SPI2 modules (using external glue logic), but that's out of the scope of this thread.
PCS to SCK Delay, After SCK Delay, Delay after Transfer
These three features right here are a time-changer (pun intended because delay). These ADCs and DACs I am using need a specific CS timing sequence, in particular you usually need to keep CS high until the conversion is done (input is sampled or output is settled), then pull CS down, then wait some time before starting clocking data in or out, then stop clocking, then you need to wait some more time before reasserting CS and repeating the process. When I first tried to use these, I had to use digitalWriteFast for the CS lines and nops to wait time with nanoseconds precision, then calling SPI.transfer16(), so I was basically wasting all CPU time just for timings and transferring data. BUT! with the proper settings for these three delay times (they depend on the use of hardware CS lines btw) I was able to get data in and out using DMA with no issues at all. These could come really handy for similar applications that require nanoseconds precision timings.
Please note that all these settings reside in the CTAR register, so maybe the appropriate place for these functions would be the SPISettings class.
Also note that the delay times are calculated in the following way:
delay = F_BUS x prescaler x scaler
The values of prescaler are 1-3-5-7 and the scaler values go from 2 to 65536.
What do you guys think?