RT-preempt or Xenomai + SPI?

[awallin]

Hi all,

I'm interested in real-time applications where I would read & write data over SPI from a real-time thread say every 1 ms (1000 times per second).

How realistic is this?
- is RT-preempt or Xenomai available for Olinuxino? (I am not keen on building a kernel myself - too hard)
- does anyone have real-time jitter/latency data measured with either RT-preempt or Xenomai?
- is there SPI read/write driver code that will work in real-time?
  (my application would read/write 16-24bits to say 1-8 SPI devices each millisecond)

There is lots of real-time application programming code (filters, PID-loops, etc) in LinuxCNC which I am familiar with. They can be run on both RT-preempt and Xenomai, so I am hoping they can be ported to olinuxino easily.

thanks for your answers,
Anders

[olimex]

please forum search before post!
https://www.olimex.com/forum/index.php?topic=812.0
as you can see xenomai on A13 have 8us MICRO seconds latency

[Tele]

Hiya Anders,

Just a few observations, maybe useful, maybe not.
Comparing Xeno and RT-preempt:
on a fully loaded system Xeno has about 8-10usec average latency, and about 20-25us worst case latency with about 10E-8 probability (thats quite rare, but some RT application needs to be planned for worst case, for example a milling machine will ruin the product, even if the program is late only once per half hour, that single case is too many already! )

RT-preempt patch has about 10 times more latency (about 100usec). Actually its much worse than Xeno, but still much-much better than regular kernel(standard kernel have 1msec latency or even more (20...50msec) on fully loaded system)

I use Xeno, because its nice and steady, RT-preempt has no real advantages compared to it.

SPI works on Xeno and/or on RT-preempt patched kernel without any problem. At least theoretically.
I have to mention that SPI (spidev) is quite fast when clocking the data out (I realized 50MHz on UEXT connector (SPI2) without any problem, documentation talks about 200MHz(!) max SPI frequency) but spidev works with FIFO queued ioctl command. That ioctl is an asynchronous command it wont be executed immediately, but later, when the kernel schedules it, can be late about 2-3msec(!) or more. Why is the precise, low latency (8usec) timer interrupt, if you cant give the command faster than a drunken turtle. Nah, unfortunately spidev is unusable in this case. If you wanna use SPI in real-time environment you have to emulate it with GPIO, or you have to write your own SPI driver for your device. Which one is better?
GPIO max throughput is about 2MHz on OLinuxino card (ports written directly via mapped memory). In emergency cases that can be hacked up to 3-4 MHz but not more. That must be enough for SPI purposes I think.

You said - "I'am not keen on building a kernel myself".
Hmmm ... sry to say but I think you must. You cant get it off so cheaply. Probably you wont find a pre-cooked solution, you have to do everything with your bare hands.
A guy, called uMinded started a thread about LinuxCNC somewhere here on Olimex forum. Maybe he can tell you more about these things, hes a clever one, try to search for his name. Another guy named Crubille is very good at Xenomai.

seeya,
Laci

[awallin]

Hi Tele,
Great info, thanks!

It seems others got Xenomai to work, so my remaining concern would be the SPI.

I am thinking about PID loops, preferrably with 1 ms loop time, so the spidev + ioctl FIFO does not sound too good.
I'd like to read one or a few ADC-chips over SPI, then do some PID or Feedforward + filtering in a real-time thread, and then write out to a DAC-chip also over SPI.

Do you know if someone already worked on SPI over GPIO? I think a 1 MHz or so SPI-clock would be enough for most purposes. Would this SPI over GPIO be vulnerable to xenomai-latency, or can the SPI-driver be written somehow atomically so it is never interrupted? I would think most ADC/DAC chips want to see pretty stable SPI-clock/signals?

Anders

[Tele]

Imagine it, like this:
   You set a 1 millisecond period timer interrupt, for the job. That interrupt arrives with delayed(latency), which is usually 10usec, but in worst case it can be 20-25usec. You can do anything, use USB, use network, use the SDD, load your CPU like a pig, but that interrupt will be there in time, at all cost, if its raining or snowing or shining doesn't matter. This is what xenomai (or any RTOS) assures for you. If you set that timer-irq thread's priority high (99 is the highest in xeno), then it never gets interrupted, you can do that, yes. But in that case you have to be in hurry, you must do everything very quickly, because many hardware stuffs on your OLinuXino can not wait, they need time slice for their correct working (USB,ethernet,so on..)
A simple PID is ok, not time consuming, but filters might be sophisticated (floating point, complex expressions, fourier-transform and harmonic analysis...so on)
If you can solve this timing problem, then I think your plan is totally realistic, makeable.

No, I dont know anyone who worked on SPI over GPIO, but SPI is so simple synchronous serial communication. ADC chip's datasheet always describes the exact protocol. Of course I assumed that you were a programmer or similar. Timing is not so critical, because there is a clock signal, and data is valid it's rising (or falling) edge. And don't forget you wont be interrupted anyway.

Another idea, just popped in my mind, try I²C ADC/DAC chips. There are many drivers in the kernel,
(Device Drivers --> Hardware Monitoring Support) for example Microchip MCP3021, Texas ADS1015,ADS7828..., Philips PCF8591 so on. Maybe the I²C drivers have no such a big delay as SPI has, I don't know, just an idea to check.