NO support for this board ROCK 4 C+ and no GPIO working help

#1

This as far as I have been able to get it… Now it is an argument in periphery python it trips over. Still I think there is a long way from getting things running as smoothly as in raspian

from periphery import GPIO
gpio_in = GPIO("/dev/gpiochip0", 158, “out”)
Traceback (most recent call last):
File “/usr/local/lib/python3.9/dist-packages/periphery/gpio_cdev2.py”, lin
e 286, in _reopen
fcntl.ioctl(self._chip_fd, Cdev2GPIO._GPIO_V2_GET_LINE_IOCTL, line_reque
st)
OSError: [Errno 22] Invalid argument

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “”, line 1, in
File “/usr/local/lib/python3.9/dist-packages/periphery/gpio_cdev2.py”, lin
e 173, in init
self._open(path, line, direction, edge, bias, drive, inverted, label)
File “/usr/local/lib/python3.9/dist-packages/periphery/gpio_cdev2.py”, lin
e 224, in _open
self._reopen(direction, edge, bias, drive, inverted)
File “/usr/local/lib/python3.9/dist-packages/periphery/gpio_cdev2.py”, lin
e 288, in _reopen
raise GPIOError(e.errno, "Opening output line handle: " + e.strerror)
periphery.gpio.GPIOError: [Errno 22] Opening output line handle: Invalid arg
ument

I cant get the GPIO pins to work in my python script

from periphery import GPIO

Open GPIO /dev/gpiochip0 line 10 with input direction

gpio_in = GPIO("~/dev/gpiochip0", 38, “in”)

Open GPIO /dev/gpiochip0 line 12 with output direction

gpio_out = GPIO("~/dev/gpiochip0", 40, “out”)

value = gpio_in.read()
gpio_out.write(not value)

gpio_in.close()
gpio_out.close()

Does anyone got this board working or should I just dump it??

#2

Not sure if I can help, but you seems to misunderstood some things. Lets start with you second code snipped:

gpio_in = GPIO("~/dev/gpiochip0", 38, "in")

The tilde in front of /dev/ is probably wrong, but the main problem is, that “gpiochio0” probably does not have 38 lines. At least on my 4C+ I got

rock-4cplus (~) $ sudo gpioinfo |more
gpiochip0 - 32 lines:
	line   0:      unnamed       unused   input  active-high 
	line   1:      unnamed       unused   input  active-high 
    ...

So neither 38 nor 40 exists, causing a Invalid argument exception. Which returns to your first snippet: 158 is probably also wrong for a 4C+. May I ask which GPIO you try to trigger?
If these numbers come from a Raspberry documentation: It does not work because a 4C+ has a different SOC…

#3

See this: https://wiki.radxa.com/Rock4/hardware/gpio

The interesting part is this:

Rockchip RK3399 GPIO has 5 banks, GPIO0 to GPIO4, each bank has 32pins, naming as below:

   GPIO0_A0 ~ A7 
   GPIO0_B0 ~ B7
   GPIO0_C0 ~ C7
   GPIO0_D0 ~ D7
   
   GPIO1_A0 ~ A7
   ....
   GPIO1_D0 ~ D7

Hence:

rock-4cplus (~) $ sudo gpiodetect 
gpiochip0 [gpio0] (32 lines)
gpiochip1 [gpio1] (32 lines)
gpiochip2 [gpio2] (32 lines)
gpiochip3 [gpio3] (32 lines)
gpiochip4 [gpio4] (32 lines)

Assuming 158 means GPIO4_D6, it should be

GPIO("/dev/gpiochip4", 30, "out") # D6 => 3 * 8 + 6
#4

Finally someone who actually knows how it works. The script is from the libmraa example, why I would think it would work.

I see the thing you say about pins and banks, and that now makes a bit more sense. But I only got this far by SUDO SU the user, and in everyday life i would like to just make a .py on my desktop and run the GPIO pins from there ?!

I am SOOO grateful for you reaching out to help Thank you. I will try your ideas later.

I would like to use pin 37 39 and i see there is a whole other way of calculation going on… Nothing like on Raspbery pie, where you can just call it.

:slight_smile:

#5

Actually it is a little more complicated. libmraa can use the WiringX nomenclatura.
periphery.GPIO uses it if you use the two argument constructor, i.e. GPIO(158, “out”).
However, then the old deprecated sysfs interface is used, which has some drawbacks.

Regarding “nothing like on Pi”. RPis are somewhat “victims” of compatibility with all old RPis. The Rocks have way more GPIOs which can be uses more flexible then on RPis, but as always, power come at a price. Nevertheless, you have to find the mapping only once :slight_smile:

#6

Okay, so if I just need for instance 3 pins for buttons/triggers and on RPI it was 29, 19 , 13 with pull up and a hold time of 0.1 from the GPIOZERO library, would it still be doable ??

#7

So the answer is yes, because I believe a Rock can do anything a RPI-4B is capable, BUT if you want to use an unmodified SW: surely not. Let’s see

29, 19 and 13 seems to be numbers of the 40-pin header, as the highest GPIO on RPi4B is GPIO27, right?

On a Rock 4 Pin29 is GPIO2_B2, Pin19 is GPIO1_B0, Pin13 is GPIO4_C6, which all can be controlled by user SW.

gpiozero seems to be a RPI only python lib, also it might be possible to “port” it to another “pinlibrary”. In your case, I would try to rewrite my code using periphery (if it should be python), as this seems to work independent o the underlying HW, or libmraa, as this has support for various SBCs. If these libraries contain all the necessary functionality - I don’t known, haven’t read the documentation (and will not do it). From here are dragons :).

That said, it took me only one hour to port the ARGON One daemon from python and RPi module to C and libmraa (runs now on my 4C+ and 5A). But “your mileage may vary”.

But “pins for buttons/triggers … with pull up and a hold time of 0.1” should be rather simple …

#8

I always assume I am the dumbest guy in the room. Here is how I handle not having to use sudo to do everything. It’s what I do for me.
For radxa / rock 4c+ using Debian: rsetup enable I2C7 or whatever
For Debian add your id to tty, i2c, ssh
getent group, groups - sudo usermod -a -G tty yourid (radxa probably)
Just for giggles i2c group also sudo usermod -a -G i2c yourid (radxa probably)
sudo chmod g+rw filename
sudo chgrp tty gpi* (also i2c* and tty*)
Now set the grp permissions sudo chmod g+rw tty*
Make i2c good with user cd /usr/sbin
sudo chgrp tty i2c*
sudo chmod g+rw i2c*
add /usr/sbin to user path edit .bashrc add at the bottom
export PATH=/home/dave/work:$PATH
and save it
sudo reboot
test it, it should now work i2cdetect -r -y 7
*** i2c stuf: to check if enabled ls/dev/i2c-7
*** check device address sudo i2cdetect -r -y 7

#9

I found this website helpfull when working with GPIO pins : https://osoyoo.com/2022/07/20/rock-pi-4-gpio-control/

#10

Thanks for the help you guys… I am diving straight into it when I am home from vacation.

It always amazes how much we can do for each other in these kind of forums.

I wish you all a good summer!

1 Like
#11

It says:

Which is out-of-date.

Back in April, mine came with Bullseye:

$ cat  /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"