SPI kernel driver latency


I would like to interface with an ADC slave device via SPI but not sure if it is realistic.

The ADC is externally clocked and alerts the master (the OMAP) that a sample is ready for retrieval by pulling a DataReady line low.
The ADC pulls the DataReady line low every 19 us (52kSamples/s) and then expects the Master to retrieve 96 bits from it with a 25MHz SCLK before the next sample becomes ready.

Is it possible/realistic to write a new kernel protocol driver that uses the mcspi controller driver and be sure that the sample will be retrieved every time before the 19us lapses?

Basically my question is, what is the best/easiest way to ensure that the OMAP retrieves all the data over SPI within 19us from when the DataReady line has been pulled low by the ADC?

Thanks in advanced,


I would expect you would regularly miss samples. Its going to take several microseconds to read the data so you’ll find you need to respond and start reading data within a few microseconds (certainly less than the 19us figure). I would put a dedicated microcontroller inbetween the OMAP and the ADC which buffers the data so that the linux kernel can be busy “off doing something else”…

I don’t know about ARM architecture, but context switching can be very expensive in CPU cycles, so constantly interrupting the CPU, reading data and then continuing with normal kernel / userspace tasks could be very inefficient.

Now supposedly you can use the PRU in the BBB to run as a separate microcontroller. I’ve been meaning to experiment but I have yet to get a BBB.

It would probably work by message passing. Where the micro would send a message to the linux kernal and then your user application could get the data.