Python GPIO Library for the Rock64 (R64.GPIO)
#11
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 ...
  Reply
#12
(04-12-2018, 08:08 AM)martinayotte Wrote: 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.
  Reply
#13
(04-10-2018, 02:08 PM)mark79 Wrote: 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 Cool

(04-11-2018, 04:20 PM)i69fstop Wrote: 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!
  Reply
#14
(04-17-2018, 10:03 AM)Leapo Wrote:
(04-10-2018, 02:08 PM)mark79 Wrote: 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 Cool

(04-11-2018, 04:20 PM)i69fstop Wrote: 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
  Reply
#15
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.
  Reply
#16
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.
  Reply
#17
(04-27-2018, 03:04 PM)Leapo Wrote: 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!
  Reply
#18
(05-11-2018, 02:56 AM)AnythingIsFine Wrote: 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
  Reply
#19
@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.
  Reply
#20
(05-14-2018, 09:53 AM)AnythingIsFine Wrote: @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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Rock64 bricked shawwwn 0 25 Yesterday, 11:15 PM
Last Post: shawwwn
  Are you guys still using Ayufan's OMV on your Rock64? AkiraSensei 0 64 11-26-2021, 07:01 PM
Last Post: AkiraSensei
  Rock64 kernel panics clay 15 991 10-17-2021, 06:30 PM
Last Post: Rocklobster
  Pine Rock64 eMMC lifespan moonspell79 3 748 08-19-2021, 06:46 PM
Last Post: bcnaz
  Rock64 No Audio - Solved wbecks 12 18,682 08-13-2021, 01:23 PM
Last Post: blakeadam
  Trustzone support for Rock64 capablegh 1 546 07-17-2021, 10:15 AM
Last Post: capablegh
  rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? klausfelix 0 451 07-02-2021, 03:13 PM
Last Post: klausfelix
Information Serial Console for the Rock64 MarkHaysHarris777 33 36,709 06-24-2021, 12:24 PM
Last Post: mikeklien
  lost eletronic component rock64 marvin1986 1 771 06-01-2021, 06:27 PM
Last Post: 8bit
Shocked Rock64 - Reboots after few minutes addezai 2 1,103 04-22-2021, 07:03 PM
Last Post: addezai

Forum Jump:


Users browsing this thread: 1 Guest(s)