![]() |
![]() |
![]() |
![]() |
![]() |
The I2C Device Library is a collection of uniform and well-documented classes to provide simple and intuitive interfaces to an ever-growing collection of I2C devices. Each device is built to make use of the generic i2cdev code, which abstracts the I2C bit-level and byte-level communication away from each specific device class, making it easy to keep the device code clean while providing a simple way to modify just one class to port the I2C communication code onto different platforms (Arduino, PIC, simple bit-banging, etc.).
The I2Cdev code is built to be used statically, reducing the memory requirement if you have multiple I2C devices in your project. Only one instance of the I2Cdev class is required. For pure C or otherwise non-object-oriented platforms, a simple procedural version of the library is currently under development.
The I2Cdevlib site is built around a core database of detailed register maps for each supported device. This information is used not only for direct reference for site visitors, but also for intelligent traffic analyzing and automatic multi-platform code generation. Register map definitions include addresses, register names and descriptions, access mode (read/write), bitfield names and definitions, and detailed specific values, if specified in the available documentation. You will not find a more comprehensive dynamic collection of I2C device data anywhere.
Based on a sufficiently detailed register map for a given device, the I2Cdevlib site infrastruction can generate functional device management code automatically, complete with documentation, address constants, bitfield access, and even example code.
Detailed documentation for all code is created using Doxygen-style comments placed in each class definition file, based on the information available in each device's register map. Since most of the code—the tedious part, anyway—is generated automatically based on register map data, This means there is a huge quantity of relevant documentation available to you right in the code itself, which saves a lot of time if you have an IDE with code completion.
Want support for a device that isn't currently in the library? Request it, or fork the code and contribute! Better yet, send me a device on a breakout board to test the code during development. No guarantees on how fast I can get it done, but I'd love to make this the biggest consistent and well-documented I2C device library around.