I forked the Library, Driver, and Sample repos with the ultimate purpose of creating support for the Microchip Mcp23xxx gpio drivers.
Please feel free to check out the repo and criticize.
To do this I forked the Library and edited the GPIO project in order to provide interface access to external assemblies.
The Drivers fork then uses this and currently only includes support for the 16bit open drain spi version Mcp23S18 as a proof while the Library pull request is reviewed.
But if that is approved I will add support for the other 6 ICs in the lineup.
Its worth noting I don’t really know how to manage the nuget packages when working on library modifications so to use this Driver not only Gpio, but the forked Spi and I2C dlls need to be included.
The Sample fork includes an example of the whole thing.
I think its worth noting the implementation of a custom provider using the IGpioContollerProvider interface. This allows implementation of the frameworks GpioPin type without trying to extend the sealed GpioPin class. I had a feeling it could be done this way, and I imagine it will be possible to extend UART, SPI and even I2C if need be.
That is what is holding this. If we were to do this, why not do it everywhere? And if we were to do it everywhere then this is a major change that is on a lower priority when it comes to the other issues that needs to be handled. This is a “nice to have” feature and will not block anyone.
It seems I then entirely misunderstood the intention of having these interfaces in the first place. If the change is to merely ensure interface members were public, in this case a single edit from internal to public, then they were probably only intended to implement the native hardware and there was likely no intention to have the community expand the framework. And with an outlook like that I’ve got other priorities to focus on instead. Just wish this was somehow more clear before investing the time, I’ve no interest in always working from a forked repo…
As at least i believe you, @Gus_Issa, are aware, there has been some talk about the proper strategy to extend things such as these controllers. Simple inheritance fails as there also has been question regarding the extensive use of sealed classes. (You even introduced the library bug asking the same question.)
In this particular post you gave a like to the comment suggesting the implementation of the provider interface as a way to perhaps properly extend the UART controller for the OPs purpose.
So my confusion is really in the belief that implementation of these interfaces must be the intended method to extend functionality. Please bear with me as I now come to the understanding that is not the case.
I can understand such functionality is low on the to do list, and wont assume what it takes to determine a safe or feasible change. But at least my recent pull drafts exercise the external implementation of IGpioControllerProvider, and demonstrate how limited a change is needed.
Ultimately things may not be feasible for TinyClr, it would just be cool to feel we’re all on the same page. Not understanding custom provider implementation was never an available option feels like not being on the same page…
Good news. A recent PR merge has made Gpio GpioPinValueChangedEventArgs constructor public. @Darko you might not be able to inherit, but at least you can now implement an entire Gpio Controller/Provider if you wish…
