GPIO performance 100x slower compared to Raspberry Pi 3

[axelf]

Has anybody else observed this issue?

I am trying to get the Blinkit LED SPI Device to work with the RockPro64.
https://cpldcpu.wordpress.com/2014/11/30...-superled/ 
https://shop.pimoroni.com/products/blinkt


I have noticed that the Python GPIO library's  under Raspberry Pi 3 seem to run 100 times faster than can be achieved under RockPro64.

While a clock pulse under RockPro64 takes 600us a clock pulse under Raspberry Pi takes 8-8us.
This is using the same blinkit example code on both devices.

Does anybody know if Raspberry Pi 3 uses a better performing solution than the /sys/class/gpio interface for programming the GPIO than  the rockpro64 ? The rockPro64 is just too slow!

The only reason I think I can not get the blinkit LED to work on the RockPro64 it because its 100 ties slower than the Raspberry Pi 3 GPIO

You can see the oscilloscope scans below


https://imgur.com/FsgX2Io  RockPro64
https://imgur.com/dRBZcjK  Raspberry Pi 3


https://imgur.com/tagotFq  RockPro64
https://imgur.com/pywieqS Raspberry Pi 3

[dkryder]

you might want to take a look at this
https://github.com/fadedreamz/R64.GPIO
which is a gpio library for the rock64. i have not read if this works on a pro or if someone has ported to the pro. but, anyway, are you using the rpi.gpio library on the pro? if so, i doubt that will work or work well. i guess you could try it by changing this
import RPi.GPIO as GPIO
to this
import ROCK.GPIO as GPIO

be sure to put R64.GPIO in the proper folder
let us know how it works out.
otherwise maybe contact blinkt and tell them you want to run their stuff on a pro and ask for their help. good luck!

[axelf]

you might want to take a look at this
https://github.com/fadedreamz/R64.GPIO
which is a gpio library for the rock64. i have not read if this works on a pro or if someone has ported to the pro. but, anyway, are you using the rpi.gpio library on the pro? if so, i doubt that will work or work well.  i guess you could try it by changing this
import RPi.GPIO as GPIO
to this
import ROCK.GPIO as GPIO

be sure to put R64.GPIO in the proper folder
let us know how it works out.
otherwise maybe contact blinkt and tell them you want to run their stuff on a pro and ask for their help. good luck!

Thanks I checked out the code and its still using the /sys/class/gpio interface

 def set_value(self, channel, value):
        base_syspath = "/sys/class/gpio"
        base_gpio_value = "{}/gpio{}/value".format(base_syspath, channel)

so this is not going to perform any better than

https://github.com/Angoosh/RockPro64-RP64.GPIO

I am looking through the Raspberry PI 3 code to see how they do it and Ill see if I can rework the code

[dkryder]

ok then you were using rockpro gpio. when you said this,
"This is using the same blinkit example code on both devices."
i was not sure what you meant.

[axelf]

Right done a little more investigation

Ran a logic analyzer on the Raspberry Pi and the RockPro64  ... and they both test back good ... the only difference is the speed.

https://imgur.com/wBBCYEA  

Blinkt Initialization on the RockPro64 GPIO using SPI DAT = Pin 16\BCM23  CLK = Pin 18\BCM24

Looking into the source code of the Raspberry PI 3  their implementation of RPi.GPIO does not use the /sys/call/gpio interface.
The python GPIO library is a wrapper of a c library _GPIO.cpython-36m-aarch64-linux-gnu.so.

This library  writes directly to the GPIO device in the SOC

/dev/gpiomem
/dev/mem

The process appears to consist of writing to some memory address space (semaphores/registers) to control the GPIO.
This is obviously a lot quicker and deterministic than trying to write to a file in Python.

Python R64.GPIO takes 530us  to toggle a Clock cycle  /sys/class/gpio equates to SPI Clock of 1.8 KHz
Python RPI.GPIO takes  4us to to toggle a Clock cycle /dev/gpiomem equates to a SPI Clock of 0.25MHz

People have tested the Blinkt up to 4MHz and 10MHz ...  but there is not reports of a minimum clock speed!

Clearly the RockPro64 GPIO performance via Python R64\RP64.GPIO is just too slow to get teh SPI interface working.

I will have to see if the RK3399 has a faster way to program the GPIO

I will post my progress.

[dkryder]

ya know, those shared object files can be decompiled. so if you are interested in a bit of reverse engineering you might could get a much closer look at whats going on inside the .so if you could crack that egg and get the pro doing excellent GPIO you might be able to get tllim (owner of pine) to supply a few test boards to you and maybe hook you up with some rockchip engineers/devs, if you get to a proof of concept. tllim has been generous over the years to devs who produce, and even to some who ended up not producing. be nice to someday see a thread titled " rockpro64 GPIO 25x faster than rpi" in theory i suppose it is possible just needs someone with skills and the time.

[axelf]

Thankfully the raspberry Pi RPi.GPIO is open source so I have access to the source code.

I have just tried to rewrite the R64/RP64.GPIO python wrapper using a C library i wrote that replaces python writes to /sys/class/gpio with c writes.

The best I could get was 190us SPI Clock of 5.26KHz  

it is more than twice as fast but nowhere near the raspberry pi performance.

I will do some digging and see if there is a faster solution and avoid /sys/class/gpio completely.

I believe that the raspberry pi uses the linux kernel gpio.h library which I hope has been implemented on the RockPro.

watch this space!

[Gienek]

Hello,
  I have written a small library to operate GPIO of ROCKPro64 in C. 
I was able to generate a square wave with period of around 2.2 microseconds. This means around 0.45 MHz. All measurements done with ROCKPro itself - I have no oscilloscope at hand.
If you are implementing SPI by software controlling of GPIO pins, this may be the way to go. But, if I understand the drawing correctly, there is a hardware SPI available on pins 19, 21, 23, 24.
  I have to admit, that my result is probably still away from hardware capabilities. I am doing everything in user space, preserving state of other pins and protecting against collisions by using a mutex at each change of pin state. This is necessary, because I would like to operate more pins simultaneously in future. 
  Best regards,
  Gienek.

[antonlyap]

Hello @Gienek, would you mind sharing the code of your library? I would be really great as I (and probably some other people) are not very familiar with such low-level stuff and it's hard to do all the research myself. Thanks in advance!

[Gienek]

Hello,
  With pleasure. I have uploaded it once in this post:
https://forum.pine64.org/showthread.php?...7#pid49547
I am attaching again here for convenience (file GPIOsrc.tar). I have been busy with other tasks, so have not developed it further. It is still in experimental phase and documentation is still very ‘sparse’...


  GPIOsrc.tar (Size: 180 KB / Downloads: 491)

  I have to admit, that I tested the standard fs-interface again on another board, with the Allwinner A20 processor. This time I have operated the interface files directly from C-code. It means, I opened the interface files, like e.g. /sys/class/gpio/gpio86/value, and then written or read using the file descriptor. The resulting speed of operations was much, much higher than in tests performed with Shell commands. So maybe scripts (Shell or Python) are so slow in interaction with the files, and not the interface itself. The only peculiarity in C is during reading: It is necessary to seek to the beginning each time before reading new value. But it is still very fast.
So maybe it is not worthy to operate directly on registers. I will compare it on the A20 board, once I have some time. The standard interface has important advantages: It takes care of race conditions and allows using interrupts (async reading with select()).
  And there is also the 'new standard' - The character-device interface (libgpiod). But I have not tried it, so far.

  Best regards,
  Gienek.