If you would like to contribute to the I2C Device Library, it's not too hard. There's a set of stub device files that you can use to create your own devices up on the GitHub repository. It's easy to get started:

  1. Fork the I2Cdevlib repository on GitHub.
  2. Copy the stub files or a functionally similar device class to a new device folder and modify them to fit the specifications of your new device.
  3. Send a pull request to get your new code merged back into the master branch.

If you can't or don't want to use GitHub, you can just let me know about your contribution and I can incorporate the updates by hand.

Contributing Changes to Existing Device Classes

It isn't just new device libraries that I'm looking for; if you see some broken or missing functionality that you can fix or add to a device class that's already in the library, by all means feel free to contribute those changes as well. Bug fixes, missing documentation, updated features, and useful convenience functions are all welcome.

Code Conventions

There are a few conventions in place to help keep all of the device libraries as consistent as possible. Here's a current list:

  1. All code is placed under the MIT license.
  2. The device class name should be the same as the device model if at all possible. No spaces or hyphens, and ideally no underlines unless they're absolutely necessary for clarity. ALL CAPS for model numbers, or FirstInitial caps for full names. For example:
    • ADXL345
    • MPU6050
    • TCA6424A
    • PanelPilot
  3. All #defines should use a device-specific prefix that is the same as the all-caps version of the class name ("MYDEVSTUB_" in this example).
  4. All #defines should be ALL CAPS, no matter what. This makes them clearly distinctive from variables, classes, and functions.
  5. Class methods and member variables should be named using camelCaps.
  6. Every device class should contain an "initialize()" method which takes no parameters and resets any important settings back to a known state, ideally the defaults outlined in the datasheet. Some devices have a RESET command available, which may be suitable. Some devices may not require any specific initialization, but an empty method should be created for consistency anyway.
  7. Every device class should contain a "testConnection()" method which returns TRUE if the device appears to be connected, or FALSE otherwise. If a known ID register or device code is available, check for that. Since such an ID register is not always available, at least check to make sure that an I2C read may be performed on a specific register and that data does actually come back (the I2Cdev class returns a "bytes read" value for all read operations).
  8. All class methods should be documented with useful information in Doxygen format. You can take the info right out of the datasheet if you want to, since that's likely to be helpful. Writing your own info is fine as well. The goal is to have enough clear documentation right in the code that someone can determine how the device works by studying the code alone.