One of functionalities I miss the most from "small embedded" in Embedded Linux is the interrupts. A signal appears on a specific pin, or other interrupt source is triggered and whatever was done inside the CPU gets interrupted, and my function of interrupt handler is launched. In Linux everything is buffered, if something happens the system just goes about its own course and when (at last) given thread is brought to foreground, its wait-state expecting the external source ends, and its handler starts.

The closest thing I know are the signals, which can trigger a handler interrupting normal flow of the thread, but still, the handler will not pick up the signal until the kernel brings the thread into foreground, which may be many milliseconds after the signal happened - and triggering the signals isn't as robust either; I need an app or a kernel module to send a signal, I can't just trivially attach it to a GPIO pin.

How could I achieve a functionality similar to hardware interrupts within Linux userspace software - have a specific function launched or specific thread brought to foreground immediately after an externally sourced condition is triggered, without waiting for the process queue to bring my thread to foreground?

If you feel this question is too broad, let's narrow it to a specific example: a Raspberry Pi board receives a signal on one of its GPIO pins (not necessarily arbitrary; if only some pins can do that, that's okay.) I want my userspace application to react to this event within least time possible, be it bringing it out of wait state, launching a handler function or any equivalent mechanism, but above all not waiting for the task queue to cycle through all pending processes before the handler is brought to foreground, but trigger it ASAP. (and specifically, when there is no signal, not leaving the system locked forever with the handler process occupying 100% CPU time polling the input and never yielding to the OS.) Is there such a mechanism?

  • 2
    A potential solution might be writing your own kernel module for this.
    – Zack
    May 21, 2014 at 15:57
  • 2
    @Zack: Yes. Writing your own kernel module is a potential solution to about every Linux problem :)
    – SF.
    May 21, 2014 at 16:23
  • Agreed. A kernel module is what you will need. All the user app stuff is at the mercy of the operating system and will not execute in a reliable amount of time. It can vary considerably. It's just not possible to do this in the userspace.
    – user113
    May 21, 2014 at 18:26
  • This is a tricky one, because userspace questions were supposed to be off topic here, how can we resolve this? I'm thinking modules along with the rest of everybody, would you accept that as a valid answer? More detailed of course, but along the module vein?
    – MDMoore313
    May 21, 2014 at 18:57
  • 4
    @BigHomie: Nope, userspace questions about writing applications for embedded systems? Realtime or realtime-like, reacting to outside signals? It's the "piercing abstraction layers to access raw iron" domain.
    – SF.
    May 21, 2014 at 19:05

3 Answers 3


If I understand your question this articled sounds like what you're looking for. The article is titled: Device drivers in user space.


UIO drivers

Linux provides a standard UIO (User I/O) framework for developing user-space-based device drivers. The UIO framework defines a small kernel-space component that performs two key tasks:

  • a. Indicate device memory regions to user space.
  • b. Register for device interrupts and provide interrupt indication to user space.

The kernel-space UIO component then exposes the device via a set of sysfs entries like /dev/uioXX. The user-space component searches for these entries, reads the device address ranges and maps them to user space memory.

The user-space component can perform all device-management tasks including I/O from the device. For interrupts however, it needs to perform a blocking read() on the device entry, which results in the kernel component putting the user-space application to sleep and waking it up once an interrupt is received.

I've never done this before so I can not offer you much more guidance than this, but thought it might be helpful towards your quest.

  • I wonder if this 'waking up' is anything more than just satisfying the blocking read when the userspace part wakes up naturally. If it is (the kernel-side really bringing the user-space task to foreground on interrupt), then this is exactly what I seek.
    – SF.
    May 22, 2014 at 4:50
  • 2
    When the kernel wakes a task for IO completion, I believe it will get some priority boost. It will not provide a hard guarantee for the worst-case latency, however, since there are lots of reasons that just making the process runable will still leave lots of work to do before the process can actually run. But it is probably the best latency that you can get from an unmodified kernel.
    – RBerteig
    May 22, 2014 at 5:23

Thinking along the same lines as @RBerteig, the BeagleBone Black contains Programmable Real-Time Unit (PRU) 32 bit microcontrollers.

It doesn't look like there's a huge community using these things to full capability. I'm not even sure there's a good compiler for this. The advantages over an assembly of an SBC and a microcontroller or microcontroller board are that the PRU code can come from the main ARM, and shared memory is pretty convenient.

Can't say I've used this, or even that I've run more than some examples on my BeagleBone Blacks yet, but the needs expressed in this question might be one of those things that can nudge a developer with these needs towards the Black and away from the Pi.

  • 1
    That sounds quite awesome. If the communication is over shared memory I really could defer a realtime thread there and just use simple mechanisms like taint bits to assure synchronization with common userspace.
    – SF.
    May 23, 2014 at 14:21
  • Yeah, there seem to be some nifty features on this platform that make it a tool quite different from the Raspberry Pi. I'm surprised it doesn't come up more often. The PRU's are the feature that raised my eyebrows and made me buy two as soon as they became available, but I haven't really put any effort into them yet. As a heads-up, unless they've come up w/ a signed windows device driver, install will fail on Win8 flavors with no good error message. You need to boot into a troubleshooting mode to install unsigned drivers. May 23, 2014 at 14:31
  • Also, those PRUs look like they clock at 200MHz! May 23, 2014 at 16:54

Thinking outside the box for a moment, this might be a good example of a use for something like the ala mode board. This is a "pi plate" that contains a complete Arduino. You would build your hard real time response, bit-banged bus protocol, or other deeply embedded logic to run in its AVR processor, and communicate over a higher latency channel back to a process in Linux.

The ala mode is not the only hardware choice available off the shelf. A comparable Arduino model that provides both Linux and Arduino is the Arduino Yún which has both a MIPS based embedded Linux SOC, as well as an AVR. Arduino has also announced the Arduino Tre based on an ARM SOC, but it has been "coming soon" for a year now. If both the RPi and the Arduino could benefit from more horsepower, there is also the UDOO, with a quad core ARM CORTEX-A9 and GPU running Linux or Android, and the same Atmel ARM CORTEX-M3 chip as on the Arduino Due.

If your problem is amenable to this partitioning, you get all the advantages of a deep embedded system running directly on the metal with no OS layer between you and the GPIO pins, while still having a full Linux kernel behind you to handle networking, business logic, user interface, and complex hardware like disk drives and video. If an Arduino isn't sufficiently powerful for your low-level processing, then there are lots of alternative deeply embedded chips and modules to consider, nearly all of which will have a UART, I2C, or even USB available for communications to the Linux end of things.

One advantage of this architecture is that you likely do not need to touch the Linux kernel at all. The hard real time code is running outside the kernel in its own CPU, and communications between the two can use existing drivers and protocols.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .