v 1.4 Device definitions (and other crazy ideas)

[EAGrahamJr]

Many of the diozero devices are implemented as concrete classes, tied to GPIO providers/delegates. This makes using the same type of device interface from a completely different kind of "port expander" either difficult or not possible.

Case in point, I recently got an Adafruit CRICKIT and it's currently a bit hair-pulling to cast any of the ports as diozero "devices". This board uses I2C as the main protocol and has an onboard processor to send/read the appropriate signals.

If DigitalInputOutput was defined as an interface, a CRICKITDeviceFactory (based on an SeeSawExpander, which uses an I2CDevice) would be able to produce 8 of them.

This proposal would be to take all the common "device types" that have been created and define interfaces for each. I think in order for it to make sense, it would probably take a lot of re-shuffling of things and could be a lot bigger than just a minor point version.

---

Other crazy/dumb idea: have you considered using Kotlin? 😈

[mattjlewis]

This should be exactly what the DeviceFactory concept enables, isn't that CRICKIT very similar to the PiconZero board?

Yes to Kotlin, looked into it a few years ago in the early days and I got a bit frustrated with it. I believe diozero as is would work well with Kotlin but need to read up more on higher-level Kotlin stuff rather than treat it as another Java-like syntax. Thoughts?

[EAGrahamJr]

The easiest way to look at what I'm doing with Kotlin would probably be by example. This branch contains my latest work on the above.

I've looked at the DeviceFactories and to be honest, I'm at a bit of a loss where the listeners aspects come into play. Okay, skip that - the PiconZero class was what I was missing as a reference.

[mattjlewis]

Excellent, I could do with improving the documentation around device factories, and in general actually.
Be very keen to hear how you get on with the CRICKIT.
Maybe start a separate discussion on Kotlin and a minimal API to optimise the experience. Keen to learn more, always think I should do an Advent of Code in Kotlin - did a few in Java but have little time recently.

[EAGrahamJr]

Well, the first thing I had to chase down was the notion of the device.key (to control open/close states via the factory). The biggest sticker was to create a matching PinInfo that would generate appropriate keys -- there's a lot of indirection there and it took a bit of digging to unravel it.

However, my test code is passing with the refactor to match device factories. And it's all Kotlin, but thanks to the interop with Java, should work just fine.

[EAGrahamJr]

I think this is more "unintended consequences", but the CRICKIT board has "multi-mode" inputs - e.g. the "signal" block can be a binary input OR an analog input. I'm currently working around this by adding the same PinInfo as both a GPIO definition and an ADC.

Is this something you had envisioned or is this a "new" thing? 😀