IoT-devices constantly promote the use of I2C bus as one of the best serial digital interfaces.
The I2C bus offers all the necessary functions:
- a simple physical interface: the SDA data and SCL synchronisation signals require only two wires to connect to the bus;
- the addressing of devices on the bus with unique 7-bit addresses;
- the identification of devices on the bus by their address or by unique identifiers (if provided by the chip manufacturer);
- hot device plugging / unplugging like Plug & Play;
- the unit is powered by the bus or by each module’s own power supply;
- the support for different supply voltages of devices on the bus (provided that the signals are matched to the voltage level);
- an advanced infrastructure of amplifiers, repeaters, splitters and multiplexers to build complex topologies offered by chip manufacturers;
All that allows about a hundred devices to be connected to the controller on a single interface at the same time. The I/O port budget of the main controller is minimal when the I2C bus is used to connect the sensors.
Sensors or actuators might be on an extension cord, or all the chips might be concentrated on one module.
The main controller and slave units might be powered independently, or all devices on the bus might be powered by a single source.
The I2C is supported by the vast majority of microelectronics manufacturers. All popular controllers, IoT / Smart Home platforms, and related development environments are compatible with the bus.
Most IoT-devices’ products support I2C as a basic interface. Moreover, the support of the I2C bus is usually a decisive factor when choosing chips for our projects. But any system has not only advantages. There are also deficiencies and hidden problems, which we reveal in our publications.
Today we would like to talk about the software problem of choosing the right hardware sensors with I2C bus support. We will not go into the theory, but rather suggest a practical example using our devices.
Let’s start with the popular radiation sensor module GGreg20.
Example №1. GGreg20 і I2C
From time to time we are asked if it would be better to equip the GGreg20 module with I2C interface and offer such a product as an alternative to the pulse output product that GGreg20_V3 currently is.
In short, no. Let’s try to justify our opinion in more detail.
We really like the I2C bus. We, moreover, already have an I2C interface splitter module, I2CHUB, which would be well suited to a hypothetical GGreg20 with I2C interface. So we can take a budget microcontroller – a companion like STM32, which must perform the necessary pulse calculations and give calculated values of the power and dose of ionizing radiation to the main controller at a low level via I2C interface.
But let’s ask ourselves how many common and very popular IoT platforms and microcontrollers will have driver support for such an I2C sensor? The answer will be disappointing, since it is not an industrial sensor with a huge sales market.
Certainly, our company needs everyone to be able to connect our sensors. It is our customers who must choose the type of controller or platform. We need to provide versatility for Arduino, ESP32 / ESP8266, Raspberry Pi, or for NodeMCU, Node-RED and ESPHome in Home Assistant, and many other IoT development environments that we might not have even heard of.
GGreg20 is now supported by any controller, development environment and IoT platform, precisely because it has a versatile pulse output. If we equipped the GGreg20 with an I2C interface, we would have a completely different result.
Note. What if we make two interfaces at once on the GGreg20 module: pulse output and I2C? This would be very convenient, but the clients’ costs increase unnecessarily in that case. The companion controller occupies a certain area on the module board. The I2C bus occupies twice as many controller ports as the pulse output. All that adds significantly to the unit price. On the other hand, the pulse counting output interface takes up only one controller GPIO with an interrupt handler and is much easier to code. The current version of the GGreg20 module can work without a controller at all: a user can use a watch to monitor the duration of the radiation measurement and count led blinks manually.
We will next consider another example of two similar devices. They both have an I2C interface, but different application perspectives.
Example №2. I2CUI3, I2CUI4 та I2C
First, we developed I2CUI3, a useful and reliable product. It is a versatile module with I2C bus support for building user interfaces. It provides input of control actions using five navigation buttons and data output to an RGB LED and a buzzer about the end-user device status or events.
It is based on the 8-bit NXP PCA9538 port expander. For many years we have been using this chip for various tasks, including as the main component of the I2CUI3 module. The PCA9538 port expander is convenient because it works semi-automatically after power-up, and does not require any pre-programming for some tasks, so it can work even without the main microcontroller.
And then it became clear that we need not 8-bit, but 16-bit similar module for certain tasks. So we created a new product with an I2C interface – I2CUI4 module based on the MCP23017 port expander chip.
We could use NXP’s top-of-the-range expander for the new I2CUI4. They have several 16-bit expander chips like PCA6416, PCA9539, PCA9575, PCA9673. But there are no official libraries for any of the chips either on arduino.cc or esphome.io. There are no drivers for NodeMCU firmware either. There are only a few libraries for PCA9539 on Github, but neither Adafruit nor Seeed Studio have drivers for any NXP chip.
That is why the new product I2CUI4 is compatible with common platforms and has probably the most popular chip MCP23017 from Microchip Technology with I2C interface.
Thanks to that, our MCP23017-based product can boast a wide range of support by Arduino, NodeMCU, ESPHome / Home Assistant, Node-RED, Blynk, MicroPython, Raspberry Pi, STM32, and other brands. GitHub has hundreds of repositories with drivers in C / C ++, Python, JS, Lua, and other languages.
We gave two examples of identifying and solving the problem of driver support for devices equipped with an I2C interface from our own experience.
Unless you plan to provide on your own driver support for an I2C device you are about to buy, please pay attention to the hidden external risks described in this publication. You should choose a device, module, or chip with an I2C interface, which, in addition to other factors, will have the widest driver support among third-party systems.
Special attention concerning compatibility and support should be given to the target microcontrollers, platforms, development environments. You have to be sure that all of these systems will support your chip before using it in your designs.
We have used these principles to develop two excellent products, GGreg20 and I2CUI4, to minimize the risks and avoid the problems mentioned above.
We hope you find this material useful.
Thank you for your attention.