msperl wrote: [*] any GPIO can get used as ChipSelect - we are no longer limited to 2 SPI Devices on the bus!
msperl wrote: The driver includes copying a 64Bit timestamp (based on a 1MHz clock) of when the SPI transfer terminates (and it would be quite easy to add one to the start of the transfer as well), but that is not exposed further up the linux SPI-stack.
as said: triggering an interrupt and then have a driver run the "pull" is right now the best approach.jesperkn wrote:Hey Martin, this was my idea to interrupt on the CS -> LOW from the FPGA/ASIC and poll out the data. Yes MCU utilisation will be high during this event but it is also critical to get all data as there is no resend possibility. Second option would be to implement at hardware buffer (SPI storage) or a SPI SLAVE to Master buffer.
I expect this to be doable but any thoughts / concerns?
In summary:Karmek wrote: As far as i understood, the crucial part is latency here, since context switches or scheduler interrupts may delay the SPI communication.
I have some questions left where i hope you could help me:
- Is the default spidev driver (spi_bcm2708) included in 3.12. Kernel (got a RT kernel with that version) good enough for this?
- I read about a BCM2835 driver which seems not to be included in my kernel. Does it improve latency perceptibly? Is it stable?
- msperls driver seems to improve performance a lot, but he mentioned that it brings little benefit for small transfers. Do you think it could improve performance in my scenario? Is it compatible with my kernel version? I think it was mentioned that it uses a new dev structure? What will change here (does it use device tree)?
- Are iio drivers a much better approach? I've never worked with them and do not know exactly what they change or if they use DMA or interrupts.
Well - if you create a spi_message that does the following:Karmek wrote:Hi msperl,
If i understand you correctly DMA is not suitable for byte-wise transfer (very small data chunks) or unpredictable transfers. In case i can find a good 4 channel simultaneously sampling ADC it would give me a single data stream containing all channels - thus causing a single transfer of ~4*3=12 byte with 1kSPS. May i ask for your guess here? Any improvement with DMA possible? Or still not worth the effort?
Polling means running without an interrupt in a tight loop consuming CPU.Karmek wrote: What will be polled with spi-bcm2835 driver? Incoming bits on the MISO line?
If I was you and you want minimal jitter, then I would not go that route of an ADC that sends an interrupt (see above), as you would need to have 4x an interrupt for 4 transfers. instead look for an ADC that has "predictable" sample/hold times - say a prefix of X bit transmitted/reading as 0 and then follows the data. Also I would run everything essential in a tight C loop not python to minimize latencies further. I guess you could get as close as 30us for the full transfer (maybe slower).Karmek wrote: I planned to use an ADC with DataReady indicator, such that it generates an interrupt on my rPi when ADC data is ready for retrieval. Within the interrupt handler I wanted to initiate the SPI transfer using wiringPi. I already did some experiments to identify the delay from the occurrence of an interrupt to a change in my SPI chip select line. It differs a lot, in average between 120 and 190us (which would be almost acceptable). Applying a FIFO scheduler and high priority (chrt -f -a -p 90 PID) stabilizes the delay a bit, but rarely a delay of~1.1ms appears, which is even longer then the sampling interval.
Do you have any idea what might cause this delay? It confuses me, since the FIFO scheduler may not be interrupted until the transfer is complete (!?).
Code: Select all
//cdiv = roundup_pow_of_two(cdiv);