We have a main system controller and several devices with an I2C interface that need to be connected to it. The figure shows an approximate classic set of modules that may need to be connected to the main controller (MCU).

Fig. Various I2C Modules Example

Most microcontrollers (MCUs) are miniature devices and have a very limited budget for free I / O ports. Typically, on Arduino / ESP8266 / ESP32 / STM32 controllers, only one interface can be reserved for the I2C bus (even if there are two) – two GPIO ports for SDA and SCL signal channels.

There are at least two reasons for this.

First , GPIO ports are a valuable resource on the main controller. They are involved in no less important external interfaces – UART, SPI, Deep Sleep Wakeup, sub-button inputs, actuator outputs (s), etc.

Secondly , the design of the main controller module board must take into account the size limitations: the more connectors installed on this board, the greater the linear dimensions it will have.

Note . We also know that the I2C serial bus can be implemented not only in hardware, with fixed I / O ports on the MCU, but also in software, when the bus signal lines can be assigned to any MCU’s GPIO ports. Moreover, the software implementation of the bus allows to declare multiple I2C software buses with different Bus_ID.

Fig. MCU I2C bus hardware and software implementations

But the manifestation of several I2C software buses simultaneously within one MCU reduces the number of free pins for other tasks. Because of this, such opportunities are rarely used. Exceptions to this may be situations when such a technique avoids problems that cannot be solved in any other way. For example, addressing collisions (two different devices with the same 7-bit address) and similar problems. But even for such problems, it is more efficient to use an I2C hardware multiplexer than multiple I2C software buses.

Problem solution

To solve the problem of one I2C port on the MCU, the hardware I2C bus interface splitter is most often used. It is a passive hub that splits one existing I2C interface into the required number of the same interfaces.

There are many similar devices on the market, but we will give an example of a device of our own production – I2CHUB_V1 , which has 6 I2C ports: 3 x 4 pin JST HX2.54, 3 x 4 pin Dupont and two additional dedicated “bidirectional” 2 pin power ports.

Fig. I2C bus interface splitter – I2CHUB_V1 as an example

Another way to solve the problem in the case of a bus-type serial interface, such as I2C, may be to use predefined end-to-end interfaces in individual sensor modules or actuators that connect to the bus.

Fig. Not widespread In-Out (two-connector) I2C sensor modules connection example

The “input” interface of each such module is connected to the MCU or the previous sensor module on the bus, and the “output” interface allows you to cascade the next module. Some manufacturers provide two I2C bus interfaces for this purpose. But, unfortunately, most modules are not equipped with such capabilities. Therefore, we consider I2C HUB as a more common and universal approach. Below you will find the basic schemes for modules connection with use of the hub.

Note . As the number of connections increases, it exponentially increases:
– number of failure points (PoF, Point of Failure);
– the risk of human error when making interface signal connections.

For the protection of equipment from failure and installation errors, in order to increase the overall reliability of the system, we recommend:

• to use connectors with a safety key as often as possible;
• to use modules with mutually compatible electrical interfaces and physical connectors.

While we recommend using key connectors whenever possible, we also try to take into account the realities of the electronic components market and meet the needs of consumers. That’s why we’ve given the I2CHUB_V1 splitter the ability to act as a type connector converter from JST to Dupont and vice versa.

We consider this a very useful feature, because thanks to the ability of freely reversing JST – Dupont interface cables from one side to the other, the user can connect almost any existing I2C interface modules to the hub. Also, the user is free to use their own Dupont – Dupont pin cables.
For the ” Order with cables ” option in the module I2CHUB_V1 connectors are always soldered in the same way: half of them are 2.54 mm JST connectors (with key), the other half are Dupont pin connectors. This is done to ensure the above-mentioned flexibility of interconnection of various I2C modules.

Schemes of modular connection to the interface splitter

Star

The most common scheme is when all modules are connected to the divider by I2C interfaces. Let’s call her “Star”.

Fig. “The Star” module connection example

Cascading

The next topology is a cascade of two or more “Stars”. Let’s call it “Cascading”.

Fig. “Cascading” module connection example

Because one of the interface splitter ports is always used as an “input”, there may be a lack of free splitter ports in some situations. In this case, the necessary number of splitters is cascaded to provide the desired number of interface ports on the I2C bus.

For example, IoT-devices I2CHUB_V1 has 6 I2C ports. If it is planned to connect more than 5 slave devices to MCU in the project, it is possible to apply cascading of two splitters and distribute the corresponding slave devices between their interfaces.

Long line

The last possible implementation scheme to be included in this publication is a topology with a long data line and two remote independent sources of power. Let’s call it “Long Line”.

Fig. “Long line” connection with remote power source example

In this scheme, only three signal lines are used, while the power for the devices comes from a local, independent source on each side. This arrangement allows a relatively long data line to be organized on the I2C serial bus interface without the use of special bus repeaters / amplifiers.

Compatibility of splitters with other systems

If you use modules with different supply voltages in one project, you should pay special attention to the signal matching of such components. But if you choose to apply a passive splitter that has no conversion or voltage leveling elements just take into consideration that the voltage that you apply to the splitter connectors will reach all the modules connected to the splitter via the respective I2C bus signaling lines.

However, since the classical I2C splitter (such as I2CHUB_V1) is a passive device and does not change the voltage level, it is automatically compatible with any controller you choose to connect it to: Arduino, STM32, ESP8266, ESP32, Raspberry Pi, etc.

Warning! Only you decide which logical levels the components of the project should work with: 1.8V, 3.3V or 5V.

Detailed I2C bus specifications

To view details of all I2C bus features, we recommend reading the official guidelines and specs here: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
As well as other resources on the Internet.

That’s all we planned to tell in this publication. We have considered the features and connectivity of the slave modules to the I2C bus interface of the main controller. We have also shown the main application patterns of the splitter, such as Star, Cascading, Long Line, with the possibility of remote independent powering of individual bus chunks, thanks to the special power “input/output” ports in the splitter.

Thank you for your attention. Ask questions on our social networks.
Good luck!

Indeed, why not add such a convenient interface to the module? Here is our next article where we discuss the advantages and disadvantages of equipping the GGreg20_V3 ionizing radiation detector module with an I2C interface.

Note that we really like the I2C serial bus for its simplicity, functionality, and reliability. You can check out our other publications where we look at this great bus:
Як правильно вибрати I2C чіпи. Або про приховану програмну проблему вибору
апаратних модулів / How to choose the right I2C chips. Or the hidden software problem of
choosing hardware modules

Application of I2C bus interface splitter

However, our goal in developing GGreg20_V3 was, and still is, to ensure that our product is as compatible as possible with various systems.

Take a look at this:

(1) If any module or chip has an I2C (or SPI, UART) communication interface, this automatically requires a low-level driver-connector to be written for that device.

(2) Also, such a device cannot be integrated with other components that do not support a specific communication or control interface such as I2C. There are many projects that do not have I2C, or there are not enough free GPIOs for the I2C bus.

(3) The radiation measurement module, under certain conditions, should be capable of being used in the field, without connection to the main controller. The user should be able to use such a device regardless of the conditions in which he finds himself. Without programming or hardware rework.

(4) Equipping the module with an I2C interface requires an embedded controller-companion on the module, which provides data preparation for the consumer and data exchange in Slave Device mode in accordance with the I2C specification. Although it can be a common and inexpensive controller, its presence increases both the price and size of the module. It is also necessary to allocate additional space on the module board for the address selection pads.

(5) A module with an I2C interface requires a main controller and display so that the module can be used for its intended purpose. This is despite the fact that the module already has an embedded controller-companion. The main controllers are very different. Some use Raspberry Pi, or Arduino, and some want to be able to use ESP32/ESP8266. That’s why we don’t put the main controller on the GGreg20 module board. We believe that the user has the right to choose the controller, platform or development environment independently. And our task is to ensure the widest possible compatibility and versatility of our product.

From an electrical point of view, equipping devices in this category with an I2C interface also has no advantages, since both the power and data interface in the I2C variant and the GGreg20_V3 pulse output variant require the same number of signal wires in the loop. Hot-swapping, supported by the I2C bus, is also hardly desirable for this type of module, not to mention the mandatory presence of this function.

In Fig. Here are schematic images of two modules – the current version of GGreg20 without I2C, and the version with I2C interface to show how much you would have to change the module to the actual size (10×10 mm) of the additional chip integrated controller-companion.

Fig. If GGreg20_V3 had an I2C interface (the built-in companion controller providing the I2C Slave Device mode is shown in red))

The only advantages to justify equipping our radiation module with an I2C interface are:

• the ability to connect multiple devices to the I2C interface of the main controller;
• calculation of user values by means of the built-in controller-companion.

But if you carefully weigh the potential benefits and the very specific losses of implementing I2C in a given device, it becomes obvious that it is better to have a universal module with extensive driver support and the ability to use it in “manual” mode than to have a tones of I2C bus advantages that you need to be able to use.

In addition to the above, here are two key problems we would like to highlight for potential users. GGreg20_V3 does not have these problems, but they are bound to occur (in some variations) in the radiation measurement module with the I2C interface:

Problem # 1 Field conditions / Emergency situation

Consider this situation: you have a radiation sensor in a drawer waiting for you to finally start programming it, and the next moment you need to leave the house as quickly as possible with one backpack in your hands and, perhaps, start measuring the level of radiation as soon as possible, because a situation of natural or man-made disaster has come, and you are near the epicenter of these events.

We in Ukraine are very familiar with such circumstances, and we take into account the experience accumulated in the most difficult times for the country to make the system design of our products as good as possible.

Our GGreg20_V3 module only needs to be powered by a powerbank (or even a few AA/AAA batteries), or a solar panel and that’s it: you can measure manually by LED flashes and a stopwatch or your own countdown.

The number of flashes per minute, multiplied by the conversion factor, is the radiation level in μSv/h.

The conversion factor for the SBM20 GM-tube is 0.0054. Thus, we have a simple formula:

CPM x 0.0054 = mkSv / hour.

where CPM is the number of flashes per minute ( Counts per Minute ).

For Kyiv[20 – 48] flashes is a normal level (0.10 – 0.26 mkSv / h).

Unlike the GGreg20_V3, a module with an I2C interface will be very difficult to use in the field for its intended purpose. After all, such a module requires a main controller, display, programming tools, software code development and special knowledge and skills to interconnect the required components and program them. This means that the average user without specialist knowledge will not be able to make a measurement with an I2C sensor, even if he happens to have the available tools in his kit.

Problem # 2 Driver support

Even if the surrounding circumstances are fine and the radiation sensor module is operated in a civilization, there are still problems with the design option of the module having an I2C interface. Problems arise for users who want to use their favorite systems / platforms / environments / architectures for IoT development.

There are many systems and user favors, but even the most advanced and popular systems do not have drivers for all the devices that consumers usually buy and try to connect.

Due to the heterogeneity of integration protocols, sometimes you have to write a driver yourself, or wait several years for the system developers to pay attention to this particular commercial device and develop an appropriate driver connector.

Here is a comparison table of common platforms with built-in I2C support for radiation sensors and platforms with GPIO pulse counter support, so that the reader can understand the extent of the problem.

This data indicates very eloquently that a sensor with a pulse output, such as the GGreg20_V3, is much easier to connect to any platform, or to use the module stand-alone, if necessary.

Of course, each I2C module usually has its own libraries developed by the manufacturer or by concerned members of the open source software community. For example, the GGreg20_V3 module has several libraries for popular platforms:

Note. While every modern IoT platform typically provides I2C bus support, there must also be a driver for each specific hardware module (manufacturer, model, version). Support must be both on the platform side and on the side of the controller to which the module is connected.

Having libraries like the ones in the table is already a good thing. But this does not give any guarantee that these libraries are supported by their authors and are up-to-date, and also that the user will find such a library for his favorite platform and will be able to integrate it and program the end device.

In the case of the pulse counter on the GPIO, the situation is completely different: all platforms support this function and are very easy to program.

In lieu of conclusion.

Despite the obvious advantages of the I2C bus, if in the future we decide to add I2C support to the GGreg20 module, it will be another, alternative device with these capabilities. And consumers will be able to choose which option suits them best.

Buy a GGreg20_V3 ionizing radiation detector with pulse output.

We wish you success!

1. General overview. This is a panel that can be mounted on the wall of the case to control the device. A joystick is installed for control. An RGB LED is installed to indicate the status of the device and audio signals are output to the buzzer. Interaction with the controller via the I2C digital interface; The module will be convenient to use in many custom projects based on ESP8266 or Arduino. The panel also has a connector with an I2C interface to make it easy to connect external devices – such as a digital thermometer.

2. You may like this module as follows solutions :

• During the design of one of our devices, the task was to place five buttons in a “tight” case. Accidentally found joystick prompted us to this elegant solution, which in practice did not disappoint us. So, instead of traditional buttons on I2CUI1 the compact joystick which in the case of the clock button unites 5 buttons (left, right, up, down, OK) is established;
• The GPIO PCA9538 expander mounted on the board solves two tasks – convenient removal (for example, if necessary to install on the walls of the case) of the panel from the main controller with a compact two-wire bus I2c and simultaneously installed popular control and indication components;
• A wide range of supply voltage allows to integrate the module in systems on ESP8266 and Arduino;
• Hardware protection against “rattle” of joystick contacts;
• Installed on the module buzzer is connected by a separate bus to the GPIO controller, because all the ports of the expander are occupied by the LED and the joystick. At first glance, this is a disadvantage, but in our experience, buzzer must be able to control the software (volume, sound effects). If the buzzer was connected to the GPIO of the expander, only software on / off would be available, because the PCA9538 port expander does not support the PWM mode required for control;
• The INT bus is activated each time the joystick is pressed and initiates a software interrupt to handle the joystick states;
• Compactness and quality of workmanship.

3. Example of application of the module .

In a few minutes we made the thermostat, using:

Of course, the thermostat requires the development of original software.

We will be grateful for the support of our page at and purchase of goods in our store. iot-devices.com.ua

The I2C bus offers all the necessary functions:

• a simple physical interface: the SDA data and SCL synchronization signals require only two wires to connect to the bus;

• the addressing of devices on the bus with unique 7-bit addresses;
• 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. Or all chips can be focused on one module.

The master controller and slave devices can be powered independently. Or all devices on the bus can be powered from a common 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 support the I2C interface as basic. Moreover, the support of the I2C bus is usually a decisive factor in the selection of chips in our projects. But any system has not only advantages. There are also shortcomings and hidden problems that we reveal in the 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 and I2C GGreg20 and I2C

From time to time we are asked if it would be better to equip the GGreg20 module with the I2C interface and offer such a product as an alternative to the product with a pulse output, which is now GGreg20_V3.

In short, no. Let’s try to justify our opinion in more detail. 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.

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 you make two interfaces on the GGreg20 module at once – pulse output and I2C? It would be very convenient, but in this case we believe that these costs at the expense of customers would be unjustified. The companion controller occupies a certain area on the module board. The I2C bus takes up twice as many controller ports as the pulse output. All this significantly increases the unit cost of the product. While the Pulse interface takes up only one GPIO controller with an interrupt handler and is much easier to program. And if we talk about maximum simplification, the GGreg20 module can work without a controller at all. The user can measure radiation (in circumstances that require it) only with a clock to record the measurement time in minutes.

We will next consider another example of two similar devices. They both have an I2C interface, but different application perspectives.

Example №2. I2CUI3, I2CUI4 and I2C

We first developed I2CUI3 – a useful and reliable product. It is a universal module of user interfaces with the I2C interface, which provides input of user instructions with the help of five navigation buttons and output of data to the RGB LED and the bazaar about the status or events of the IoT device. 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, as it works semi-automatically after power supply and for some tasks does not require pre-programming at all, and therefore 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.

For the new I2CUI4, we could use NXP’s older expander in the line. 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 the arduino.cc site or on the esphome.io site. There are also no drivers for the NodeMCU firmware.

There are only a few libraries for PCA9539 on Github, but neither Adafruit nor Seeed Studio has 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.

Conclusion

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.