[Andreas] has created this tutorial on real-time (RT) tasks in Linux. At first blush that sounds like a rather dry topic, but [Andreas] makes things interesting by giving us some real-world demos using a Raspberry Pi and a stepper motor. Driving a stepper motor requires relatively accurate timing. Attempting to use a desktop operating system for a task like this is generally ill-advised. Accurate timing is best left to a separate microcontroller. This is why we often see the Raspi paired with an Arduino here on Hackaday. The rationale behind this is not often explained.
[Andreas] connects a common low-cost 28BYJ-48 geared stepper motor with a ULN2003 driver board to a Raspberry Pi’s GPIO pins. These motors originally saw use moving the louvers of air conditioners. In general, they get the job done, but aren’t exactly high quality. [Andreas] uses a simple program to pulse the pins in the correct order to spin the motor. Using an oscilloscope, a split screen display, and a camera on the stepper motor, [Andreas] walks us through several common timing hazards, and how to avoid them.
The most telling hazard is shown last. While running his stepper program, [Andreas] runs a second program which allocates lots of memory. Eventually, Linux swaps out the stepper program’s memory, causing the stepper motor to stop spinning for a couple of seconds. All is not lost though, as the swapping can be prevented with an mlockall() call.
The take away from this is that Linux is not a hard real-time operating system. With a few tricks and extensions, it can do some soft real-time tasks. The best solution is to either use an operating system designed for real-time operation, or offload real-time operations to a separate controller.
Other options include mixing a real-time OS micro-kernel with Linux (like Xenomai or RTAI), or using the PREEMPT_RT patches for the Linux kernel. Xenomai is readily available for the Pi and several other ARM boards like the BeagleBone.
Do you have any suggestions for a good introduction to Xenomai? It seems interesting, but all I’ve found are implementations and installation instructions– no real tutorials yet.
The article makes some controversial statements. Xenomai is currently used in quite a few serious applications, worth giving it a try!
Yeah I use RTAI over here myself on a PC. This site is such a joke.
RT_PREEMPT is sufficient in a lot of use cases. It’s also the simplest to use, since you hardly have to do anything differently once you have compiled a kernel with the patch.
When we design products that require a real time controller, we do something similar: ARM running a higher level OS for the UI, netwroking, file system and a PIC, running uCOS or something similar for the A/D, D/A, stepper motors, sensors, etc. They communicate with a simple serial protocol over a regular async link. The ARM makes data requests, issues commands and the PIC responds with data or a status message indicating, for example, “stepper #3, move complete, success”.
The other advantage of this dual processor approach, is that the code bases are completely separate, and one developer can do the GUI while another can work on the real-time code.
If you are lucky enough to have something like a TI OMAP, with two independent processors, you can probably combine them, but we find that two separate systems is easier for everyone. Sometimes they’re on the same PCB, sometimes they’re on different PCBs, it just depends on how dense we need to pack the hardware.
Source: EE doing industrial, consumer and medical embedded product design.
Hi,
As said in above comments, the beagle bone is a very interesting platform for real time. The
CPU integrates 2 independant real time units (PRUs). Being integrated, communication between
CPU, PRUs and peripheral is relatively easy. If anyone interested, I put some examples here:
https://github.com/texane/pru_sdk
For instance, we are using this platform to control switched power supplies: the main CPU runs a
typical LINUX for non real time tasks (network communication and user interface), and the PRU
runs the control loop, data acquisition and PWM generation using the high resolution PWMs. All in
one where it required FPGAs previously. At this price, this is pure winning.
What language do you use for the prus? Isn’t it a special kind of assembler?
(On the phone right now)
Hi Mathieu,
The language is a very accessible assembly.
For instance:
https://github.com/texane/pru_sdk/blob/master/example/pruss_iep/iep.p
Yes, the Beaglebone is a perfect platform for these types of applications. It has specialized hardware for doing things like driving stepper motors, driving PWM signals, quadrature decoder, continuous timestamping of events, event counting, etc. And of course if that isn’t enough, you have the two PRU units and the Cortex-M3.
If someone interested, an article to get started with PRU is here:
http://www.embeddedrelated.com/showarticle/586.php
also of note, the pi has 3 general purpose cpu cores in it
the ARM 700mhz is the main one running linux
but it also has a dual core VPU that is already running a proper realtime operating system (thats the blob providing all the closed source functions)
there is a mailbox API to run code on the VPU, so in theory you could insert a custom interrupt handler on it and do proper realtime on the VPU, totally ignoring the arm and whatever linux does
but without the source of the blob, you dont know which interrupt is free, and the VPU has no MMU, so its all in physical memory addressing
wow. are there C-Compilers for the PRU ? how can the limited PRU-Code/RAM size be overcome? from what i read the PRU can only access few KB of Code and RAM. is it possible to run eg. FreeRTOS on the PRUs?
I am using PREEMPT_RT patch and trying to implement a UDP connection in my PC(with real time features). Can anyone help me with the idea of implementing it? I am totally new to this