If your device uses PREEMPT-RT realtime, then you can use any userspace
interface (ioctl, read, write, recv, send, etc) that gives you
acceptable latency in practice.  Otherwise, you basically get to do
direct memory-mapped control of the applicable registers in your SOC,
because for xenomai and rtai you can't use standard kernel or syscall
interfaces in realtime context (but you can for setup/cleanup code, for
instance to get actually map MMIO regions)

The SPI hardware interface, with /dev/spidev as a userspace API, is
perfect on paper; however, I have experenced that the quality of the
driver implementation is often poor, both in latency and in, well,
actually working!  

Here are some notes about various ARM SBCs and SPI interface hardware.
Except for odroid c2, these are all my direct experience.

odroid u3: /dev/spidev working with good latency (good enough for 1kHz)
after kernel driver modifications, linuxcnc driver hm2_spi, mesa 7i90
fpga card

odroid c2: reported non-working (only supports 8-bit transfers)

odroid xu4: does not honor spidev byte order ioctl (hardcoded in
devicetree).  poor latency even after kernel driver modifications
(probably ok for 500Hz, probably not for 1kHz).  hm2_spi driver again.

raspberry pi 3: only supports 8-bit transfers.  contributed
register-level driver, confirmed working on preempt-rt (only--will need
work for other supported rtoses), hm2_rpspi


Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Emc-users mailing list

Reply via email to