I'm looking for some controller boards I can control using Linux. I need three types of electronic boards:
LED controlling device: I need to be able to control about 100 LEDS, so basically on or off. Every led needs to be controllable seperately.
relay device: I need to steer about 8 12V devices. I guess I need some relay board for this.
Switch board: I have about 100 switches that I need to monitor. These are basic on/off switches like this one:
formatting link
Speed is quite important for 2&3, that's why I'm planning on using Real time linux. I need to keep latency to a minimum.
Could somebody point me to some designs I could make myself? Or perhaps there some ready made boards I can just buy somewhere online? I was planning to use a miniITX board to run the Realtime linux on. I'm not sure what the best interface is for these boards? PCI, printer port, serial? Of course the number of PCI slots, printer and serial ports are limited on such a device.
As you might have guessed I'm not an electronics engineer, so I can't design this stuff myself. I can however 'read' a electronic design and solder a board myself. But perhaps of the shelve boards are a better option? (especially if I need to start debugging a self made board)
But obviously not that important since you do not have bounding numbers for it.
With standard Linux Kernel 2.6.18 you will get latencies from 1 msec to about 10 msec and for that you might need to build the kernel yourself to set the highest
1 khz tick rate.
There is a high resolution timer patch about to become standard "real soon now" that in principle removes the tick and gives usec resolution:
formatting link
(on some platforms). I see that the code now looks like it might work on more than an 80x86 box with the original 8047(?) PIT timer - and there are some references in kernel changelog on
formatting link
so maybe it is really "soon" this time ;-)
I.O.W: You might be lucky and get what you want just by patching the vanilla kernel.
RT-Linux is a bit of a hack:
From the RTLinux home page: """ Realtime tasks are privileged (that is, they have direct access to hardware), and they do not use virtual memory. Realtime tasks are written as special Linux modules that can be dynamically loaded into memory. The initialization code for a realtime tasks initializes the realtime task structure and informs RTLinux kernel of its deadline, period, and release-time constraints. """
I.O.W:
Your programs will not acquire real time properties on Real Time Linux, only special kernel modules that you write yourself as "RTLinux compatible" will!
Montavista produces a kernel that has more realtime-like performance. Many of Montravista's enhancements are now part of the standard kernel.
I am not saying all this to rant, just to point out that you might become sucked into an unneccesary detour of kernel hacking and grief because you have not decided if "90% latency below 2 msec and occasionally above 10 msec" is real-time enough for you.
PC-104 is probably what you want because that format is dedicated to industrial control and industrial control wants lots of I/O.
There are many to choose from:
formatting link
I would let the PC104 system run the time critical stuff and use another box to control it from. If you run X, network, file system and god knows what else a typical Linux distribution thinks is essential then your real-time performance will suck.
The affordable PC-104 hardware tends to be 386SX'en and Pentium 266, National Geode, and so on. If you absolutely must run everything from one piece of hardware, it is often useful to do a minimal "server" install and then install a very light GUI such as "fluxbox", (assuming that you have enough sense to use a package-based system). Gnome is obscenely bloated these days - really needs
64bit Athlon 3000++ and 2Gig++ just to not appear sluggish ;-).
I use Ubuntu "dapper drake" on an old SUN Ultra Sparc 10 with 433 Mhz CPU and
256 MB RAM at home - the "server" install + "fluxbox" is what keeps everything from grinding to a halt.
If you can buy something and hack that, it is always much better; Can you do this yourself + drivers for USD 192? In less than one hour??
formatting link
This is a full size PCI card and i never used this company' products - I just googled it up as an example.
I will look into these PC104 boards. I was already planning to do a minimal install of my linux system without any X Gui. However I need the system to play some sounds from time to time so perhaps using my miniITX board for steering the pc104 board and playing sound (some wavs or mp3z) will keep the latency to a minimum.
I will have a look at those pci boards you suggested me. I will defenitly go for of the shelve products as much as possible.
I think I will start by reading the manuals of some of those pci boards... (RTFM usally pays of..)
Not wishing to stir things, but a couple of noddy thoughts ... won't the relays have a switching time of several milliseconds and the switches also Will this have an effect on the latency ? I've used DOS in the past for simple 'real time' stuff, to avoid the possibility of Windows going off doing its own thing. Seemed to work OK (in the limited way I needed it). hth Neil
"Jean" skrev i en meddelelse news: snipped-for-privacy@i42g2000cwa.googlegroups.com...
Sound is not really a problem any more because the kernel is now fully pre-emptible. In practice this means that interrupts are handled "immediately" and not only every timer tick as in the old days of before Kernel 2.6.16. Sound is mostly interrupt driven. Once there was a need for "low latency patches" and "preemption patches" those days are long gone. User processes will still have jitter and scheduling latencies - even on "realtime" priority.
You still might need to rebuild the kernel because some distributions are not compiled to be pre-emptible out-of-the-box.
Well, find one with Linux drivers and some sample code, buy it and start playing with it. That's the fastest way I.M.O.
For LINUX peripherals, you might want to look into COMEDI. See URL:
formatting link
In particular, see the list of already-supported boards:
formatting link
Untortunately, the list isn't organized by category of peripherals, but I do see "DIO" (suggestive of digital IO) in some of the National Instruments boards.
There is no need to convert from standard RS-232 at lowish baud rates. From a desktop PC you can typically transmit RS-232 10E6/BAUD feet.
[....]
I have not done it but I have been told that doing a device driver under Linux is easy enough that there is no good reason to add an external micro on an Linux embedded system. Under Windows, however, it seems to be the way to go.
I have and it is not that hard. Certainly character devices are easy to play with. Block devices are slightly harder but not too much. The best part is, you don't need to handle *everything* in the device driver if your device is character (8bit) oriented. Just write the most basic thing you need (or steal code from examples like me) to get 8 bit data in and out or your device and create a node for it in /dev. Then you can simply "cat" and "echo" to and from it like an ordinary file. This also means you can then use whatever higer level language you like to control your device as long as it can read and write to a file.
The *Bible* of Linux device driver hacking, O'Reilly's appropriately named "Linux Device Drivers". Also available online for free (and constantly updated) here:
formatting link
Lots of sample code in there to steal from. Just copy, paste, modify and compile.
Before I forget. I strongly recommend developing and prototyping device drivers on a dedicated machine, not your main machine. You're playing inside the kernel now and you no longer have all the nice protection you had in userland. No segfaults here, the machine will simply hang (or worse if it's controlling a 1 tonne robot arm).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.