3 ms·

The PRUs have no bus, their GPIO is in the register file and memory is SRAM. They do have access to the beefy ARMs bus, which makes them infinitely more useful

The PRUs have no bus, their GPIO is in the register file and memory is SRAM. They do have access to the beefy ARMs bus, which makes them infinitely more useful than a cape. More often than not a cape will not solve the problem because quelle surprise, there is then just no low latency reliable path to control the cape from the ARM. So you've just shifted the issue for a 100x increase in complexity.

bsder 10y ago
Sure, if you need hard real-time control, a much simpler processor with a much simpler OS (or none at all) is going to do it better. Absolutely. Arduinos and Cortex-M's win here. However, I find that a VERY small amount of programmable logic on a cape often takes care of the hard-real time problem while the BeagleBone gives me a Linux backend to work against. Even if I find that the Linux side of things has too many hiccups to be reliable, the time saved in development because I can lean into a very powerful process with quick iterations before transferring to a leaner, more restricted processor is valuable. And, often, people find out that their hard real-time isn't as hard as they thought. Sure, if I have a safety system, I'm going to be religious about maximum latency. However, if I have a machine controller, overkilling processing power is often way cheaper (and faster to develop) even if I get the occasionally glitch that causes a fault which needs human intervention.
- willglynn 10y ago
  The BeagleBone's CPU has a normal ARM processor and a pair of PRUs. (This is much like how the Cell processor had a normal Power processor alongside some Cell SPUs.) PRUs can control GPIO pins running your dedicated, hard-realtime code without an OS, and they can do it while Linux runs on the same chip. http://beagleboard.org/pru http://beagleboard.org/pru
  - bsder 10y ago
    I'm well aware of the on-board PRU's. They are very cool. They also are very specific to the TI processors and lock you into using the Sitara's forevermore. Not so good if I have a product with volume. In addition, the PRU's had absymal documentation when I last checked. Fortunately, that seems to be changing.

bsder 10y ago

Sure, if you need hard real-time control, a much simpler processor with a much simpler OS (or none at all) is going to do it better. Absolutely. Arduinos and Cortex-M's win here. However, I find that a VERY small amount of programmable logic on a cape often takes care of the hard-real time problem while the BeagleBone gives me a Linux backend to work against. Even if I find that the Linux side of things has too many hiccups to be reliable, the time saved in development because I can lean into a very powerful process with quick iterations before transferring to a leaner, more restricted processor is valuable. And, often, people find out that their hard real-time isn't as hard as they thought. Sure, if I have a safety system, I'm going to be religious about maximum latency. However, if I have a machine controller, overkilling processing power is often way cheaper (and faster to develop) even if I get the occasionally glitch that causes a fault which needs human intervention.

willglynn 10y ago
The BeagleBone's CPU has a normal ARM processor and a pair of PRUs. (This is much like how the Cell processor had a normal Power processor alongside some Cell SPUs.) PRUs can control GPIO pins running your dedicated, hard-realtime code without an OS, and they can do it while Linux runs on the same chip. http://beagleboard.org/pru http://beagleboard.org/pru
- bsder 10y ago
  I'm well aware of the on-board PRU's. They are very cool. They also are very specific to the TI processors and lock you into using the Sitara's forevermore. Not so good if I have a product with volume. In addition, the PRU's had absymal documentation when I last checked. Fortunately, that seems to be changing.