PINE64

Full Version: GPIO performance 100x slower compared to Raspberry Pi 3
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
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!
(03-22-2019, 04:14 PM)dkryder Wrote: [ -> ]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
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.
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.
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.
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!