Fortunately, the driver program doesn't have to wait for the ADC to perform its conversion. If /CNVST _and_ /RD are both driven low, the ADC places the results of the PREVIOUS conversion on its data pins and also initiates the _next_ conversion. The impact of noise is minimized because the conversion starts with the MSB first, so by the time the ADC's SAR is working on the LSBs the data-read is done. The delays I have to deal with are all in the 10-45nS range, aside from the somewhat slower GPIO access time, so very short compared to the 1us conversion time. That's per the data sheet anyway.In these things, if you want to use the fastest it can go, (warp mode), there is a minimum time between conversions of 1mS, should you be wanting to go the slowest. If course, that is real slow, but lets you get up to 1MSPS when you go fast. Choosing "normal" mode lets it run at 800kSPS maximum, but should you desire, you can clock it along as slow as you like (I think).
Forgive that I don't know the detail of how you are having the Teensy talk to the AD7667, but I did not think you were constrained to having the Teensy be stuck waiting for the ADC when the event rate is 1.25uS.
I know this sounds simplistic, but can the Teensy initiate a conversion by setting /CNVST to LOW, and then go off and do whatever else it likes in it's loop until 1.25 (or more) microseconds later, and then check the pin 29 BUSY signal for data_ready?
I get it that the available delay in the Teensy may not be suitable. There are likely a whole lot of different solutions to this. Last I had a (almost) similar scene with a 32-bit microcontroller, I resorted to a little interrupt routine to decrement my own delay. The main housekeeping loop did not pause in any noticeable way.
I take it that the Teensy has to take out 8 bits at a time.
My ADC board includes a jumper that shorts /CNVS and /RD so this mode of operation requires one less connection between the Teensy and ADC board. Right now I also am not using the BUSY signal. Hopefully that won't be necessary.
The Teensy4.0 has enough of GPIO6's bits brought out to perform one 8-bit read or write in parallel, although there is some bit-shifting needed to get 8 bits. Specifically, GPIO6 is a 32 bit register and the useful bits are selected by ANDING 0x0f0f0000 with the contents of GPIO6_DR then shifting and ORING to turn those separate 4-bit nybbles into an 8 bit quantity. To read 16 bits two successive 8-bit reads have to be done (but the bit shifts are different to occupy the upper 8 bits of my data word). That's where the ADC's BYTESWAP pin comes in.
It's surprising that it takes about 4X longer for the data pins to settle after changing BYTESWAP, compared to setting /RD low, but that's how it is.
The Teensy4.1 has 16 contiguous bits brought out so it definitely is better suited for this. Just one read/shift operation and no messing with the BYTESWAP pin. It still has to wait 10nS for the ADC's data pins to settle.
It's possible that the slower peripheral clock has enough delay that it may not be necessary to use as many wait states as I currently have put in my ISR code. Something TBD.