Low data throughput with HAT Brick and Accelerometer V2c

[cl-]

First of all, I love the HAT Brick! Thanks!

 

I have a general question related to its performance:

 

Do you know whether there are technical limits on how much data I can get through the GPIO of the Raspberry Pi? I'm using the new Version 4 Raspberry Pi (2 GB RAM) and the HAT Brick. I tried to get the full rate of 25.6kHz out of an Accelerometer V2 bricklet, but it wasn't possible. It seems strange to me, as the Master Brick has no problems at all (at least when connecting only one Accelerometer V2 with continuous acceleration callback). I know about the technical limits for more than one Accelerometer V2 bricklet.

 

When compared to the Master Brick, however, the data throughput with the HAT brick seems to be much lower. I was expecting it to be the other way around (as there isn't a USB connection anymore that limits the number of messages per second). Is there a technical reason why the HAT Brick doesn't get the (at least equal) amount of data through the system that is needed for the Accelerometer V2 bricklets? How does Debian (or Brick Daemon on the Pi) read the GPIO? I'm guessing it iterates over the SPI pins one by one?

 

For comparison: I connected a Master Brick to the Raspberry Pi and it gave me the expected "Master Brick" like performance I was used to in the past.

 

Thanks for your support!

 

EDIT 1: I'm using your Rust API bindings.

 

EDIT 2: Does it have to do with the maximal SPI clock of 1400000?

 

// On RPi 3 make sure to set "core_freq=250" in /boot/config.txt.
// The SPI clock is scaled with the variable core_freq otherwise
// and the SPI clock is not stable...
#define BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ   1400000

[borg]

It should be possible to transfer about the same amount of data through the HATs (maybe a little bit less) as with a Master Brick.

 

From the perspective of the Linux kernel there is a lot of context switching going on (between kernel and user land as well as between IO and CRC calculation etc). There is unfortunately some time lost compared to the Master Brick, since the Master Brick does not do anything else in-between.

 

Also, the processor of the RPi3 does not support SPI CPHA (which we need) on spidev1.x. Because of that we have to manage 8 chip selects with one hardware SPI unit. The SPI unit does not have 8 hardware chip selects, so we have to do them from the user land via GPIO. This also costs additional time.

 

That being said: I did all my tests with the RPi3. During the development of the HAT the RPi4 was not yet released.

 

I will do some measurements with the RPi4 to see where the time is lost and if there maybe is a kernel configuration somewhere that we can do to increase the throughput. I think i will be able to do this on Wednesday, give me a few days for this. I will post the results in this thread.

[borg]

I did some real fast preliminary tests: The SPI clock on the RPi4 seems to be derived from the main cpu clock (on the RPi3 it is derived from the VPU, which is even crazier...).

 

This means that if the CPU governor scales down the CPU, it also scales down the SPI speed.

 

One solution is to put the governor in performance mode:

 

sudo apt-get install cpufrequtils

sudo cpufreq-set -g performance

 

Another, very unintuitive, solution is to have something running on the RPi that uses a lot of CPU. Just running a while(true)-loop on 2 cores does the trick in my tests, i then get the full speed too...  .

 

I have written on my TODO-list to install the newest version of Raspian on a RPi2, RPi3 and RPi4 and compare the exact performance and document the steps necessary to configure the PIs for the best performance. I will add this to the HAT and HAT Zero documentation.

[borg]

I tried the newest Raspbian Image with RPI 2/3/4 and the behavior is now the same with all three versions*: The SPI speed scales with the CPU frequency, which is depended on the Linux governor.

 

I added a section to the documentation: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Brick.html#configuration-for-improved-throughput

 

With the RPi 3 and 4 i get the full 1000 messages per second after the changes.

[cl-]

Brilliant! Thanks a lot for the quick response and solution!

I tried the changes and the performance increased immediately.