search

jbienzms / iot-devices

Helper library for interfacing with devices in IoT projects.
45 stars 17 forks source link

Planning #6

Closed mjmeans closed 7 years ago

mjmeans commented 8 years ago

I wish there was a way to create this as a "discussion" not an "issue". Anyway ...

I was thinking again about the Pwm implementation while working on my Adafruit stepper motor HAT library. And it occurred to me that in the namespace could ultimately will be an IPwmControllerProvider class for each kind of PWM, one connected through I2C, one for those connected through SPI, one for those connected though GPIO, and possibly one for those connected to the RXD/TXD pins. There could also be an IPwmProvider class for the default PWM controller in the Raspberry Pi 2/3, one for the default PWM controller on minnow board or beagle or whatever, and one for each HAT or other add-on device. Each board or device IPwnProvider implementation would call the appropriate IPwmControllerProvider implementation. Of course this makes the library more complex.

If the classes were more strictly implemented does all that complexity help .NET native tool chain optimize the compilation to only included those classes that are necessary? Does that complexity help the implementation of an actual driver that can be automatically loaded in the BSP or loaded upon the boot process reading the HAT's ID EEPROM? Does Windows IoT even read the HAT ID EEPROM so that this may be possible? And how does this implementation choice affect interoperability between the native controller driver and the lightning controller driver.

I’m not trying to lobby for separate classes. I just want to explore the cost/benefit analysis of single versus separate classes so we can develop some guidelines to indicate at which point (if any) where separate classes and a more complex implementation may be desirable. And if it is a foreseeable plan, how to road map it so that it is the least problematic for existing users updating their code in the future.

Mark

jbienzms commented 7 years ago

Thank you for the "thinking out loud" here Mark. Since we haven't changed the architecture and since this is showing up as an open issue, I'm going to close it. We can still find these notes later under closed issues.