adafruit / Adafruit_SSD1306

Arduino library for SSD1306 monochrome 128x64 and 128x32 OLEDs
http://www.adafruit.com/category/63_98
Other
1.75k stars 964 forks source link

Where to discuss potential enhancements? #180

Open richhas opened 3 years ago

richhas commented 3 years ago

Is this a forum to discuss a potential enhancements (that I'm more than willing to do) to this library? Or is there a place for in the adafruit fourm for such a thing. Me: a newbie to adafruit github practice.

Thanks,

Rich

ladyada commented 3 years ago

here is fine, be aware that we wont merge enhancements that are hard to support or are specialized

richhas commented 3 years ago

Here's what I'm thinking about... We refactor SSD1306 into a more abstract base class that is not bound to the specifics of a given I2C or SPI implementation but keeps ALL of the common imp... And then turn the existing class into a simple derivation that supplies the standard Wire and SPI logic as is. A "driver" imp if you will.

Where I'm headed with this is being able to have a different I2C (or SPI) "driver" derivations - In my case I want to use I2C_DMAC (our something like it) for very friendly multi-threadable (multi-bus) use case.

Make sense? I'm more than willing to do the work on this if you guys agree - 100% back compat promised!

Thanks,

Rich

ladyada commented 3 years ago

we already have base class you can use here https://github.com/adafruit/Adafruit-GFX-Library/blob/master/Adafruit_MonoOLED.cpp that has some niceties like dirty window tracking. you can refactor this library with that, however, any I2C DMA should be handled at a lower level by your Wire library

richhas commented 3 years ago

To be clear you could be saying that 1) make SSD_1306 a derivation of MonoOLED, and 2) adding ctor overloads that could take in an Adafruit_I2CDevice instance which in turn (after making a bit more generic) could implement another form of I2C that's not TwoWire (e.g.DMA).

Just want to make sure I'm understanding and on the same page.

Thanks,

Rich

ladyada commented 3 years ago

yes SSD1306 would be subclassed, like we did here https://github.com/adafruit/Adafruit_SH110x

any DMA stuff should be handled in your board support package Wire implementation (or a subclass thereof) becuase it is extremely port-specific

richhas commented 3 years ago

I would love to understand your arch intent wrt the Adafruit*Device work. It would, imho, be a great advantage if those types truly abstracted I2C /SPI imps so the existing TwoWire and SPI concrete imps were not so hardwired everywhere. Any background thinking / intent you could share wrt your Adafruit*Device work would be greatly appreciated.

And back to your isolation concerns... Any specific behavior like an i2c-dma library dependency (e.g. I2CDMAC) should be down under the Adafruit*Device abstraction...

Thanks,

Rich

ladyada commented 3 years ago

BusIO just calls underlying Wire library as a nice wrapper for register management - that is not where DMA should occur & we wont probably would not accept DMA changes to BusIO library.

mzero commented 3 years ago

of relevance would be my pull request #165 - which pulls most the SPI and I2C code into one place in the implementation. This well might make an easier jumping off point for refactoring.