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 No Audio @ Debian 12 dmitrymyadzelets 1 112 03-18-2024, 06:56 AM
Last Post: diederik
  Rock64 bricked shawwwn 7 5,448 03-17-2024, 12:22 PM
Last Post: dmitrymyadzelets
  Rock64 won't boot luminosity7 10 3,863 03-16-2024, 08:33 AM
Last Post: dmitrymyadzelets
  Rock64 doesn't boot dstallmo 1 253 03-16-2024, 08:29 AM
Last Post: dmitrymyadzelets
  How well does Rock64 deal with HDR and Atmos on Kodi? drvlikhell 3 1,769 04-29-2023, 04:24 AM
Last Post: newestssd
  OpenWRT on the Rock64 CanadianBacon 12 7,790 04-24-2023, 12:40 PM
Last Post: arunkhan
  Rock64 board not working, no HDMI no Ethernet. EDited 3 3,393 01-17-2023, 02:31 PM
Last Post: Flagtrax
  ROCK64 v3 can it boot from USB? Tsagualsa 4 1,972 11-29-2022, 11:31 AM
Last Post: Macgyver
  rock64 v3 spiflash Macgyver 0 703 11-28-2022, 02:18 PM
Last Post: Macgyver
  my rock64 dosen't work rookie_267 0 904 10-07-2022, 07:50 PM
Last Post: rookie_267

Forum Jump:


Users browsing this thread: 2 Guest(s)