Hi,
Im working on a fairly complex project and one of the things it does is write to a bunch of SPI dacs and read from an SPI adc.
The write speed of the spi dacs are rated at 20Mhz clk (although before I realised this, I tested them up to 80Mhz and settled on 48Mhz) but the adc spi bus is only rated to about 1.8Mhz.
With a teensy 4.1 running at 600Mhz, it seems that this will be hanging around for between 12.5 cycles for the 48Mhz overclocked DAC (is this a problem for an MCP4822 if the output isn't corrupting?) to ~333 clock cycles for a non overclocked MCP3202 per spi clock.
Im going to be doing around at least 130,000 writes per second. Probably more. For the amount of data being piped across to these devices I seem to be using way too much of the Teensy processing time.
Should I instead use an interrupt and bit bang my own spi using GPIO?
Arguably If my dacs are happy running at 48Mhz, using an interupt is largely pointless because I think it takes 5 cycles at either end of the interrupt to enter and exit, but if i want to slow the SPI clk down to the specified 20Mhz, this is probably worth doing as would lose 10 cycles rather than 30 cycles on the main processor.
or.....
Whilst the spi is being written to or read from, can the processor be doing something else? Is this what the FIFO is for? I think ideally, I would like to pre load a value in to some kind of FIFO/buffer or register, and once an spi write is initiated, some part or peripheral in the processor deals with this by itself whilst the main processor returns to the main loop something more useful rather than waiting for a slow SPI to clock round.
Ideally I would like to call an interrupt every so often to set an address + enable, then whilst my dac is being written to, settling and charging a sample and hold cap, Id like the processor to be calculating new values instead of waiting for the spi write to finish.
Thanks
Im working on a fairly complex project and one of the things it does is write to a bunch of SPI dacs and read from an SPI adc.
The write speed of the spi dacs are rated at 20Mhz clk (although before I realised this, I tested them up to 80Mhz and settled on 48Mhz) but the adc spi bus is only rated to about 1.8Mhz.
With a teensy 4.1 running at 600Mhz, it seems that this will be hanging around for between 12.5 cycles for the 48Mhz overclocked DAC (is this a problem for an MCP4822 if the output isn't corrupting?) to ~333 clock cycles for a non overclocked MCP3202 per spi clock.
Im going to be doing around at least 130,000 writes per second. Probably more. For the amount of data being piped across to these devices I seem to be using way too much of the Teensy processing time.
Should I instead use an interrupt and bit bang my own spi using GPIO?
Arguably If my dacs are happy running at 48Mhz, using an interupt is largely pointless because I think it takes 5 cycles at either end of the interrupt to enter and exit, but if i want to slow the SPI clk down to the specified 20Mhz, this is probably worth doing as would lose 10 cycles rather than 30 cycles on the main processor.
or.....
Whilst the spi is being written to or read from, can the processor be doing something else? Is this what the FIFO is for? I think ideally, I would like to pre load a value in to some kind of FIFO/buffer or register, and once an spi write is initiated, some part or peripheral in the processor deals with this by itself whilst the main processor returns to the main loop something more useful rather than waiting for a slow SPI to clock round.
Ideally I would like to call an interrupt every so often to set an address + enable, then whilst my dac is being written to, settling and charging a sample and hold cap, Id like the processor to be calculating new values instead of waiting for the spi write to finish.
Thanks