[Proposal] Provide a Software implementation of the SPI protocol.

[dotnet]

[Proposal] Provide a Software implementation of the SPI protocol.

[joperezr]

There has been some changes lately around what to do with communication protocols. We now plan to create protocol interfaces, IGpioController has been added already, but we want to add similar ones for IPwmController, ISpiController, and II2cController. I think it would be better to first finish defining those remaining ones, and that way we can switch our current hardware implementation of the protocols to implement that interface.

Once we have that, device bindings can have constructors like MyDeviceBinding(ISpiController spiDevice) and you can pass in either a hardware based spi device or a software (gpio) based one that implements that interface. Once we have those interfaces, we should revisit this issue and make sure we add the software implementation of those protocols.

[shaggygi]

except that it would take pin numbers instead of Spi Channels and connection settings.

I think the constructor would still use SpiConnectionSettings. Now that SpiConnectionSettings include ChipSelectLineActiveState, DataFlow, and DataBitLength, it would make it easier to configure. But as mentioned, it should also have the GPIO pins.

// Bus ID = 0, Chip Select Pin = 25.
var settings = new SpiConnectionSettings(0, 25)
{
    ChipSelectLineActiveState = PinValue.High,
    DataBitLength = 5,
    DataFlow = DataFlow.LsbFirst,
    // other properties set as needed.
}

// SCLK = 18, MISO = 23, MOSI = 24.
var spiDevice = new GpioSpiDevice(18, 23, 24, settings);
var myBinding = new MyBinding(spiDevice);

[joperezr]

I believe what you ant here is the ability of having software SPI instead of hardware SPI as we have today. If that's the case, I would instead prefer having the device binding take in the GPIO pin numbers instead of taking in a device, and inside its implementation it would do the software SPI. This is the way that a lot of Adafruit device bindings work today as well. Here is an example of a binding already in our repo that does it:

iot/src/devices/Mcp3008/Mcp3008.cs

Lines 33 to 52 in a0afb05

	public Mcp3008(SpiDevice spiDevice)
	{
	_spiDevice = spiDevice;
	_protocol = CommunicationProtocol.Spi;
	}
	public Mcp3008(int clk, int miso, int mosi, int cs)
	{
	_controller = new GpioController();
	_clk = clk;
	_miso = miso;
	_mosi = mosi;
	_cs = cs;
	_controller.OpenPin(_clk, PinMode.Output);
	_controller.OpenPin(_miso, PinMode.Input);
	_controller.OpenPin(_mosi, PinMode.Output);
	_controller.OpenPin(_cs, PinMode.Output);
	_protocol = CommunicationProtocol.Gpio;
	}

As you can see, this binding will allow for you to initialize it with a spidevice, but it will also support you passing in the pin numbers manually and it will instead use GPIO to do a software SPI.

[shaggygi]

I guess I was thinking it would be no different than passing in a UnixSpiDevice or a newly offered GpioSpiDevice for the abstract. You still have to pass in the pin numbers and settings info for a GpioController or GpioSpiDevice.

As attempted here, you pass in the related info and the GpioSpiDevice creates the GpioController behind the scenes.

I guess you could pass in the pin numbers and settings like you suggested and have the GpioSpiDevice be created behind the scenes for the binding.

I like the GpioSpiDevice concept for a couple of reasons...

1. You only have to worry about 2 options to decide on protocol to use (if the device offers both I2C and SPI on same chip). Related to #89, if you had both and offered GPIO to do the bit-banging... it would be 4 options.

2. The GpioSpiDevice includes all the logic to perform the protocol, including clocking in/out, polarity, phase, etc. If you pass only the pin numbers and create a GpioController, every binding would have to implement the logic for doing this. Reference the current ReadGpio method for Mcp3008 as an example. One other thing to point out... the Mcp3008 binding is currently coded to only support Mode0, but the device also supports Mode3. Meaning, more logic to add to the individual binding.

I have not had time, but think this same concept applies for a GpioI2cDevice, as well.

[krwq]

I think this should be something like I2cDevice.Create(settings) and SpiDevice.Create(settings) (I just got a quick look at the issue so disregard if I'm offtopic)

[joperezr]

Marking as up-for-grabs. The next step in this issue would be to send a PR with the software implementation of SPI protocol. Initially we would want to have it under the devices tree, and once we have the interfaces for the SPI protocol ready then we can move this to the main library. In terms of Api Surface, this class should have the same signatures as our regular SpiDevice, except that it would take pin numbers instead of Spi Channels and connection settings.

[Ellerbach]

@shaggygi do you feel this is still to be open? With all the recent addition to SPI and I2C, I feel this could be closed.

[shaggygi]

@Ellerbach We have this one, but I was thinking it was eventually going to be moved within core API. We can go ahead and close for now.