Pin class should be used in generic implementations like SoftwarePwmChannel or SoftwareSpi

[krwq]

We've recently added Pin class but classes like SoftwarePwmChannel or SoftwareSpi use pin directly. I think we should provide constructor overloads for at minimum those two classes.

Other candidates:

• LCD Character screen
• GPIO extenders

[Ellerbach]

What would be the advantage of doing this? And what would be the typical usage?
For me, the Software PWM and Software SPI have different usage than the Gpio Pin. So not really sure of the value for mixing the Gpio Pin with the software PWM and SPI.

[krwq]

to me anything which uses multiple GPIO pins as input is candidate for using GpioPin. What are your thoughts on what qualifies?

[pgrawehr]

You mean we should at a ctor taking a list of Gpiopins instead of numbers? I agree, as this was one of the use cases why we added the GpioPin.

[Ellerbach]

So how would you see the API? Any example of high level implementation? I fully get the extender, that's all ok and done for that, I'm bit more skeptical for PWM and SPI.

[krwq]

For SPI you could add another constructor like this (and similar for PWM):

public SoftwareSpi(GpioPin clk, GpioPin sdi, GpioPin sdo, GpioPin cs = null, SpiConnectionSettings? settings = null, bool shouldDispose = true);
// existing one:
public SoftwareSpi(int clk, int sdi, int sdo, int cs = -1, SpiConnectionSettings? settings = null, GpioController? gpioController = null, bool shouldDispose = true);

that would allow to easily use pins from different controllers. For SPI especially that makes sense for CS pin which you might want to use extender for.

PWM is more arguable since it only takes 1 pin.

[Ellerbach]

Ho yes, definitely. We can add constructors for this and adjust the bindings. What we have to keep in mind is that the default behavior for GpioPin is to open it. Good news is that we can change the mode when needed.
We do already have bindings on nanoFramework which does accept either Controller and pin number either GpioPin. It does require to change a bit of conde inside to operate GpioPin directly rather then the controller. But it's quite straight forward.

[joperezr]

Just throwing out a thought here, but what about creating a special subclass of GpioController which takes in GpioPin instances, and "acts" as a controller but in reallity it is really just forwarding the reads and writes to the GpioPins? The advantage of a model like this, is that you would no longer need to essentially add hundreds of new constructors to the types in this library, and instead just use the existinc controller that already takes in a custom GpioController. The usage I have in mind would be something like:

GpioPin clk_GpioPin, sdi_GpioPin, sdo_GpioPin;

var virtualGpioController = new VirtualGpioController();
virtualGpioController.AddVirtualPin(clk_GpioPin, pinNumber: 16);
virtualGpioController.AddVirtualPin(sdi_GpioPin, pinNumber: 17);
virtualGpioController.AddVirtualPin(sdo_GpioPin, pinNumber: 18);

var SoftwareSpi = new SoftwareSpi(16, 17, 18, virtualGpioController); // With this, we can now still use GpioPin objects we have and use existing constructors.

The VirtualGpioController would literally only be a collection of GpioPins and would just forward the calls made to it like:

public override void Write(int pinNumber, PinValue value) => _gpioPins[pinNumber].Write(value);

OpenPin override would likely just be a no-op, since we know that virtual pins passed in to this controller would already be open.

Thoughts?

[krwq]

While I agree this is a solution it likely feels overly complex from user perspective. We could also create a source gen which does reverse (so we always take pins but constructor which takes numbers could be generated).

Improving on suggested idea, I'd rather go with something like this so you don't have to know the virtual numbers:

var vc = new VirtualGpioController();
var SoftwareSpi = new SoftwareSpi(vc.GetVirtualPinNumber(clk_GpioPin), vc.GetVirtualPinNumber(sdi_GpioPin), vc.GetVirtualPinNumber(sdo_GpioPin), vc);

but still, I'd rather have us direct support for popular devices

[Ellerbach]

[Triage] Having both approaches with a VirtualGpioController makes sense to cover different scenarios. If anyone have time for a proposal and draft PR, feel free to assign yourself!