Ok I have confirmed this.
First disabled both PWM.
Then enabled one by one.
Enabling PWM2 is bringing up pwmchip1
Enabling PWM3 is bringing up pwmchip2
Whereas in the older legacy image, it shows pwmchip3
pi@controller-18794:/sys/class/pwm$ ls
pwmchip0 pwmchip1 pwmchip2 pwmchip3
We are already using mraa in our legacy image and our software has a dependency on it.
I was checking rock-pi-s branch of your mraa fork.
Do you think changing the parent_id in src/arm/radxa_rock_pi_s.c will fix this?
Currently they are set to 2 and 3.
b->pins[11].pwm.parent_id = 2; // pwm2
b->pins[11].pwm.mux_total = 0;
b->pins[13].pwm.parent_id = 3; // pwm3
b->pins[13].pwm.mux_total = 0;
Will changing them to 1 and 2 fix this?
What about GPIO 22 issue? That is also not working with mraa.
>>> pin = mraa.Gpio(22)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.11/dist-packages/mraa.py", line 614, in __init__
_mraa.Gpio_swiginit(self, _mraa.new_Gpio(pin, owner, raw))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: Invalid GPIO pin specified
No it wonāt. Newer Linux kernel no longer assign fixed number to pwm controller, instead in a first come first serve manner. Hardware initialization order is non deterministic, so there is no guarantee that even with the same overlay enabled you will get same numbering all the time. We would switch to register based access for PWM, which will guarantee the device order.
@Nasca please check the GPIO issue though.
ok thanks for explaining the issue.
So it seems like we canāt use mraa anymore in the new image atleast for the PWM.
And I am guessing this will require fix in the mraa itself.
Can we expect this support from the Radxa team ? If yes, then any expected timeline?
How is this working for other boards though ? Other boards having same problem or mraa is using register based access for them?
And yes, it would be really helpful if we can atleast get GPIO working fine from mraa.
Out of all pins we need, GPIO 22 is not working.
We will fix this, as we are moving more products to the newer kernel. But there is no timeline yet.
I think all our boards are affected. Other vendorsā board could be affected as well, since pwm.parent_id is part of the base MRAA data type, so I think many would use it like what we did. Raspberry Piās implementation is register based.
ok @RadxaYuntian understood. Thank you for prompt explanation of the issue.
@Nasca let me know if you need anything for me to test for the GPIO issue. I have rock-pi-s with old and new image in my test setup.
Lets also understand the GPIO issue and then we will take a call and go ahead with testing periphery library.
@RadxaYuntian Do you have any info on whether periphery python library would work without any issues?
There are a bunch of python PWM library. Any of them should work, since this is a standard Linux interface.
To check which PWM device is mapped to which physical pin, you can check the symbolic links under /sys/class/pwm/. They should point to some file named like pwmX@ffabcdef. The part after @ is the register address, and that is linked to the physical pin.
Ok great. Thanks.
Now testing PWM with peripheral python library.
from periphery import PWM
# Open PWM chip 0, channel 10
pwm = PWM(0, 10)
# Set frequency to 1 kHz
pwm.frequency = 1e3
# Set duty cycle to 75%
pwm.duty_cycle = 0.75
pwm.enable()
# Change duty cycle to 50%
pwm.duty_cycle = 0.50
pwm.close()
This is in the /sys/class/pwm/ directory
(venv) pi@controller:~$ ls -l /sys/class/pwm/
total 0
lrwxrwxrwx 1 root root 0 Sep 9 10:44 pwmchip0 -> ../../devices/platform/ff180000.pwm/pwm/pwmchip0
lrwxrwxrwx 1 root root 0 Sep 9 10:44 pwmchip1 -> ../../devices/platform/ff180020.pwm/pwm/pwmchip1
lrwxrwxrwx 1 root root 0 Sep 9 10:44 pwmchip2 -> ../../devices/platform/ff180030.pwm/pwm/pwmchip2
@RadxaYuntian as per your statement
Newer Linux kernel no longer assign fixed number to pwm controller, instead in a first come first serve manner. Hardware initialization order is non deterministic, so there is no guarantee that even with the same overlay enabled you will get same numbering all the time
Does this mean that PIN 13 i.e PWM3 will not always correspond to /sys/class/pwmchip2 ? It can be any of pwmchip0 / pwmchip1 / pwmchip 2 ?
So we have to pass chip and channel in the periphery library
If I want to set PWM on PIN13 i.e PWM3
what values of x and y should I pass in this?
# Open PWM chip x, channel y
pwm = PWM(x, y)
PWM3 would always be this device. You can check the name under /sys/devices/platform/ff180020.pwm/pwm/ to get the pwmchip number, then use that in Python to create the device.
Rockchipās PWM controller only has 1 channel, so PWM(2, 0) should work.
Ok makes sense. will test it out.
Where in the documentation, can I find mapping of rock-pi-s PIN NO. and corresponding GPIO chip no. and Line no. ? Can you send me some link for reference?
Because periphery library asks for chip number and line number.
from periphery import GPIO
# Open GPIO /dev/gpiochip0 line 10 with input direction
gpio_in = GPIO("/dev/gpiochip0", 10, "in")
# Open GPIO /dev/gpiochip0 line 12 with output direction
gpio_out = GPIO("/dev/gpiochip0", 12, "out")
The Rockchip platform usually has 5 groups of GPIOs (also called banks): GPIO0 ~ GPIO4 (different chips will be different), each group has 32 GPIOs. Each group of GPIOs is divided into 4 groups, A/B/C/D, with 8 GPIOs in each group (0~7, also called bank_idx). So the GPIOs can be named from GPIO0_A0 to GPIO4_D7. Taking GPIO3_C5 as an example, we can deduce that its bank is 3, and its bank_idx is 21, i.e., GPIO3_C5 is the 21st GPIO in group 3.
ok thanks. Testing it now.
egg:
gpiochip: 0; line: 10 <==> GPIO0_B2
gpiochip: 0; line: 12 <==> GPIO0_B4