-
Couldn't load subscription status.
- Fork 70
Description
The same configuration cannot be used between FS and FFM PWM providers.
As a user I would expect to be able to use the same configuration, regardless of the underlying provider.
With the FS provider I can use the following configuration. Admittedly, this relies on the FS plugin defaulting the chip to 0):
// LinuxFS
val pwm = pi4j.create(
Pwm.newConfigBuilder(pi4j)
.id("refresh")
.name("Refresh PWM")
.address(2) // PWM channel
.pwmType(PwmType.HARDWARE)
.frequency(220)
.dutyCycle(50)
.shutdown(0)
.build()
)The FFM provider changes the definition of address to now refer to the chip and uses busNumber instead to refer to the channel.
// FFM
val pwm = pi4j.create(
Pwm.newConfigBuilder(pi4j)
.id("refresh")
.name("Refresh PWM")
.address(0) // PWM chip
.pwmType(PwmType.HARDWARE)
.frequency(220)
.dutyCycle(50)
.shutdown(0)
.busNumber(2) // PWM channel
.build()
)This seems contradictory to the plugin architecture. From the user's point of view these are now different device types requiring bespoke configurations.
The FFM version does make sense as it makes the configuration explicit by removing a dependency on properties if a different chip is required.
A fix might not revert the FFM version to be compatible with FS. Maybe the FS version needs a breaking change in V4 to make it compatible with FFM and maintain the usability of the plugin architecture.