Skip to content

BBB GPIO speeds

Jump to bottom
Franz Miltz edited this page Aug 7, 2021 · 1 revision

BeagleBone Black's GPIO R/W Speeds

Protocols like I2C/SPI/CAN/UART ultimately work using digital pulses. However, there are hardware buffers which can handle a number of pulses before the CPU needs to step in to do anything. Working with GPIO requires CPU's attention for each change in the digital signal.

Following things are worth testing:

  1. How fast can BBB count pulses? (At what frequency does it start missing some of the pulses?)
  2. What is the shortest pulse that BBB can reliably register?
  3. How often can BBB reliably update a GPIO output?

For reading (1 & 2), interrupts can be used for significant improvement over polling. For outputs, PWM can be used to produce well-timed waveforms. Direct pin manipulation would achieve much less precise timing but could give better control over the number of pulses sent for example.

Counting speed

How fast can BBB count pulses? (At what frequency does it start missing some of the pulses?)

This is important for applications like counting wheel rotations.

Test specifications

Prerequisites

  • BBB with code to count pulses while simulating a realistic competition load
  • Arduino UNO with code to generate known number of pulses at various frequencies
  • 2 USB cables to connect to the BBB and Arduino
  • 1 GPIO jumper wire (male-male)

Variables

  • Dependent variable: Number of pulses counted by BBB
  • Independent variables:
    • Frequency of input pulses
    • BBB load - should be at least as high as during an actual run
  • Controlled variables:
    • Number of pulses created - the CPU may not always pay attention to GPIOs so the tests should be long enough for worst-case scenarios to occur (probably between several seconds and a minute)
    • Pulse width - probably keep constant, 50% duty cycle (signal high and low for equal amount of time)

Objectives

  • Primary: Determine maximum input frequency at which the number of pulses counted by BBB exactly equals the number of pulses created
  • Secondary: Gauge the impact of BBB CPU load on the counting performance

Test procedures

Generating pulses

  1. Flash the pulse generation code onto the Arduino
    1. Clone the experiments repo
    2. The PULSES folder is a PlatformIO project and contains the pulse generation code
    3. You can use the PlatformIO IDE extension for VS Code to open the project and compile and upload the code
  2. Send the "GO" command
    • If using PlatformIO Serial Monitor, only type "GO", do not hit enter
  3. The program will output the number of pulses that it will send as well as their frequency
  4. After all the pulses are sent, the program outputs how long it took to send them and the resulting average frequency. This is to check that it behaves as desired.
  5. [OPTIONAL] To change the frequency or duration of an experiment, modify the constants at the top of the file

Counting pulses

  1. Check out the sns-gpio_encoder_test branch in the hyped-2020 repo. The counter is implemented in run/demo_gpio_counter.cpp.
  2. You can modify the number of busy threads by chnging the kNumWorkers constant. This makes it harder for BBB to count but makes the test more realistic (the BBB will need to be doing a lot of other stuff).

(The interrupt-based counting uses the stripe counter implementation from previous years.)

Test execution

This is a step-by-step guide for executing the test.

  1. Make sure the Arduino has the appropriate sketch flashed to it (see Generating pulses above)
  2. Power on the BBB
  3. Make sure the BBB has the ./hyped executable compiled from correct MAIN (see Counting pulses above)
  4. Connect pin 67 (or whatever kPin is) on the BBB to pin 3 (or whatever PIN is) on the Arduino.
  5. Power on the Arduino (and wait a few seconds for stuff to stop blinking)
  6. Start the ./hyped executable and follow the instructions it gives you.
  7. Trigger the sending of pulses from Arduino (see Generating pulses above)
  8. Check whether the BBB counted all pulses. If so, increase the frequency on the Arduino and repeat steps 5-8
  9. Record the highest frequency that worked and the one that did not

Results

Only few preliminary tests have been carried out. We should add more in the future.

  • Polling counter, 1 busy thread, 100Hz for 10s: 2 runs, counted 804 and 797 out of 1000 pulses
  • Polling counter, 2 busy threads, 100Hz for 10s: 1 run, counted 565 out of 1000 pulses
  • Interrupt counter, 2 busy threads, 100Hz for 10s: 3 runs, counted 998, 1000 and 1000 out of 1000 pulses
  • Interrupt counter, 2 busy threads, 200Hz for 15s: 1 run, counted 3000 out of 3000 pulses
  • Interrupt counter, 2 busy threads, 200Hz for 15s, intermediate count printed twice: 1 run, counted 2992 out of 3000 pulses

For reference, this version of the code uses SimpleCounter class which is the polling counter above. This version was used to test the interrupt counter implementation.

Pulse width

What is the shortest pulse that BBB can reliably register?

This is especially relevant for stripe counter where the pulses come at a low frequency but they can be extremely short.

This test will be essentially the same as the previous one with the only difference being that we would decrease the duty cycle instead of increasing frequency. The frequency should probably be the highest safe one identified above or a bit lower.

It is unlikely that short pulses will be a problem (if BBB uses interrupts) so we might need to make the Arduino work really hard to make it interesting. The calls to digitalWrite(pin, value) are a bit slow but there is a faster tho less safe method.

Output frequency

How often can BBB reliably update a GPIO output?

I don't think we have a direct use for this yet. However, it can help us understand how often a thread gets to run and for how long can it be waiting. (I think the idle time was up to several ms when we tested it with Martin two years ago.)

HYPED Logo

Clone this wiki locally