4 ms·
Why do the PRU's exist? Part of the reason is that real time programming is kind of hard. It's much easier to reason about if you have dedicated processors per
by etaioinshrdlu 8y ago
Why do the PRU's exist? Part of the reason is that real time programming is kind of hard. It's much easier to reason about if you have dedicated processors per task!
My experience with real time systems led me to believe that RTOS's are kind of harmful and don't live up to expectations.
Using an RTOS felt basically like a regular OS but with cooperative multitasking. I could never separate the time consumption of one task from another and think about them in isolation.
What I really ended up wanting was preemptive multitasking.
But to instead divide the CPU time into fixed allocation of say 10 to 100 tasks, each with a dedicated slice of CPU time that never varies.
Then you can finally reason about tasks in isolation!
Interrupts are then disallowed.
It's basically equivalent to having a bunch of little CPUs communicating. (One should try to use ring buffers for all communication, not shared memory.)
To me, this is the only real time architecture I feel smart enough to even handle.
- guan 8y agoDon’t some of the commercial RTOSes have optional fixed, time slot–based scheduling like you describe? I thought I had seen that, but now I can’t find any examples with some simple searches.
- Gibbon1 8y agoMost of them will support that. It's not actually that big of a jump between cooperative to preemptive multitasking. Preemptive can give lower latency, but you can still have high priority tasks blocking lower priority ones. Work arounds exist but they aren't a panacea.
- pstuart 8y ago> One should try to use ring buffers for all communication, not shared memory Could you expound upon that?
- etaioinshrdlu 8y agoIt is a similar concept like used in Go and Erlang. Don't use shared memory and locks, instead, send messages between processes. It works great with embedded real time systems as well. It can be easier to get right than the alternative -- because without locks, the performance is more predictable. Less chance for race conditions and deadlocks as well. It is also basically the same thing as hooking up different processors with a bunch of serial ports. UARTs typically have a hardware ring buffer for send and receive. So basically, you simulate a bunch of separate processors all communicating. You could do it in hardware, or within software. Both work equally well.
- pstuart 8y agoThanks for the detailed response.
- mch82 8y agoI think what you’re describing is one of the objectives of the Nerves Project (https://nerves-project.org https://nerves-project.org), which happens to include the BeagleBone as a target platform.
- etaioinshrdlu 8y agoNerves doesn't look terribly amenable to realtime in design, however. About as amenable as running Node.js on linux. Not a great solution for strict timing requirements.
- thebruce87m 8y agoWould you not need to use locks for the ring buffers?
- learc83 8y agoHere's a good explanation from Linux Device Drivers, Third Edition. "When carefully implemented, a circular buffer requires no locking in the absence of multiple producers or consumers. The producer is the only thread that is allowed to modify the write index and the array location it points to. As long as the writer stores a new value into the buffer before updating the write index, the reader will always see a consistent view. The reader, in turn, is the only thread that can access the read index and the value it points to. With a bit of care to ensure that the two pointers do not overrun each other, the producer and the consumer can access the buffer concurrently with no race conditions."
- petschge 8y agoLitmus, a real time extension of the linux kernel allowed such partioned scheduling. The last version is based on 4.9.30 and there is not plans to maintain it. Check https://www.litmus-rt.org/ https://www.litmus-rt.org/ for more details.
- monocasa 8y agoEven Litmus isn't great here AFAIU. The issue is that you kind of need to design the kernel from the ground up to not have potential long times between preemption points.
- learc83 8y agoI designed a product once using a Parallax Propeller. I loved it because it had 8 CPU cores that had rotating access to shared memory and no interrupts. If I remember correctly I did implement a ring buffer to handle communication between cores. I think the Propeller 2 is close to being released now that I think about it.
- etaioinshrdlu 8y agoTotally. Now that is a nice architecture. It looks like it may have trouble attracting wide industry adoption as it is a little idiosyncratic with Spin and custom languages for everything...
- learc83 8y agoYeah Spin is a definite barrier. Right when I was wrapping up my design, Parallax was just starting to encourage people to use the C compiler in production. I would guess the Prop 2 will be similar. It's still different enough to scare a lot of people off, but I'll give it a shot. I went poking around the forums and it looks like they just shipped out the first 100 evaluation boards in December.