“IoT-devices” повсякчасно просуває застосування шини I2C, як одного з найкращих послідовних цифрових інтерфейсів.

Шина I2C пропонує всі необхідні функції:

• простоту фізичного інтерфейсу: сигнали даних SDA та синхронізації SCL потребують лише два дроти для підключення до шини;

• адресацію пристроїв на шині унікальними 7-ми бітними адресами;
• ідентифікацію пристроїв на шині за їх адресою чи за унікальними ідентифікаторами (якщо такі передбачено виробником чіпів);
• можливість “гарячого” підключення / відключення пристроїв на кшталт “Plug & Play”;
• живлення пристрою від шини або від власного джерела кожного модуля;
• підтримку різних напруг живлення пристроїв на шині (за умови узгодження сигналів за рівнем напруги);
• розвинену інфраструктуру з підсилювачів, повторювачів, поділювачів та мультиплексорів для побудови складних топологій, що пропонують виробники чіпів;

Все це дає змогу одночасно підключати до контролера близько ста пристроїв на одному інтерфейсі. Бюджет портів вводу-виводу головного контролера мінімальний, коли шина I2C використовується для підключення сенсорів.

Сенсори чи виконавчі механізми можуть бути виносними на дроті. Або всі чіпи можуть бути зосередженими на одному модулі.

Головний контролер та підпорядковані пристрої можуть мати незалежне живлення. Або всі пристрої на шині можуть живитися від спільного джерела.

Шину I2C підтримує абсолютна більшість виробників мікроелектроніки. З шиною сумісні всі популярні контролери, платформи ІоТ / Smart Home та відповідні середовища розробки.

Більшість пристроїв виробництва IoT-devices підтримують інтерфейс I2C як базовий. Ба більше, підтримка шини I2C є, зазвичай, вирішальним фактором під час вибору мікросхем до складу наших проектів. Але будь-яка система має не лише переваги. Є і недоліки та приховані проблеми, які ми розкриваємо у публікаціях.

Сьогодні ми б хотіли поговорити про програмну проблему правильного вибору апаратних сенсорів з підтримкою шини I2C. Ми не будемо вдаватися в теорію, а пропонуємо розглянути суто практичний приклад на наших пристроях.

Почнемо з популярного модуля сенсора радіації GGreg20. 

Приклад №1. GGreg20 і I2C

Час від часу нас запитують, чи не краще було б обладнати модуль GGreg20 інтерфейсом I2C і пропонувати такий продукт, як альтернативу продукту з імпульсним виходом, яким зараз є GGreg20_V3.

Якщо коротко, то ні, не варто. Спробуємо обгрунтувати свою думку розлого. 

Нам дуже подобається шина I2C. Тим більше, у нас вже є модуль поділювача інтерфейсів послідовної шини  I2CHUB, до якого б гарно пасував гіпотетичний GGreg20 з інтерфейсом I2C. Тож ми могли б взяти бюджетний мікроконтролер – компаньйон типу STM32, який мав би на низькому рівні виконувати необхідні розрахунки імпульсів і надавати готові значення потужності та дози іонізуючого випромінювання головному контролеру через інтерфейс I2C. 

Але тепер давайте себе запитаємо, скільки поширених і дуже популярних ІоТ платформ та мікроконтролерів матимуть драйверну підтримку для такого I2C-сенсора?

Відповідь буде невтішною, оскільки це не промисловий сенсор з ринком у десятки мільйонів штук на рік.

Вочевидь, нам у IoT-devices потрібно, щоб наш сенсор мали змогу підключити всі бажаючі. Контролер чи платформу мають обирати саме вони – наші клієнти. Ми ж маємо забезпечити універсальність як для Arduino, ESP32 / ESP8266 чи то Raspberry Pi, так і для NodeMCU, Node-RED чи ESPHome у Home Assistant, та багатьох інших засобів побудови ІоТ, про які ми могли навіть не чути.

Зараз GGreg20 підтримується будь-яким контролером, середовищем розробки та IoT-платформою саме тому, що у нього є універсальний імпульсний вихід. Якби ми оснастили GGreg20 інтерфейсом I2C, ми мали б зовсім інший результат.

Примітка. Що якщо зробити одразу два інтерфейси на модулі GGreg20 –  імпульсний вихід та I2C? Було б дуже зручно, але в даному випадку вважаємо, що ці витрати за рахунок клієнтів були б невиправданими. Контролер – компаньйон займає певну площу  на платі модуля. Шина I2C займає вдвічі більше портів контролера, ніж імпульсний вихід. Все це значно збільшує вартість одиниці продукту. В той час як Імпульсний інтерфейс займає лише один GPIO контролера з обробником переривань і програмується значно простіше. Та й якщо говорити про максимальне спрощення, модуль GGreg20 може працювати без контролера взагалі. Користувач може вимірювати радіацію (в обставинах що цього вимагають) лише з годинником, щоб засікти час вимірювання по хвилинах.

Далі розглянемо ще один приклад двох подібних пристроїв. Обидва з інтерфейсом I2C, але з різними перспективами застосування.

Приклад №2. I2CUI3, I2CUI4 та I2C

Спочатку ми розробили I2CUI3 – корисний і надійний продукт. Це універсальний модуль інтерфейсів користувача з інтерфейсом I2C, який забезпечує ввід керівних дій користувачем за допомогою п’яти кнопок навігації та вивід даних на RGB-світлодіод і базер про стан чи події IoT-пристрою. В основі 8-бітний розширювач портів NXP PCA9538. Багато років ми застосовуємо цей чіп для різних задач, у тому числі як головний компонент модуля I2CUI3. Розширювач портів PCA9538 є зручним, адже працює напівавтоматично після подачі живлення і для деяких задач взагалі не потребує попереднього програмування, а відтак може працювати навіть без головного мікроконтролера.

А потім нам стало зрозуміло, що для деяких задач потрібен не 8-бітний, а 16-бітний аналогічний модуль. Так з’явився новий продукт – модуль I2CUI4 на базі чіпа розширювача портів MCP23017, теж з інтерфейсом I2C.

Для нового I2CUI4 ми могли б скористатися старшим у лінійці розширювачем компанії NXP. У них є кілька чіпів розширювачів на 16-біт, наприклад PCA6416, PCA9539, PCA9575, PCA9673. Але для жодного з чіпів немає офіційних бібліотек ні на сайті arduino.cc, ні на сайті esphome.io. Під прошивку NodeMCU теж немає драйверів.

На Github є лише кілька бібліотек для PCA9539, але ні від Adafruit ні від Seeed Studio драйверів немає для жодного чіпа NXP.

Саме тому на новому продукті I2CUI4 передбачено сумісність з поширеними платформами і встановлено мабуть найпопулярніший чіп MCP23017 з I2C інтерфейсом.

Через це наш продукт на базі MCP23017 може похизуватися повною підтримкою у Arduino, NodeMCU, ESPHome / Home Assistant, Node-RED, Blynk, MicroPython, Raspberry Pi, STM32 та багатьох інших брендів. На GitHub можливо знайти сотні репозиторіїв з драйверами на C/C++, Python, JS, Lua, тощо.

Висновок

Ми навели два промовисті приклади виявлення та вирішення проблеми драйверної підтримки пристроїв обладнаних інтерфейсом I2C з власного досвіду.

У випадку, якщо ви не плануєте самостійно забезпечувати підтримку I2C-пристрою, який купуєте, драйверами і розробляти їх, зверніть увагу на приховані зовнішні ризики, описані у цій публікації. Пристрій, модуль чи чіп з інтерфейсом I2C потрібно обирати такий, щоб він поміж інших чинників також мав найширшу драйверну підтримку серед систем третіх виробників. Особливу увагу щодо сумісності і підтримки варто приділити цільовим мікроконтролерам, платформам, середовищу розробки. Ви маєте бути впевнені, що всі ці системи будуть підтримувати ваш чіп, перш ніж спиратися на нього у власних проектах.

Керування цими принципами дозволило нам розробити два прекрасні продукти GGreg20 та I2CUI4, мінімізувати ризики і уникнути згаданих проблем.

Сподіваємося, цей матеріал буде вам корисним. 

Дякуємо за увагу.