Fail to set GPIO

#1

Hi,

I have installed the libmraa to the Rock Pi X with the steps listed on this link:
https://wiki.radxa.com/RockpiX/dev/libmraa

However, I can’t set the GPIO pin with its sample command or python script:

  • When I try: sudo mraa-gpio set 7 1
    -> It returned: Could not initialize gpio 7
  • When I try the gpio.py in /usr/local/share/mraa/examples/python
    -> It shows:
    Traceback (most recent call last):
    File “./gpio.py”, line 15, in
    gpio_1 = mraa.Gpio(23)
    File “/usr/local/lib/python3.8/dist-packages/mraa.py”, line 474, in init
    this = _mraa.new_Gpio(pin, owner, raw)
    ValueError: Invalid GPIO pin specified

Actually the command: mraa-gpio list works and could show exact 40 pin listed in aforementioned link. I also try different pin in gpio.py, but no luck!

Here is my system:
OS: Ubuntu 20.04.4 LTS
mraa-gpio version: Version v2.1.0-15-g03d3059 on ROCK PI X

Does anyone have solution on this? Thanks!

#2

Can you try with different pin numbers and see if you get a different response?

Anything in dmesg?

#3

Yes, I have tried another pin number, still got same error
For sudo mraa-gpio set 7 1, dmesg shows:
export store: invalid GPIO 335

I have checked the folder under /sys/class/gpio:
gpiochip737, gpiochip740, gpiochip826,gpiochip853,gpiochip926
It seems the chip’s base value are different from this link: https://wiki.radxa.com/RockpiX/hardware/gpio

Thus, I tried to use sysfs to control the gpio. Although it works, I still can’t use mraa in python script

Here are the new GPIO pin number I found:
335 -> 847
334 -> 846
338 -> 850
329 -> 841
229 -> 741
348 -> 860
342 -> 854
346 -> 858
332 -> 844
336 -> 848

#4

Ah, that’s very interesting - I was trying to write a dtb for a SPI/TFT display and was trying to work out why the example elsewhere on github used numbers that made no sense given the wiki page.

#5

I have the same problem, I tried the GPIO numbers, but nothing works! All very annoying… The aio.c example (ADC) works OK, but not the gpio.c.
What’s up?

#6

[SOLVED]
You have to run mraa/examples/c in root AS root, as per the instructions. This is a tad inconvenient as my application will have to run as root too, unless there is a fix by relocating a bunch of files in home/ or some other method?
Any ideas?

#7

for my information : what kernel version are you using and what libmraa ?

#8

$umame -r
4.4194-11-rk3399 …
$journalctl -t
v2.1.0-24…
OK - comments?

#9

So this is a 20.04 right ?
I can’t have libmraa working on my 22.04
Shows “no pins” instead of 40 pins.
Tried to recompile the kernel, now my rock pi X is stuck at boot.
I’m Gonna reinstall with 20.04
if someone wants to give a hand he is welcome
Christian
Mistralkriss at g(like google)mail dot com

#10

update : 20.04 just installed , shows 40 pins. working on the GPIO numbrs too now

#11

maybe this can help
https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html

(I can’t have a led blink thow lmraa seems to work)
I need to handle a button, a led too.
If someone knows about all this, I can join a Discord, or provide one, to talk about this stuff.

more news :
I echoed 847 to /sys/class/gpio/export and had a gpio847 created
since 847 is supposed to replace 335, I wired a led onto pin7 on the connector (with a 220ohms R ) which is supposed to be (335 so->847)
direction was input I wrote out into direction
value was 0 I echoed 1 into value
but the led doesnt light up. (solved, see hereunder)
more news : lbmraa0.4 works, not the one we can find on github (on a 20.04 ubuntu server) ,
i have active_low=0 , led ground is on that pin 860, pin37 on the connector near ground pin39 )
led anod through a resistor is on the +5v (could be 3.3v, works) . when I write 0 to value, th led lights up, when I write 1 it lights off. apparently the logic is inverted. but ho well… now I wonder how to program it with any language, and how to handle a button and an interruption

#12

@Nasca Please take a look at this issue.

#13

I’m using ubuntu 22.04 on my RockPiXs and I see in a number of places that sysfs is deprecated for GPIO, and it also looks like MRAA is using sysfs. It seems gpiod is the more-current way to interact with GPIO so I thought I’d try it (I’m fairly new to GPIO in linux). After apt installing gpiod (as well as libgpiod-dev and/or python3-libgpiod to interact programatically), I was able to see the gpio devices in /dev…

root@rockpix:~# ls /dev/gpiochip*
/dev/gpiochip0  /dev/gpiochip1  /dev/gpiochip2  /dev/gpiochip3  /dev/gpiochip4

… and by running gpio detect, and comparing the number of lines in each device with the RockPi X GPIO wiki page I was able to tell which chip was which.

root@rockpix:~# gpiodetect 
gpiochip0 [INT33FF:00] (98 lines)
gpiochip1 [INT33FF:01] (73 lines)
gpiochip2 [INT33FF:02] (27 lines)
gpiochip3 [INT33FF:03] (86 lines)
gpiochip4 [INT0002 Virtual GPIO] (3 lines)

I was then able to succesfully use gpioset on the pin I wanted and verify with a mulitmeter that the line was being toggled.

Note the offsets being wrong doesn’t seem to matter in this way of interfacing.

I hope this helps someone who may be stuck on using GPIO on the RockPi X on newer systems.

One thing I will note is that the GPIO pins all come up as “unnamed” when listing using gpioinfo… so you can’t refer them by the names on the wiki page (like GPIO_DFX3 for pin 12) (and here in the kernel src). I’m not sure how those names get populated, but calling out a pin by name (rather than gpio device+offset) would be much more developer friendly.

#15

Thanks a ton [cyborg0x2b] .
(I wasn’t working the last 2 days that’s why I hav’nt answered yet.)
You are absoluetly right about sysfs, deprecated, But I thought libmraa was the only avail package (the 0.4 one), so thanks a ton for this info about gpiod and stuff.

But, I might be wrong but the biggest problem I have about this rock pi X connector is “how to handle a button input” using interrupt. we already have an output with sysfs, but and ISR input is another story.
That’s the story I’m after :wink:

If you have a simple python code to write an output I guess it would be interresting for the records (and me :wink: ) but the real deal for me, is managing the input, and the right way (interrupt)

#16

@Nasca the problem is still there. Anything on your side ?

Basically the question is

How do we handle a button , either using sysfs (and libmraa) or anything else ?

#17

@KrissNC, My apologies for not responding sooner. That was my first and only comment on this forum, so I wasn’t monitoring it very carefully.

Taking a quick look at the gpiod python documentation, I see that there there’s a line for testing buttons: python3 -m gpiod.test.button <chip> <line offset> [rising|falling|both]. When I run this as root, it waits for input. I don’t have physical access to my RockPi X at the moment, so I haven’t had a chance to test it.

Edit: I realize this doesn’t address your ISR question, but maybe it will be “good enough”?

#18

Thanks for your reply @ cyborg0x2b.

My project needs 700 boards, up to thousands. Apparently the Rock pi X is not shiping anymore (or being built) so I moved to a sibling board, called up4000. Very close architecture. I still have the same kind of problems thow. If I had something very clear on how to handle a button on rock pi X, I can probably port it to my other board. (a button, using interrupt, not polling)
For example I’m trying to have a device tree (dt file) … I don’t have it.
It is so unclear what’s needed to catch a button press… Same for I2C, nothing is clear on how to use it.

#19

There’s also the Odroid H3/H3+ that look capable, if you’re needing an x86_64. Personally, I prefer ARM-based boards (maybe until RISC-V matures a bit more), but need x86_64 for one particular proprietary library that only provides x86_64 bins (yuck). I found that on the ARM based boards gpio tends to be better documented, or at least more widely used by the community.

#20

I managed to wait for a button press, using “select” in a c program. a problem was making an “edge” file to appear, then I could write “both” into it, to detect falling and raising edges, It works.

Now I need to use I2C… to display something.