How to control the GPIO?

#11

Somehow it doesn’t work in my build (Debian ARM64 + DTB from armhf).

The red LED is on in Debian ARM64 and off in armhf by default, after I copied the DTB from armhf to ARM64. I got the audio but the LED turns off. The intfc:dtoverlay=two-color-led setting in /boot/hw_intfc.conf doesn’t seem affect this on neither side. I guess there are some conflicts going on.

1 Like
#12

The example with the red LED was more to demonstrate the general usage of the GPIO Python class. It can be used to switch any GPIO pin. On my RockPi Armbian system the red LED works.

#13 
GPIO_3_D5 = 3 * 32 + 3 * 8 + 5  # = 125
gpio = GPIO(GPIO_3_D5)

If you could parse the name string to convert to number, that would help some people to calculate the numbers.

#14

For newer kernel, the LED is configured as heart beat device. You can not control it. You can control it with led trigger.

cat /sys/class/leds/user-led2/trigger
none rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 mmc1 timer oneshot [heartbeat] backlight gpio cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 default-on rfkill0 mmc2 rfkill1 rfkill2

For example, you can set it to emmc read/write status with following:

echo mmc1 >  /sys/class/leds/user-led2/trigger
1 Like
LED error codes
#15

Good idea, already updated.

#16

HI Jack,
I have problem to activate the GPIO pins on Ubuntu mate desktop with the latest kernel. Could you please have a look at my problem?
https://forum.radxa.com/t/mraa-gpio-list-no-pins/1467

Thanks,
Rolly

#17

Hi friends,

I have a silly question, but I’m not finding the answer.

I’m reading the documentation of the mraa to see if I can learn how to control my gpios. On Raspberry we have to define if we are either going to use the GPIO address or the BOARD address.

Can I do or need to do the same with mraa? What about the gpio.cleanup command ?

Thanks in advance!

#18

Simple C function to get gpio number from string such as GPIO1_D3. Can be ehanced to support lower case such as gpio1_d3. Hope this helps someone.

int get_gpio_number(char *gpio_str)
{
int gpio_no, bank = 0, pin_mul = 0, pin = 0;

if(!gpio_str)
    return -1;

if(strlen(gpio_str) != 8)
    return -1;

bank = gpio_str[4] - '0';
pin_mul = gpio_str[6] - 'A';
pin = gpio_str[7] - '0';

gpio_no = bank*32 + pin_mul*8 + pin;

return gpio_no;
}
2 Likes
#19

The problem with porting libmraa to the ROCK Pi 4 is that there is a TON of software written for many HAT devices that depend on WiringPi. This kind of comparability is critical if you want folks to adopt ROCK Pi 4 over the Raspberry Pi 4. Perhaps you might reconsider your decision and also port WiringPi?

1 Like
#20

I agree with @few. There already exists a WiringNP, which is WiringPi for Nano PI from friedlyelec.
It shouldn’t be a big problem to fork the repo and include also RockPi 4.

The board is detected using CPU information in boardtype_friendlyelec.c. I don’t have any of the boards yet, but I do think that if you compile the repo the board will be detected as Nano Pi M4, which uses RK3399. In the wiringPi.c there are various schemas related to detected board. You should patch the GPIO schema of NanoPi M4 according to RockPi 4. An experienced programmer would need some hour to fork, patch and make the WiringPI for RockPi.

I do agree, that Radxa team should spend this hour of labour work to clone almost done work.

However, not all apps would work, even if you would have WiringPi implemented. Only the apps, referencing with header pin number shall work. For others you would still need to change the GPIO numbers in source.

#21

In my opinion It is no-sense to develop a board which want to be as much as possible compatible with Pi3 and on the other side not supporting the ecosystem of Pi3 world, and in particular the porting of one of the most well working libraries for Gpio

1 Like
#22

One doesn’t need to support all the childish hacks that are built for pi. Just because a lot of noobs use something stupid does not make it correct or reasonable.

1 Like
#23

I agree with @luke1962. Those noobs are actually buying your boards, don’t forget it.

1 Like
#24

Dear Radxa,

I would like to have WiringPi and RPI.GPIO library for interfacing ready made examples for Raspberry Pi. I have noticed that FriendlyElec already ported those libraries to their Nano Pi M4. Unfortunately they violate the license agreement and their library are not open source, so no possible port to Rock Pi 4. You could inform them about their violation, they had copied opens source and made it like their own source??? We (buyers of Rock Pi) would expect also from Radxa, to port those widely used libraries made for Rpi.

Thank you.

2 Likes
#25

We prefer to support WiringX, which is a more general library.

1 Like
#26

It doesn’t seem to support RockPi4.

1 Like
#27

I found a port of wiringX by Radxa, but it seems to be for Rock SBC rather than Rock Pi 4.

https://wiki.radxa.com/Rock/wiringX

Personally, I am plan to try using the GPIO via a bash or python script like here:

#28

Hey @Nechoj

May I use your posted code in an open source (GPLv3) program/script?

Thanks!

#29

I have a good news :slight_smile: The wiringX maintainer agreed to help us get ROCK Pi 4 supported. We will send him a kit. Let’s wait…

1 Like
Rockpi4 WiringX
#30

Sorry I missed your message. Of course you can.

1 Like