Teaching Real-time Systems

Drop in for a chat and a cup of tea

15 posts
by tigger908 » Tue Dec 13, 2011 11:22 am
Hi All,

I'm a lecturer currently teaching amongst other things an introductory module on real-time systems. Could anyone tell me if/how I could use the RasberryPi in this? I wondered if MuCos2 or similar would be an option?

Regards,

T.
Posts: 3
Joined: Tue Dec 13, 2011 10:17 am
by Davespice » Tue Dec 13, 2011 12:12 pm
I don't see why not... I've seen less powerful machines used in real-time systems.

I wonder if you could connect the serial output of a private telephone exchange PBX via an RS232 to USB adapter and write something in python to react to it. Maybe a simple program which shows who is on the phone or not? You would probably have to do a lot of string matching and parsing, might be a good way to teach them RegEx though.

Is that the kind of thing you were thinking of?
User avatar
Foundation
Foundation
Posts: 1418
Joined: Fri Oct 14, 2011 8:06 pm
Location: London, United Kingdom
by dpawson » Tue Dec 13, 2011 1:05 pm
1. Think about your realtime needs? Microsecond response? Human response times? Something in between?
2. Choose your OS to match your answer to 1.

3. After that rpi should be perfect. Fast response, assembler level tools free, good enough IO for teaching purposes.

Ideal IMHO

Dave
Posts: 115
Joined: Mon Nov 14, 2011 5:05 pm
by Hugh Reynolds » Tue Dec 13, 2011 1:47 pm
The only thing missing is a clearly defined method of getting an interrupt into the system. If you don't need interrupts it is not a reattime system IMHO.

It may have been here on the forum that I read that all GPIOs can generate interrupts but as we have so little info on the GPIO, I2C, SPI and UART interfaces that's difficult to be sure about. All will become clear in the near future.

I would have thought that you could use any of Debian, Fedora et al as your OS. Not necessary to work with ?C/OS-II or any of the other kernels out there and difficult unless they release a support package for the RPi

I use an ARM running at 120MHz and that is pleanty fast enough for my hard realtime embedded systems so the RPi should be fine with the 'Linux like' OS. There's not much difference in hooking into a Linux interrupt device driver and using one managed by ?C/OS-II.

Looks like a perfect platform for learning/teaching. IMHO.
Posts: 61
Joined: Tue Sep 06, 2011 9:48 am
by andywe » Tue Dec 13, 2011 2:05 pm
It depends on whether you are thinking about Hard or Soft real time ...
For soft real time Linux (and there are various Embedded Linux flavors that should run on the RaspberryPi ...) the Raspberry platform is fine ...
You can use memory mapping to access GPIO, and libusb to access "widget like sensors" of the Phidget variety ... or, even better start developing "open Phidgets" ... but be careful not to fall foul of the "Copyright laws" ...
You might also look at some of the Velleman boards and how they can be driven from a Linux platform over USB ...
You can even do CAN by accessing suitable CAN controllers e.g. over SPI or I2C
Posts: 44
Joined: Thu Dec 01, 2011 5:09 pm
by tufty » Tue Dec 13, 2011 9:34 pm
Quote from Hugh Reynolds on December 13, 2011, 13:47
It may have been here on the forum that I read that all GPIOs can generate interrupts but as we have so little info on the GPIO, I2C, SPI and UART interfaces that's difficult to be sure about.

#define INTERRUPT_I2C (ARM_IRQ0_BASE + 15)
#define INTERRUPT_SPI (ARM_IRQ0_BASE + 16)
#define INTERRUPT_I2SPCM (ARM_IRQ0_BASE + 17)
#define INTERRUPT_UART0 (ARM_IRQ0_BASE + 19)
#define INTERRUPT_GPIO0 (ARM_IRQ2_BASE + 17)
#define INTERRUPT_GPIO1 (ARM_IRQ2_BASE + 18)
#define INTERRUPT_GPIO2 (ARM_IRQ2_BASE + 19)
#define INTERRUPT_GPIO3 (ARM_IRQ2_BASE + 20)

UART is pl011.
Posts: 1330
Joined: Sun Sep 11, 2011 2:32 pm
by tigger908 » Fri Dec 16, 2011 10:49 am
Many thanks for all your responses, I'll probably try something with Fedora (my OS of choice,) on the RasberryPi. I think I read somewhere that there are real-time elements in the current Linux kernel.

I've got several students interested in the RasberryPI already, perhaps I can set up some sort of group here at the university.

Regards,

T.
Posts: 3
Joined: Tue Dec 13, 2011 10:17 am
by selvmarcus » Sun Jan 08, 2012 7:53 am
One can always hope. I am waiting for about 15 years for some kind of realtime processing (audio) becoming possible on Linux. The kernel is certainly capable of doing  quite well now that for example preemption during system calls is possible (Big Kernel Lock gone), there are realtime scheduler policies and drivers are behaving most of the time.. a lot of effort has been put into this during the last years, for example by kernel developer Ingo Molnar and other enthusiasts.

But no one can say for sure what"s the matter here until there are proper tests done on the board, with recent realtime or low-latency enabled/configured kernels. The gpu/driver with its possible high bus demands is the big if. IF designed and executed properly, it should work. But don"t just expect it, or you may be disappointed, because this board and SoC has clearly not specifically designed for realtime processing,  but more as a small low-power HD media player and OpenGL-engine under linux control.

For games and video, it just doesn"t matter this much.

Check out the XENOMAI project, it's available  for ARM and plays with recent linux kernels, it has a realtime model for drivers and threads which could possibly be used for controlling GPIO, timers, ... on the Pi, running below the kernel level, as a minimal nanokernel beneath catching some of the interrupts (Depending on getting enough hardware specs to implement it).

It is well designed also for industrial applications, maybe got a too complex model to use for education? But there this a set of Xenomai skins mimicking traditional RTOS APIs, it could be helpful for learning and studying different options.

Integrating Hard Real-Time into Linux

http://www.xenomai.org/index.p.....ai:Roadmap

All the best, Marcus
Posts: 18
Joined: Sat Jan 07, 2012 1:21 pm
by Gert van Loo » Sun Jan 08, 2012 12:37 pm
FatBuzz said:


...

It may have been here on the forum that I read that all GPIOs can generate interrupts but as we have so little info on the GPIO, I2C, SPI and UART interfaces that"s difficult to be sure about. All will become clear in the near future.


Every GPIO can generate an interrupt on any edge or level.

Hold tight: I generated a data sheet and it is being revised. With a bit of luck we have a Raspberry-Pi Peripheral datasheet in the next week or so. It tells you all about not only GPIO but also SPI, UART, PCM/I2S,  I2C, USB, Interrupts & the ARM timer.
User avatar
Moderator
Moderator
Posts: 1843
Joined: Tue Aug 02, 2011 7:27 am
by JonB » Thu Feb 02, 2012 8:53 pm
Wondering why you are starting with a "make Linux real time" approach.

Should you not be starting by getting your students to write their own real time scheduler (in assembly)? That's how I learned, from the ground up... and obviously you can use the Pi as the dev environment (we used a Unix system with hardware emulation boards that ran 68000 processors).
Posts: 218
Joined: Tue Nov 29, 2011 9:26 pm
by Bakul Shah » Thu Feb 02, 2012 10:08 pm
Marcus V. said:


One can always hope. I am waiting for about 15 years for some kind of realtime processing (audio) becoming possible on Linux.


Too bad Massalin's Synthesis Kernel ideas don't seem to have gone anywhere. The original paper on the Synthesis kernel came out in 1988 where they talk about a music synthesizer running in real time @ 25kHz sampling rate on a 20Mhz 68020! As someone put it, Massalin takes Amdahl's Law (optimize the common case) to the extreme. He/She uses kernel code synthesis, collapses layers, nonblocking synchronization, minimal context and lazy context switching, fine grained scheduling, specialized queues etc.  Massalin's thesis was published in 1992 and certainly worth checking out for some great ideas. It is really pitiful that a general purpose OS on a 3Ghz multicore machine today can still not provide a smooth human/computer interface, let alone meet the much more stringent real time requirements of devices.
Posts: 291
Joined: Sun Sep 25, 2011 1:25 am
by pygmy_giant » Sun Apr 29, 2012 9:00 pm
Would it be possible for someone cleverer than me to adapt Chibios fo the Pi - it states that it supports Armv6-M on the LPC11xx http://chibios.org/dokuwiki/do.....hitectures
Ostendo ignarus addo scientia.
Posts: 1567
Joined: Sun Mar 04, 2012 12:49 am
by Clifford » Fri May 04, 2012 5:11 pm
OK, I am a real-time systems practitioner, and lets be clear about one thing.  Linux is not a real-time OS.  Even when built with the real-time scheduler policy, it is not a real-time OS.  It is suited to many embedded applications, especially where connectivity and graphical displays are required, and system resources are plentiful, and it may be suited to some classes of real-time system, but it is not suited to a large proportion of hard-real-time applications with context switch and interrupt latency times required to be of a few microseconds or less. There is also a large proportion of cost-sensitive, high-volume, low margin applications where hardware costs must be minimised – making Linux unsuitable.

Linux requires huge resources just to boot, a typical real-time priority based pre-emptive scheduler with inter-process communication (IPC) primitives, will come in at less than 10K of code, and a few tens of byte of RAM per thread, plus thread stacks which may be as small little as 128 bytes on ARM for simple tasks.  Linux will just about boot to something useful from 4Mb of ROM and there is probably good reason why RPi Model A will no longer have just 128Mb RAM!

I have taken a look at the minimal hardware data sheet released by Broadcom, and the RPi schematic, and I believe that there is sufficient technical information to get any ARM11 targeted RTOS to boot using the UART for standard I/O. Accessing the exposed header pins is straightforward.  Hooking up to a USB keyboard and display via the GPU/HDMI are a somewhat more complex task, and would require significantly more software and more technical data than is probably available at present.  Even a minimal USB HID stack is quite complex, and you need the details of the USB controller to get it to work.

Accessing the SD card should be possible, a simple FAT FS library such as ELM or EFSL is easy to port, although I have only used then in SPI mode, not SDIO, so it would be down to sufficient information from Broadcom.

For both the USB and SD it is likley that there is firmware already on the RPi ROM since it uses both I imagine in the bootloader.  Finding out how the bootloader works will be key to loading an RTOS from SD rather than re-flashing the firmware, probably rendering the RPi unable to ever boot Linux again!

In the end a more expensive, less powerful, but more open platform such as Beagle-board, or Panda-board may be a better bet. You might even ask chip vendors for free evaluation kits – they often will for education since it familiarises future engineers with their parts.  These boards certainly have more I/O and expansion capability as well as more on-board devices such as switches and LEDs and even displays to save you having to hook up your own hardware.

Now as a practitioner of 23 years experience, if I interviewed a graduate that did a real-time system course taught using Linux, I'd be very sceptical about their concept of real-time systems, and would be asking them some hard questions.  So I think @tigger908 is right to be considering uC/OS-II, especially is Jean Labrosse's book is the course text.
Posts: 30
Joined: Fri May 04, 2012 3:19 pm
by danpeirce » Thu May 10, 2012 5:28 pm
It would seem to me one would offload low latancy real world interfacing onto a MCU connected to the RPi via SPI or I2C and use the RPi for the networking/mass storage/HumanInterface.

We have been using PIC18F4525s for some years with students to control simple robots. I think we would like to do some new projects and have the data coming from sensors available to PC's and it looks to me like a very simle route to this is the RPi which includes the LAN access.
User avatar
Posts: 88
Joined: Thu May 10, 2012 8:32 am
Location: Richmond & Surrey BC Canada
by colinbroad » Fri May 18, 2012 8:03 am
I am looking at Raspberry Pi as an user interface to real time systems and not as a real time device itself. The main advantages that I see are 1) life expectancy, 2) price,, 3) Ethernet, 4) LCD display, 5) Host USB interface.
Posts: 1
Joined: Fri May 18, 2012 7:55 am