3 ms·

Hilarious, GHz+ processors and they can toggle a GPIO pin at 2.8MHz with millisecond jitter (so, not really 2.8MHz). This is what it has come to. Honestly, th

Hilarious, GHz+ processors and they can toggle a GPIO pin at 2.8MHz with millisecond jitter (so, not really 2.8MHz). This is what it has come to. Honestly, the BeagleBone (or the TI AMx series) has got it right: modern processors with their layers upon layers of caching and modern operating systems are utterly useless for this task. The deterministic 200MHz PRU-ICSS processors however are perfectly suited to do it. Don't bother fighting the OS and 30 years of CPU evolution when a PRU can toggle at 5ns intervals.

bsder 10y ago
> Hilarious, GHz+ processors and they can toggle a GPIO pin at 2.8MHz with millisecond jitter (so, not really 2.8MHz). Um, allow me to flip your statement around "GHz+ processors so CHEAP that you can use them to toggle a GPIO pin." However, that's not generally how I use a BeagleBone. The BeagleBone provides the user interface (USB, Ethernet, etc.) while a cheap cape provides the hardware specific part. BeagleBone's have absolutely proliferated around me once the started being able to run mainline Debian instead of weird things like Angstrom. That having been said--I have bit-banged the bone. The annoyance isn't the speed so much but you have to be in Supervisor mode to change the direction of the pin. That's really annoying and is a limitation of the TI Sitara SoC. The RaspberryPi does not seem to have that limitation. So, if you're gonna bit-bang, an RPi is probably a better choice. As for why it's so slow, there are two parts. 1) mmap() marks the writes as strongly-ordered and slows things down You can actually get to 12.5MHz. https://groups.google.com/forum/#!category-topic/beagleboard/xuHRlDL19NI https://groups.google.com/forum/#!category-topic/beagleboard... 2) The system seems to have internal packetized transfer buses that gate the speed The bus frequency determines the ultimate speed. This is no different from the much smaller microcontrollers, except that the smaller microcontrollers tend to run their bus frequencies at the same speed as the internal frequency since they are running much slower.
- revelation 10y ago
  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

> Hilarious, GHz+ processors and they can toggle a GPIO pin at 2.8MHz with millisecond jitter (so, not really 2.8MHz). Um, allow me to flip your statement around "GHz+ processors so CHEAP that you can use them to toggle a GPIO pin." However, that's not generally how I use a BeagleBone. The BeagleBone provides the user interface (USB, Ethernet, etc.) while a cheap cape provides the hardware specific part. BeagleBone's have absolutely proliferated around me once the started being able to run mainline Debian instead of weird things like Angstrom. That having been said--I have bit-banged the bone. The annoyance isn't the speed so much but you have to be in Supervisor mode to change the direction of the pin. That's really annoying and is a limitation of the TI Sitara SoC. The RaspberryPi does not seem to have that limitation. So, if you're gonna bit-bang, an RPi is probably a better choice. As for why it's so slow, there are two parts. 1) mmap() marks the writes as strongly-ordered and slows things down You can actually get to 12.5MHz. https://groups.google.com/forum/#!category-topic/beagleboard/xuHRlDL19NI https://groups.google.com/forum/#!category-topic/beagleboard... 2) The system seems to have internal packetized transfer buses that gate the speed The bus frequency determines the ultimate speed. This is no different from the much smaller microcontrollers, except that the smaller microcontrollers tend to run their bus frequencies at the same speed as the internal frequency since they are running much slower.

revelation 10y ago
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.