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 Jeff ------------------------------------------------------------------------------ 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
