FFM Plugin: Extend plugin with PwmFFMSoftware

[FDelporte]

Extend PWM functionality with a SOFTWARE PWM implementation in the FFM plugin.

Based on results and improvements after #551 and #553

Can use Raspberry Pi kernel improvements from raspberrypi/linux#6450

Documentation changes needed: probably needs to describe how to configure with dtoverlay=pwm-gpio,<param>=<val>.

[DigitalSmile]

Okay, so I guess there is nothing much to do with our code.
Enabling software PWM is controlled by the device tree and overlays. E.g. to enable software PWM in raspberry you can add this overlay:

// Definitions for w1-gpio module (without external pullup)
/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";
    fragment@0 {
        target-path = "/";
        __overlay__ {
            pwm_gpio: pwm_gpio@0 {
                compatible = "pwm-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&pwm_gpio_pins>;
                gpios = <&gpio 4 0>;
                status = "okay";
            };
        };
    };

    fragment@1 {
        target = <&gpio>;
        __overlay__ {
            pwm_gpio_pins: pwm_gpio_pins@0 {
                brcm,pins = <4>;
                brcm,function = <1>; // out
                brcm,pull = <0>; // off
            };
        };
    };
};

This instructs kernel to use bcm pin 4 for PWM and autoload software PWM driver. After that there will be regular pwmchip device and you can interact with it using our providers (FFM or linuxfs).

This feature is quite new to kernel, it is released with 6.11 kernel version at September 2024. I guess in a near future there will be more usable config.txt options, rather than creating a special device tree PWM entry.

So, long story short we need to decide whether we are going to creating userspace software PWM or we can leave it with kernel.
One thing that we can do with this issue (if not recreating software PWM by ourselves) is to rename provider: remove Hardware postfix to make it more general.

@FDelporte @eitch @taartspi what are your thoughts?

[DigitalSmile]

Btw, for general purpose usage kernel implementation is better than userspace.

Note the kernel-driven PWM has jitter, but it remains within a ~900ns deviation. While the software, userspace PWM is over 5us. My scope game isn't strong, but this - as you might expect- suggests GPIO PWM jitter is quite considerably better than userspace.

From https://forums.raspberrypi.com/viewtopic.php?t=365816

[eitch]

I'm a bit lot as to what to say. So this means the kernel has internally two implementations: Hardware and software? And we can also do a software version in Java? For me this is now getting even more confusing =)

[DigitalSmile]

So this means the kernel has internally two implementations: Hardware and software? And we can also do a software version in Java?

True for both (but for the sake of truth, this is not "internal", it's just two separate drivers user can load).
But I do not think it will be of any value to create our own version, because of high latency and less accuracy. Sometime ago I make a prototype to control a fan - it was not very good working. I can imagine how it will go wrong with more sensitive devices (like servos).

For me this is now getting even more confusing =)

Indeed, that is why I am asking for help :)

[FDelporte]

Confusion++ ;-)

FFMHardwarePWM is now working ok with chip+address. So the most critical question, can we also make it work with BCM to use the kernel to have PWM on "any" pin? Or should we stick to the two we can use now, and advise to use a PWM expander board for all other use cases?

[DigitalSmile]

So the most critical question, can we also make it work with BCM to use the kernel to have PWM on "any" pin?

Yes, with configuration of device tree / config.txt and outside of pi4j code

[FDelporte]

@DigitalSmile can you provide short how-to documentation? I will try it out and add to docs.

[DigitalSmile]

@DigitalSmile can you provide short how-to documentation? I will try it out and add to docs.

What platform should we target? I guess it really depends on a hardware, e.g. we need separate instructions for RPI Zero, RPI5 and OrangePi.

[FDelporte]

I'm testing on RPi 4 and 5 now. Can do Zero later.
OrangePi and other boards from other providers could be added later...