Connect with us

linux controlled hardware

Discussion in 'Electronic Design' started by Jean, Sep 21, 2006.

Scroll to continue with content
  1. Jean

    Jean Guest


    I'm looking for some controller boards I can control using Linux. I
    need three types of electronic boards:

    1. 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.

    2. relay device: I need to steer about 8 12V devices. I guess I need
    some relay board for this.

    3. Switch board: I have about 100 switches that I need to monitor.
    These are basic on/off switches like this one:

    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)

    Best regards,
  2. 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: (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
    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

    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.


    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:
    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??

    This is a full size PCI card and i never used this company' products - I just
    googled it up as an example.
  3. Jean

    Jean Guest


    Thanx for your reply!

    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..)
  4. neil

    neil Guest

    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).
  5. Donald

    Donald Guest

    There are so many micro controllers with a serial port, this would be
    the easiest way with out getting into the problems with PCI or parallel

    Adding a RS-485 interface to the serial port you can be over 1000 feet
    away from the host computer.

    Adding a radio interface to the serial port you can be miles away.

    Programming the serial port under Linux would be far easier than writing
    a device driver for a PCI device.

    So, find a cheap micro board in what ever country you are located and
    begin learning how to use that.


    PS: what country are you in ??
  6. 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.

    Good luck.
  7. Jean

    Jean Guest

    I'm located in Belgium (Europe)
  8. Guest

    Jean, et al,

    For LINUX peripherals, you might want to look into COMEDI.
    See URL:
    In particular, see the list of already-supported boards:

    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

    I'm only just looking into this myself.

    Hope this helps,

    -- Larry
  9. Ken Smith

    Ken Smith Guest

    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.
  10. Donald

    Donald Guest


    This I would like to know more about.

    How you tried this your self ??

    Do you have any links that make it "easy enough" ??



    I believe this.
  11. Ken Smith

    Ken Smith Guest

    "I have not done it" means much the same as "I have not tried it" so why
    did you conclude I had?
  12. Guest

    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:

    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).
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day