What is Android Things Raspberry Pi GPIO max frequency?

Question

Where can be found the characteristics of the switching speed of GPIO port for the Raspberry Pi 3 under Android Things like that?

Bruin

Sorry for being late to this but it was only just brought to my attention. I did the tests quoted in the first answer. I could only get 3KHz or so and I thought this was so slow I contacted the dev team and asked why and could they make it go faster. The reason its slow is that they use SYSFS which is secure but very very slow. I asked about implementing memory mapping and they said no way because it would be insecure. They basically don't get it and at that point I decided that it wasn't going to be a useful platform. Sysfs can be made to run at 100KHz if you do it right (see chapter 3 of my – Unmask

Answer 1

In DP2 there is two ways to control GPIO:

1) with SDK using java (analyzed by Harry Fairhead here);

2) with NDK using C/C++ (analyzed by Harry Fairhead here).

With SDK using java the fastest pulses seen are around 0.23ms and there are lots of large (up to 8ms) interruptions (!!!) in the pulse train. And with NDK using C/C++ the pulse width is reduced from 0.23ms to just around 0.15ms.

Conclusion: Android Things DP2 Raspberry Pi GPIO max frequency is about 3 kHz, that is not fast enough to write drivers that interface to most not supported "from the box" protocols.

Bruin

I'll get to see if it's possible to port wiringPi to NDK, I think they use memory mapping instead of sysfs which is what seems to be on the official NDK API. I've faced some compiling errors but I think they can be circumvented. – Salvatore

@Salvatore It will be good, because many custom protocols waiting to be implemented on Android devices ) – Bruin

Answer 2

Here goes the results with C: it's near 100kHz.

Since I don't have a scope or proper equipment for these measures, here's what I did:

A java method that measures time, and invokes a C method that is efficient for a big number of cycles. This was for simplicity only, and I believe it's enough to show that for high number of cycles the speed asymptotically reaches almost 100kHz:

1 Iterations done in 501.38547 ms = 0.0019944734 kHz
10000 Iterations done in 599.4385 ms = 16.68228 kHz
100000 Iterations done in 1496.2832 ms = 66.83227 kHz
1000000 Iterations done in 10275.258 ms = 97.32116 kHz
2000000 Iterations done in 20104.879 ms = 99.47834 kHz

Among other things that the C code must do is sit waiting for 500ms until the pin is configured properly.

All code used for this measurement is available at https://github.com/fmatosqg/androidthings_ndk/tree/SO_speed_measurement, and I believe there still may be room for speed improvement. Though it uses a hack to write from C code, instructions available in the README.md.

Salvatore

Answer 3

I got this java code to run in 0.633 seconds, equivalent to roughly 1500 Hz.

for (int i = 0 ; i < 1000 ; i++) {
     buzzer.setValue(true);
     buzzer.setValue(false);
}

There seems to be some optimization though because if you run it multiple times it occasionally goes faster.

I'm very curious to see the results using C/C++ though.

Salvatore

Is setValue() synchronous (I mean setValue() ended only if output voltage on GPIO pin set to given value)? And did You know any examples to access GPIO on Android Things using C/C++? – Bruin

no idea on what setValue does, but my educated guess is that it need to call native methods at some point, which are expected to be reeeally slow. I still didn't look for C/C++ examples or references, there may be something from Brillo still around that may apply, or maybe the drivers can offer a more efficient solution. In any case, these are things I'd be willing to try soon. – Salvatore

@AndriyOmelchenko got some progress on doing it on C (#41895467). With very inneficient code I'm getting at least 5kHz and that's by measuring time from Java side of things. – Salvatore

Good job! I try to investigate it. – Bruin

Answer 4

We have run a relevant benchmark test for both Rpi.GPIO and PIGPIO python libraries.

We concluded that both libraries perform well for frequencies of up to 5 KHz with and accuracy above 99%. The accuracy of the Rpi.GPIO library deteriorates over 5 KHz and at 50 KHz it is incapable of performing this task.

The PIGPIO library performs comparably better, with its accuracy being above 99% for frequencies up to 20 KHz. Above that frequency, its performance gradually deteriorates and at 110 KHz it cannot read correctly any phrase at all.

You can read the more about the test, including all required information so as to replicate it, at our blog

Heroine

NB! From the link in answer: "For this test we used a Raspberry Pi 3B running Raspberry Pi OS Lite (Kernel version: 5.4)." - this is not Android Things and not its GPIO. – Bruin

Apologies. Should have read the question more carefully! Might be a good idea for a next benchmark test! – Heroine

Everything is ok, you work is good and interesting. Thanks. – Bruin