Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where to discuss potential enhancements? #180

Open
richhas opened this issue Aug 10, 2020 · 8 comments
Open

Where to discuss potential enhancements? #180

richhas opened this issue Aug 10, 2020 · 8 comments

Comments

@richhas
Copy link

richhas commented Aug 10, 2020

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
Copy link
Member

ladyada commented Aug 10, 2020

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

@richhas
Copy link
Author

richhas commented Aug 10, 2020

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
Copy link
Member

ladyada commented Aug 10, 2020

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
Copy link
Author

richhas commented Aug 10, 2020

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
Copy link
Member

ladyada commented Aug 10, 2020

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
Copy link
Author

richhas commented Aug 11, 2020

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. I2C_DMAC) should be down under the Adafruit_*Device abstraction...

Thanks,

Rich

@ladyada
Copy link
Member

ladyada commented Aug 11, 2020

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
Copy link
Contributor

mzero commented Oct 31, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants