VisionFive2 PWM led and servo control, the non-'visionfive2.gpio' way

VisionFive 2 （English Forum)
1

I have a video online of the VF2 controlling a PWM Led and a Servo.

(I include a 5v level converter circuit for the servo in the description.)

Controlling PWM led’s and servos is fairly easy and well documented using the visionfive2.gpio package; which itself mirrors the RPI.GPIO package.

Which is fine; but I actually needed to control PWM channels from userland on my MangoPI MQ Pro (also a risc-v based system).

Not having a ‘architecture specific’ *.gpio package for the MQ Pro I decided to make my own architecture-neutral userland PWM control system that will work with any kernel driver implementing the legacy /sys/class/pwm api.

The ‘key’ feature of the video and code above is that it also works (and has been tested on) Raspberry PI’s and the MQ Pro; eg chipsets from SciFive, Broadcom and Allwinner.

The VF2 in the video is running on the 202409 release; and using the two PWM pins mapped by the stock device tree.

My code only controls the hardware timers, it does not do any device tree setup and cannot map pins itself, so if you want to use all 8 of the timers available on the VF2 you will need a custom device tree or overlays.

Not strictly VF2 related but still risc-v; Associated with this I have a guide for modifying DT’s on the MQ pro (it’s a bit of a niche board, my guide covers ubuntu install using a lycheeRV image, and then ‘fixing’ the device tree for the MQ pro)

2 Likes
2

You can control devices through legacy /sys/… interface from the command line or a bash|cron|systemd|… script. There’s an example somewhere in the forum for cpu temp fan control.

3

My tool IS just such a script and uses the /sys/ tree. It has shell and python interfaces. The fan control scripts are good for vf2 specific use, but this is different; a cross-architecture tool that can allow non root users to control the timer despite the /sys tree being rroot only.

4

I usually sudo, but…
The documentation for sysfs says -
Note as stated in include/linux/kernel.h “OTHER_WRITABLE? Generally
considered a bad idea.” so trying to set a sysfs file writable for
everyone will fail reverting to RO mode for “Others”.

Doesn’t specifically talk about group writable, might have to setup permissions on boot.
Official way to change /sys/… ownership - still looking
could be done in /etc/rc.local
Just tested, on boot, of course reverts to root:root

I just tried making my laptop /sys/class/backlight/amdgpu_bl0/brightness root:plugdev group writable and I can now control the brightness by writing to brightness.

plugdev for no good reason, just I’m already a member and didn’t have to log out/in,
maybe create a special group ??