Python GPIO Library for the Rock64 (R64.GPIO)

[martinayotte]

Internal SoC PullUps are usually between 20K to 100K.

So, using a external PullDown to put it low is like creating a voltage divider with the internal pullup, therefore with a external 20K, you get a voltage that is neither a LOW or a HIGH, explaining why you get interrupts triggered repeatedly.

If you use a external 1K as a pulldown instead, you will see that will be close to 0V ...

[edupv]

Internal SoC PullUps are usually between 20K to 100K.

So, using a external PullDown to put it low is like creating a voltage divider with the internal pullup, therefore with a external 20K, you get a voltage that is neither a LOW or a HIGH, explaining why you get interrupts triggered repeatedly.

If you use a external 1K as a pulldown instead, you will see that will be close to 0V ...

Thanks for your reply.

By calculation, the internal pull-up resistor is around 60K, it is normal.

As I expected the pin was pull-down internally and I had prepared a switch with 5K resistor to pull it up, so when I found the pin was pull-up, I was a little confused - I wanted to pull it down and use the switch to pull it up to trigger the interrupt.

[Leapo]

It would be great if you add "GPIO.add_event_detect". I need this for a motion python script.

Working on it, I'll have it implemented soon

Actually, it didn't work. There is no more error but when testing the the LED, it din't work.

Hmm, make sure you have the correct GPIO/pin selected. Pin assignments for each mode are documented here: https://github.com/Leapo/Rock64-R64.GPIO...GPIO-Modes

I usually use ROCK 100 (BOARD 15), ROCK 101 (BOARD 16), and ROCK 102 (BOARD 18) for testing.

Also make sure you've downloaded the latest version from the repo!

[tllim]

It would be great if you add "GPIO.add_event_detect". I need this for a motion python script.

Working on it, I'll have it implemented soon

Actually, it didn't work. There is no more error but when testing the the LED, it din't work.

Hmm, make sure you have the correct GPIO/pin selected. Pin assignments for each mode are documented here: https://github.com/Leapo/Rock64-R64.GPIO...GPIO-Modes

I usually use ROCK 100 (BOARD 15), ROCK 101 (BOARD 16), and ROCK 102 (BOARD 18) for testing.

Also make sure you've downloaded the latest version from the repo!

Thanks, I have added your Github link at PINE64 wiki page: http://wiki.pine64.org/index.php/ROCK64_...ifications

[edupv]

I found a "generic" python gpio package here : Pure Python native GPIO access. Edge-triggered interrupts included.

I wrote a python motion detecting script for my OrangePi-PC2 in the past few days. Today, I make it working in my Rock64 by changing only the port number, just one line of code. It is very very convenient.

[Leapo]

Looking over their code... might be useful, but their interrupt implementation is pretty thin compared to RPi.GPIO

Current progress: One interrupt feature is in. The background threading required to implement the others is slowing me down a bit, but I'm still working on it.

[AnythingIsFine]

Looking over their code... might be useful, but their interrupt implementation is pretty thin compared to RPi.GPIO

Current progress: One interrupt feature is in. The background threading required to implement the others is slowing me down a bit, but I'm still working on it.

Hi Leapo,

First off, thanks for taking the time to port RPi.GPIO lib to Rock64 !

I have a Rock64, running Armbian 5.42 Ubuntu Xenial minimal (4.4.124-rk3328) and trying to use the R64 GPIO lib .

I read your note, stating testing was done on using Ayufan's release 0.5.15 and other distros/versions are not guaranteed to work, yet I want to inquire of a certain error I am receiving.

I used the "prefered" way of getting the lib, downloading the R64 directory and running the script in the same path as it.
The module seems to be imported, yet I get some errors when exporting the the GPIO pin, like below:


root@rock64:/home/pi/projects# cat gpio_test.py
import R64.GPIO as GPIO

pin = 16
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pin, GPIO.OUT, initial=GPIO.HIGH)
#GPIO.setwarnings(False)

root@rock64:/home/pi/projects# python gpio_test.py
Error: Unable to export GPIO
Error: Unable to set GPIO direction
root@rock64:/home/pi/project


I want to add , I tried the script as 'root', as at first I believed it could not write tot he '/sys/class/gpio/export' file. I tried mode BCM (pin=23), ROCK(pin=101), BOARD(pin=16), always getting the same error.

If I try to set pin 16 to "out" via bash, it works, but only If I add an offset of 1000, i.e 101 becomes 1101. Could this be the reason why the R64.GPIO lib fails, where should I go about to add this offset in the lib if possible ?

Thanks!

[pfeerick]

If I try to set pin 16 to "out" via bash, it works, but only If I add an offset of 1000, i.e 101 becomes 1101. Could this be the reason why the R64.GPIO lib fails, where should I go about to add this offset in the lib if possible ?

I *still* haven't gotten around to trying this library out, but I suspect you are right... I seem to remember some reference to the gpio ids changing on one of the kernel updates...

Maybe look at these lines??

https://github.com/Leapo/Rock64-R64.GPIO...py#L30-L32

[AnythingIsFine]

@pfeerick:

I edited Leapo's Github repo and edited the library so it considers the offset and now it works, at least on Armbian 5.42 for Rock64.

Here's the edited R64.GPIO python library, if anyone has the time and will, please try it out.


I added function ("offset") which checks the kernel version on the local machine and if it finds that the version is over 4.4.103, it adds the "1000" offset to the pin channel values.

The kernel version 4.4.103 was not randomly chosen as start point for implementing the offset, but rather from a comment I read by user "dontpostalot" in this thread

I have yet to validate if that actual kernel version starts implementing the offset.

[pfeerick]

@pfeerick:

I edited Leapo's Github repo and edited the library so it considers the offset and now it works, at least on Armbian 5.42 for Rock64.

Here's the edited R64.GPIO python library, if anyone has the time and will, please try it out.


I added function ("offset") which checks the kernel version on the local machine and if it finds that the version is over 4.4.103, it adds the "1000" offset to the pin channel values.

The kernel version 4.4.103 was not randomly chosen as start point for implementing the offset, but rather from a comment I read by user "dontpostalot" in this thread

I have yet to validate if that actual kernel version starts implementing the offset.

Nice solution! I'll try to give this a run sometime this week.