Real-Time OS for Control Systems

[CycloWizard]

This is sort of a feeler thread for me, so feel free to blow any of my ideas out of the water. A bit of quick background: I have no formal training in computer science or hardware design, but some experience at high-level work in both. I do quite a bit of MATLAB programming, and have recently started working on some C/C# for embedded systems (TI's MSP430 programmed in C, and some associated data logging in C#). My primary interest is in building new instruments which control motors and monitor sensors for engineering applications. I have a PhD in chemical engineering, but my interests have diverged considerably from the "chemical" bit.

Now that that's out of the way, here is my main idea: I was wondering whether it would be feasible for someone like me to put a computer together which monitors RS-232/parallel port/USB inputs, does some processing on their signals, and sends output accordingly in more or less real-time. I tried doing this at relatively long timescales a few years ago in Windows before I realized the futility of that approach, but I recently looked at the problem again. It seems like this should be possible using a stripped-down version of Linux or something, though I'm not sure if such a stripped-down operating system would allow me to interface with these devices using relatively high-level languages which simplify the interface to a simple procedure call (e.g. a call which reads the input from a serial port). If I have to write all of these procedures from scratch, then it's not really going to be an effective method for me and I'd have to stick with my reductionist embedded systems approach. Anyway, I guess I'm just looking for some input from people who might know a bit more than myself before I invest time into installing such an OS and trying to actually do this sort of thing.

 

[theevilsharpie]

A general-purpose version of Linux cannot guarantee real-time performance, no matter how much you strip it down.

IBM had a relatively recent article about the modifications to the Linux kernel needed to make it real-time, as well as a list of links for more info. It may help you out if you want to go this route.

http://www.ibm.com/developerworks/linux/library/l-real-time-linux/

The other alternative is to use a commercial real-time OS. Most of the embedded devices I've used recently have used VxWorks, but QNX is also an alternative.

 

[Nothinman]

There are patches to make Linux hard real-time and I think soft real-time is possible without much work, it depends on how restrictive your requirements are.

And any kernel should allow serial access just via normal file open/read/write/close functions. USB might be a bit more work, but there is libusb for writing userland USB drivers.

 

[CycloWizard]

Thanks guys. I might look into it for my next project if I have a bit of extra time to brush up on this stuff.

 

[RebateMonger]

QNX used to be the big real-time OS. It's been around for thirty years. I see it's still available and supported. I'm not in that business, so I don't know what the competition is today.

 

[Cogman]

x86 cannot be real time, It must complete the current instruction that it is on before it can process interrupts.

However, It can get pretty dang close to it if you can stomach a clock cycle delay.

Now, it really depends on what sort of approach you want to take and what you want to get out of it. if you are just looking for "really fast reading" then a simple application that monitors whatever port you are interested will do, but if you want real-real time, then you will need to create your own driver and IR code, that is going to lead to a need to learn some assembly (it ain't THAT hard).

http://www.isd.mel.nist.gov/projects/rtlinux/rtutorial-2.0/doc/ex05_isr.htm

If you have to write a driver, then I would suggest you stay as far away as possible from the USB port. Driver software for USB devices is very complex, the USB interface is far different from any other. Contrast that with the parallel and serial where they are basically "put a high voltage on Pin 1".

If you are interested, USB devices run on a client/server model. So writing drivers for them essentially means implementing an entire server system, it is a PITA.

 

[CycloWizard]

x86 cannot be real time, It must complete the current instruction that it is on before it can process interrupts.

However, It can get pretty dang close to it if you can stomach a clock cycle delay.

I can't think of anything I'd try that wouldn't be able to handle a few nanoseconds of delay... The problem is that trying to run this sort of thing in Windows means you're lucky if you even catch all of the UDP data sent at you every 2 ms from some of the controllers. Most of the systems I'm working with would benefit from a response time in the microsecond timescale, which means that in a few microseconds, I should be able to read the input, do some relatively trivial computation on that data, then set an output based on the result of the computation (essentially, some sort of feedback control). If someone is paying me $25k for an instrument, I wouldn't be taking a big hit if I bought a decently fast processor (a few GHz) to perform these tasks.

Now, it really depends on what sort of approach you want to take and what you want to get out of it. if you are just looking for "really fast reading" then a simple application that monitors whatever port you are interested will do, but if you want real-real time, then you will need to create your own driver and IR code, that is going to lead to a need to learn some assembly (it ain't THAT hard).

http://www.isd.mel.nist.gov/projects/rtlinux/rtutorial-2.0/doc/ex05_isr.htm

If you have to write a driver, then I would suggest you stay as far away as possible from the USB port. Driver software for USB devices is very complex, the USB interface is far different from any other. Contrast that with the parallel and serial where they are basically "put a high voltage on Pin 1".

If you are interested, USB devices run on a client/server model. So writing drivers for them essentially means implementing an entire server system, it is a PITA.

I've piddled around a bit with RS-232 and parallel port coding and they seem to be pretty straightforward, though I'm not sure how quick the response times might be. RS-232 seems to require parsing of the data to extract the information I need, whereas parallel is a bit simpler as you said (just check the value of the bit(s)). I have only a very vague notion of how USB works, so I'll probably stay away from that for the foreseeable future.

Thanks again for the insights. :beer;