5 ms·
This article makes repeated references like the following: > If you want to perform real-time operations, the BeagleBone's ARM processor won't work well since
by greggyb 10y ago
This article makes repeated references like the following:
> If you want to perform real-time operations, the BeagleBone's ARM processor won't work well since Linux isn't a real-time operating system.
I get that Linux is not a real time system, but the article seems to be making the implication that the ARM processor cannot support real time operations. I was under the impression that the real-ness of time was determined solely by the operating system and not by the hardware. Is this not the case, or is the article just making the assumption that no one is going to port a real time operating system to the BeagleBone?
- AceJohnny2 10y agoAmusingly enough, performance enhancing features like cache or a flexible interrupt controller get in the way of a system's "real-timeness", because the timing of operations is no longer clearly deterministic. That's why ARM has cores like the Cortex-R series (R as in Realtime) that do promise real-time characteristics. The Sitara in the Beagleboard has a Cortex-A (A as in Application), which is not designed for realtime. So yeah, it's more than just the OS.
- Narishma 10y agoAFAIK you can disable (or rather not enable) the cache(s) and use a simple interrupt scheme in any standard ARM core (at least it's possible on the Raspberry Pi).
- Gibbon1 10y agoJust simply having interrupts will mess with a hard real time processes. Total sketchtastic, some modern processors have background stuff that takes control every so often.
- greggyb 10y agoThanks much. I learned something new from you and the sibling comment!
- revelation 10y agoI'm sure there is an real-time version of Linux that would work on the ARM, but these systems still have worst-case scheduling latencies of around 100us, and around 10us in just normal operation. So they are perfectly fine for some subset of real-time tasks, where you just need some sort of guarantee like "this thread will not be starved of CPU for 10 milliseconds". But that kind of latency and jitter isn't going to work out when you want to generate something like a fast PWM signal or send out audio over I2S in software or generally do any task that relies on reproducible (fast) timings. You could connect a servo to your real-time Linux generated PWM signal and it would tremble like it's drunk. And honestly, modern beefy ARM cores like the BeagleBone uses have been tuned for throughput above everything else that you will find it extremely difficult to get anywhere near the timing that a PRU can do and still have anything resembling a useful system. There's a nifty presentation from TI [1] where they have the ARM core do nothing but toggle one of it's GPIOs and it takes 200ns for that to go through all the various layers of caches, pin muxing, buses, interconnects, what have you. And that's a GHz processor! 1: http://processors.wiki.ti.com/images/3/34/Sitara_boot_camp_pru-module1-hw-overview.pdf http://processors.wiki.ti.com/images/3/34/Sitara_boot_camp_p...
- greggyb 10y agoThanks very much. I never realized this. I appreciate the time you took to answer.