Alternate I2C/TWI library or library abstraction layer

[commodoretim]

Hello Rob,

Thank you for your ADS1X15 library! Your work helped me test the performance of the ADS1015 and confirm that it will work well for my needs.

My organization has an existing ATmega328P (AVR) codebase with a custom I2C library, and I needed to add ADS1015 support to our application. The MIT licensing of your library could work for us. We couldn't use the underlying Arduino or Wire (TwoWire) libraries, though.

Are you aware of alternate I2C libraries with MIT or BSD or similar licensing that implement the same interface as the Wire library, so that your ADS1X15 library could operate unmodified? My searches weren't fruitful.

Is there a possibility of abstracting the I2C access so that the user of the library could provide their own adapter between the available I2C library and your ADS1X15 library? This idea is inspired by how the U8g2 display library can be ported to new platforms. (This worked very well for me just recently.)

Is the idea of forking your library and replacing the Wire function calls with similar calls into my custom I2C library sensible? The fork would be publicly accessible as is your library. It would have function calls into my private I2C library, though, and therefore wouldn't be useful to others.

Is the best approach for me to write my own ADS1015 library upon my custom I2C library? While this likely would require the most time investment, the questions surrounding licensing would be simpler.

Thank you for your work and your ideas/suggestions!

Gratefully, Tim Mason

[RobTillaart]

First thing that pops in my mind is a Software I2C implementation I used for SHT31_SW and SHT31_SWW.

Have a look if there is a solution in those sw i2c libs used.

[RobTillaart]

Will try to come back to these questions tomorrow.

[commodoretim]

Thank you for your quick response earlier today. Much appreciated!

Interesting idea about the software I2C implementations. The licenses for SoftWire and SoftwareWire won't work for my organization, though.

An idea is coming to mind about a simple abstraction layer that would allow separating the I2C communications from the ADS1X15 logic. Perhaps I may have functional code to present Monday or Tuesday next week for your evaluation.

In the meantime, I look forward to any additional ideas you have. Thank you again for your efforts!

[RobTillaart]

@commodoretim

Have you seen this discussion - https://arduino.stackexchange.com/questions/11689/alternatives-to-wire-library-for-i2c

it has some dead links and some possibly interesting

• https://github.com/mikaelpatel/Arduino-TWI/tree/master
• https://github.com/SMFSW/WireWrapper

[commodoretim]

Thank you for your research! You found some great resources. My search results weren't quite that good.

The ideal scenario for me would be a wrapper that's the inverse of WireWrapper. It would wrap around my custom I2C library and provide an interface similar to that of Wire, which in turn would be available for use by device libraries such as your ADS1X15 library.

The question though is whether mimicking even a portion of the interface of Wire, but not the implementation, would constitute copyright infringement or require adoption of the license terms of Wire? I'll seek to talk with my teammates on Monday for further advice, and am open to other input you may have.

Likely the best path forward for me is to write my own simple device library for the ADS1015, built on top of my custom I2C library. Good news is that my needs are basic: don't need differential inputs and don't need continuous conversion mode.

[RobTillaart]

To know the details of copyright one should ask lawyers, they have a sort of "parallel universe with other laws / logic".

To be sure you best use your own (generic) names for functions. A minimal interface (master only) could look like this

class I2C_master
{
  I2C_master(uint8_t SDA, uint8_t SCL);  //  constructor, pins might be optional
  begin(uint32_t speed);
  send(uint8_t * bytes);
  request(uint8_t address, uint8_t bytes);
  receive(uint8_t * bytes);
}

[commodoretim]

Yes, legal matters and copyright and licensing can be complex.

Monday and Tuesday I proceeded forward with writing a simple device library based upon the I2C library I wrote years ago. Diving into datasheets is honestly enjoyable and GitHub Copilot gave me amazingly helpful code completion recommendations.

Today I've been working on integrating my simple device library into my application and diagnosing the latest revision of the PCB made by my teammates, but that's another matter.

You're welcome to close this issue if you like. Thank you so much for your expertise and advice.

[RobTillaart]

Feel free to reopen if needed