[SOLVED] BrickPi 3 Questions




I am writing an article for Linux Magazine about the BrickPi 3 and have two quick questions:

a) Is the connection logic the same for the BrickPi and the BP3, i.e. does it also use the serial connectors to
communicate and thus are the other GPIO pins available on the top of the BP3? I would like to create
a driving thermometer :slight_smile:

b) I have been playing with the python API. Is the only way to wait for sensor changes to do a busy wait loop and query the value again and again?

Kind Regards,



Hi Konstantin, welcome to the forums.

The BrickPi3 is of a completely new design. The BP3 hardware, firmware, drivers, and examples are all new. Due to the significant changes (improvements) of the BP3, none of the software (drivers, examples, etc.) are backwards/forwards compatible between the older BP and the BP3. The original BrickPi used UART serial for communication (RPi GPIO pins 8 and 10), and the BrickPi3 uses SPI serial for communication (RPi GPIO pins 19, 21, 23, and 26).

The original BrickPi firmware/drivers were designed to update all values in a single transaction package. The drivers would send updated values to the BP (such as motor power levels), and the BP would send updated values back to the RPi (such as sensor values and current motor encoder values). Since UART communication was comparatively slow, especially with the processing overhead, this was a relatively efficient method of updating many sensor/motor values quickly. Since it requires “BrickPiUpdateValues” to be called for each update, it’s a little extra complicated to code, and if you are only waiting on a single sensor, each update would take longer than otherwise necessary (since it’s updating all the sensor and motor values).

In contrast, the BP3 firmware/drivers communicate each time you call a method to read a sensor value or set a motor value. The significantly reduced overhead of SPI (compared to UART), allows “real-time” communication, where only the value you need to set/get is being transferred. Internally, the BP3 FW continuously polls the sensors, and when the RPi reads a sensor value, the BP3 FW immediately replies with the latest value. Each complete transaction takes approximately 0.5ms (some are shorter and some are longer), so you can update/poll values at around 2000 per second.

With the BP3, since the RPi acts as the SPI bus master, the slave (BP3) is not able to “force” a message to the RPi. Without the RPi polling the BP3, there is no way for the RPi to be “notified” of a specific sensor value or change. If, for example, you need the program to wait until a touch sensor is pressed, you would use a loop such as this:

# loop until the touch sensor on sensor port 1 is pressed
while not BP.get_sensor(BP.PORT_1):
    time.sleep(0.01) # pause for 10ms to save CPU cycles.

Note, in the firmware, the touch sensor is updated at a rate of 250 Hz (4ms).

There is no behind-the-scenes polling (or other communication) taking place between the RPi and the BP3. The only time data is being transferred is when you call a method from the brickpi3 python module.

See the BP3 schematics here for a list of which RPI GPIO pins are being used by the BP3.



Hi Matt,

thanks for the detailed article I will incorporate this into the article. Expect orders from Germany :slight_smile:

Best Regards,



I have already written a review about the BrickPi3 in our German Mindstorms Forum, in German :slight_smile:


Well I am writing for print media :slight_smile:


This topic was automatically closed after 4 days. New replies are no longer allowed.