I’m looking for a means to do real-time scheduling on a BeagleBone with the Angstrom distro. Is it possible? I’ve been trying, but failing…
Whenever I try programmatically using pthread_setschedparam, I get “Operation not permitted” errors even when logged in as root.
When I try with the “chrt” command to change a process to use SCHED_FIFO, it reports back that the process is using SCHED_OTHER, effectively ignoring my request.
If real-time is not possible with Angstrom, can anyone recommend a quick path to get there with another distro or add-on to Angstrom?
I have one simple real-time requirement. I need to detect an edge of a GPIO signal and take an action within 1 millisecond of that edge, guaranteed. I’m doing this with user space GPIO calls, blocking a thread waiting on a GPIO edge event. I’m measuring response time by watching another GPIO that I assert when the sleeping thread wakes up. Without real-time scheduling, many edge events are detected and responded to in under 1 ms, but the worst case time is sometimes as long as 20 milliseconds. I could live with 2 or 3 ms, if reliable, but 20 ms is just too slow for my application.
Would a kernel module doing the same job experience better worst-case response times?
I'm looking for a means to do real-time scheduling on a BeagleBone with the Angstrom distro. Is it possible? I've been trying, but failing...
Whenever I try programmatically using pthread_setschedparam, I get "Operation not permitted" errors even when logged in as root.
When I try with the "chrt" command to change a process to use SCHED_FIFO, it reports back that the process is using SCHED_OTHER, effectively ignoring my request.
If real-time is not possible with Angstrom, can anyone recommend a quick path to get there with another distro or add-on to Angstrom?
I have one simple real-time requirement. I need to detect an edge of a GPIO signal and take an action within 1 millisecond of that edge, guaranteed. I'm doing this with user space GPIO calls, blocking a thread waiting on a GPIO edge event. I'm measuring response time by watching another GPIO that I assert when the sleeping thread wakes up. Without real-time scheduling, many edge events are detected and responded to in under 1 ms, but the worst case time is sometimes as long as 20 milliseconds. I could live with 2 or 3 ms, if reliable, but 20 ms is just too slow for my application.
Would a kernel module doing the same job experience better worst-case response times?
I would imagine this would be no problem for a kernel module, it should even be possible in userspace, how are you blocking your thread? Are you polling an edge triggered interrupt, that's how I would do it.
As for guarantees, well, as Linux isn't realtime without additional patches then you're going to struggle to prove that it will _always_ complete within a certain time frame but with good, solid code and an understanding of exactly which part should be as close to realtime as possible, it is possible to get somewhere near.
I would imagine this would be no problem for a kernel module, it should
even be possible in userspace, how are you blocking your thread? Are you
polling an edge triggered interrupt, that’s how I would do it.
That’s what I’m doing. I configure the GPIO pin as an edge, open the value file, initialize a file descriptor set, and hang on a poll() call.