03-28-2018, 12:43 AM
(This post was last modified: 04-09-2018, 10:32 AM by Leapo.)
R64.GPIO aims to re-implement RPi.GPIO for the Rock64, with the goal of 100% code compatibility with the original Raspberry Pi module.
The following functions are currently implemented and working: - GPIO.setmode()
- GPIO.setwarnings()
- GPIO.setup()
- GPIO.output()
- GPIO.input()
- GPIO.cleanup()
- GPIO.PWM() (start, stop, ChangeFrequency, ChangeDutyCycle)
- GPIO.wait_for_edge()
Not yet implemented, but planned for the near future: - Interrupts (GPIO.event_detect)
The latest version of R64.GPIO can be found on my github, here: https://github.com/Leapo/Rock64-R64.GPIO
I'm currently updating the library very frequently, so make sure to grab the latest code!
Importing the R64.GPIO module: - Download the entire "R64" folder from the repo, then place the "R64" folder in the same directory as the Python script you're working on.
- Within your script, substitute the normal "import RPi.GPIO as GPIO" line for "import R64.GPIO as GPIO". Syntax for implemented functions should be identical to RPi.GPIO.
You may use GPIO.setmode() to select between ROCK, BOARD, and BCM numbering. - ROCK numbering is the default. I've created a reference spreadsheet of Rock64 pins, their functions, and their GPIO numbers, which you can find here: https://github.com/Leapo/Rock64-R64.GPIO...rence.xlsx
- BOARD numbering works exactly like it does in RPi.GPIO. Simply input a pin number, and the correct ROCK GPIO will be selected for you.
- BCM numbering attempts to emulate the physical layout of the Pi. This isn't perfect (some pins had to be mapped to the P5 header, can't use some pins with MicroSD, etc.), but I figured someone might find it useful.
Thanks for the update, I hope I get some time over the holidays to test some things....
Just updated the llibrary with software PWM support.
PWM currently defaults to high-precision mode. This mode achieves the highest possible PWM timing accuracy, and works the same on all platforms/kernels, but uses a lot of CPU time due to the use of a busy-wait.
Low-precision mode is much lighter, but accuracy is kernel-dependent. You'll have to test low-precision mode to see if it's adequate for your needs.
Low-precision mode can be enabled by passing "pwm_precision=GPIO.LOW" as an argument for start()
thank you @ Leapo , can't wait to test it out.... so excited
04-08-2018, 04:11 AM
(This post was last modified: 04-08-2018, 04:48 AM by i69fstop.)
Hi @ Leapo
I have this error..running
Code: root@rock64:/home/Rock64-R64.GPIO# sudo python R64-GPIO-test.py
Testing R64.GPIO Module...
Module Variables:
Name Value
---- -----
GPIO.ROCK ROCK
GPIO.BOARD BOARD
GPIO.BCM BCM
GPIO.OUT out
GPIO.IN in
GPIO.HIGH 1
GPIO.LOW 0
GPIO.PUD_UP 0
GPIO.PUD_DOWN 1
GPIO.VERSION 0.6.3
GPIO.RPI_INFO {'P1_REVISION': 3, 'RAM': '1024M', 'REVISION': 'a22082', 'TYPE': 'Pi 3 Model B', 'PROCESSOR': 'BCM2837', 'MANUFACTURER': 'Embest'}
Error: Unable to export GPIO
Error: Unable to set GPIO direction
Error: Unable to export GPIO
Error: Unable to set GPIO direction
Testing GPIO Input/Output:
You must setup() the GPIO channel first
Output State : None
You must setup() the GPIO channel as an output first
You must setup() the GPIO channel first
Input State : None
You must setup() the GPIO channel as an output first
Testing PWM Output - DutyCycle - High Precision:
60Hz at 50% duty cycle for 1 second
Traceback (most recent call last):
File "R64-GPIO-test.py", line 58, in <module>
p.start(50)
File "/home/Rock64-R64.GPIO/R64/_GPIO.py", line 333, in start
self.pwm_calc()
File "/home/Rock64-R64.GPIO/R64/_GPIO.py", line 350, in pwm_calc
self.sleep_low = (1.0 / self.freq) * ((100 - self.dutycycle) / 100.0)
AttributeError: PWM instance has no attribute 'freq'
root@rock64:/home/Rock64-R64.GPIO# uname -a
Linux rock64 4.4.114-rockchip-ayufan-193 #1 SMP Sun Mar 4 20:24:21 UTC 2018 aarch64 GNU/Linux
@ Leapo
I update to 4.4.120, it fixed the issue with IO error
Code: Linux rock64 4.4.120-rockchip-ayufan-209 #1 SMP Mon Apr 2 16:05:07 UTC 2018 aarch64 GNU/Linux
(04-08-2018, 04:11 AM)i69fstop Wrote: I update to 4.4.120, it fixed the issue with IO error
So it's all working now?
I've updated the readme on the GitHub repo to include the test platform (Ayufan 0.5.15, Debian Jessie, 32bit). I can't guarantee that this library will work on newer/older releases until tested.
(04-09-2018, 10:29 AM)Leapo Wrote: (04-08-2018, 04:11 AM)i69fstop Wrote: I update to 4.4.120, it fixed the issue with IO error
So it's all working now?
I've updated the readme on the GitHub repo to include the test platform (Ayufan 0.5.15, Debian Jessie, 32bit). I can't guarantee that this library will work on newer/older releases until tested.
Thanks and appreciate on your GitHub contribution :-)
Thanks a lot for the module.
It would be great if you add "GPIO.add_event_detect". I need this for a motion python script.
(04-09-2018, 10:29 AM)Leapo Wrote: (04-08-2018, 04:11 AM)i69fstop Wrote: I update to 4.4.120, it fixed the issue with IO error
So it's all working now?
I've updated the readme on the GitHub repo to include the test platform (Ayufan 0.5.15, Debian Jessie, 32bit). I can't guarantee that this library will work on newer/older releases until tested.
Hi @ Leapo,
Actually, it didn't work. There is no more error but when testing the the LED, it din't work.
I'd like to report my test on the interrupt of the GPIO, I wish this will be help for the development.
Hardware : Rock64 4GB (Rock64 V2 2017-0713)
Software : bionic-minimal-rock64-0.6.31-209-arm64 (kernel 4.4.120).
I tried interrupts with gpio-int-test.c on physical pin 16 (GPIO3_A5):
Code: root@rock64:~# ./gpio-int-test 101
poll() GPIO 101 interrupt occurred
..
poll() GPIO 101 interrupt occurred
It had responses, but I found the followings :
- once gpio-int-test started, pin 16 had already been pulled-up internally to 3.2 V.
- it was difficult for me to pull-down the pin. With a 20K resistor pull-down to ground, interrupt was triggered repeatedly. With a 10K resistor, pin voltage became 0.443V, and it became more stable. When I opened the 10K resistor, interrupt was triggered.
The problem is :
10K pull-down resistor is quite small, and even with the 10K resistor, the pin voltage is still 0.443V, not close 0V. There should be something wrong.
|