Модуль DCDC_3V3_400V_V1 є джерелом високої напруги для живлення широкого спектру трубок Гейгера – Мюллера, які мають різний рівень напруги анод – катод, а також може бути застосований в якості малопотужного джерела високої напруги в інших DIY проектах.

Потреба встановлення різного рівня вихідної напруги, є однією з причин встановлення в модулі налагоджувального потенціометра.

Іншими налагоджувальними компонентами є резистор R1 і конденсатор C1.

Для пояснення наведена зображена нижче.блок схема.

На блок схемі ліва частина демонструє структуру модуля високовольтного перетворювача DCDC_3V3_400_V1.

Права частина блок схеми показує компоненти споживачів електричної енергії від модуля DCDC_3V3_400_V1, інтегрованого в DIY проект, відповідно до задуму користувача.

Вихідним каскадом модуля DCDC_3V3_400_V1 є високовольтний помножувач. В проектах детекторів радіації на базі лічильника Гейгера-Мюллера трубка отримує високу напругу від 300 до 2000 вольт через ланцюжок R1C1. 

Значення опору, ємності і напруги для R1 і C1, залежать від типу трубки або схемотехніки DIY пристрою. Зважаючи на це, R1 i C1 на модулі DCDC_3V3_400_V1 не встановлені. 

Іншою причиною відсутності на модулі R1 і C1 є ймовірність пошкодження (електричного пробою) С1 під час регулювання напруги потенціометром. 

Враховуючи ці фактори, рекомендуємо при проведенні тестування модуля DCDC_3V3_400_V1, до вихідних контактів припаяти або приєднати ланцюжок за  такою схемою:

Регулювання і вимірювання напруги потрібно виконувати аналогічно до кроків зазначених у Інструкції з початкової діагностики модуля лічильника гейгера GGreg20_V3.

Другу частину опису дивіться за посиланням: Підключення сенсора радіації GGreg20_V3 до сервера Home Assistant через інтеграцію ESP Home – частина 2

Примітка. Дана публікація підходить для всіх версій детектора іонізуючої радіації виробництва IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3. 
Оскільки вся лінійка даних детекторів орієнтована на трубку СБМ-20, усі версії пристроїв мають однаковий алгоритм та коефіцієнти розрахунку рівня потужності та дози іонізуючого випромінювання.
На точність вимірювання впливають лише індивідуальні властивості встановленої в кожен конкретний детектор GGreg20_V3 трубки СБМ-20. У технічних характеристиках виробника трубок вказано граничний діапазон точності вимірювань у 20%. На практиці це означає, що два однакові пристрої GGreg20, але з різними трубками СБМ-20, можуть давати результати (не білше ніж) із зазначеним відхиленням за кількістю імпульсів.

Кроки з підключення GGreg20 до Home Assistant – продовження.

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Сутності та показники пристрою на сервері

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним GGreg20

Наводимо приклад консолі діючого пристрою з GGreg20 та yaml-налаштуваннями аналогічними тим, що ми розробили вище.

Рис. Вивід у консоль журналу (Logs) пристрою через інтерфейс ESP Home

Крок 9. Перевірити, чи утворилися нові сутності на боці сервера

Щоб перевірити, чи утворилися відповідні сутності GGreg20 в плагіні ESP Home і чи бачить їх сервер Home Assistant, є два шляхи:

• перейти в меню Інструменти для розробників на бічній панелі інтерфейсу Home Assistant та пошукати відповідні дані так, як показано на Рис.

Рис. Пошук потрібних сутностей через меню Інструменти для розробників

• або перейти у меню Конфігурація -> Інтеграція та пошукати як показано на на наступних рисунках

Рис. Пошук потрібних сутностей через меню Конфігурація -> Інтеграція

Рис. Пошук потрібних сутностей через меню Конфігурація -> Інтеграція : Пристрої / Сутності

Візуалізація та Автоматизація

Крок 10. Додати на Дашборд віджети сенсора радіації GGreg20

Наводимо приклад демонстраційної вкладки з діючого сервера для двох пристроїв GGreg20_V1 та GGreg20_V3 розташованих у різних площинах координат. Для кожного з пристроїв застосовується такий самий yaml-файл, як ми створили вище.

Рис. Дашборд демонструє віджети з даними про рівень радіації з двох сенсорів GGreg20_V1 і GGreg20_V3 що розташовано за різними вісями координат.

Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Після того, як ми пересвідчилися, що новий пристрій працює і надсилає надійні дані, можливо перейти до головної задачі – Автоматизацій. Цей потужний інструмент доступний адміністраторові через меню Конфігурація -> Автоматизації.

Оскільки сутності, зі значенням потужності та дози іонізуючої радіації, створені нами засобами ESP Home, доступні наскрізно для всіх компонентів та функцій Home Assistant, адміністратор може створювати будь-які події, функції, сценарії з їх застосуванням.

Наприклад, можливо створити автоматизоване сповіщення, про перевищення нормального порогу потужності іонізуючого випромінювання з повідомленням на смартфон. І так далі.

Але, ці теми далеко виходять за межі даної публікації і ми не маємо змоги їх тут розглянути.

Висновки

У першій та другій частинах ми розглянули кроки

Сервер
Крок 1. Встановити (або запустити) сервер Home Assistant

Плагін ESP Home для Home Assistant
Крок 2. Підключити розширення ESP Home для сервера Home Assistant через меню Supervisor -> Add-on Store

YAML-конфіг нового пристрою ESP з GGreg
Крок 3. Скачати готовий приклад пакетного yaml-файлу конфігурації пристрою GGreg20_V3 для ESP8266 з нашого сайту
Крок 4. Створити (на базі прикладу) у ESP Home відповідний yaml-файл конфігурації

Апаратне підключення GGreg20_V3 і контролера
Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від Ggreg20
Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера

Прошивка пристрою ESP з GGreg
Крок 7. Побудувати і записати прошивку для контролера

Далі ми виконали наступні кроки з підключення GGreg20 до Home Assistant:

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Ми докладно розглянули найпростіший шлях підключення детектора GGreg20 з контролером ESP8266 до сервера Home Assistant з плагіном ESP Home.

І пересвідчилися, що це зовсім не складно, адже всю роботу за нас виконує:

• Детектор GGreg20_V3 – одразу ж реєструє імпульси і передає їх на ESP8266;
• Плагін ESP Home – надає інтерфейс з побудови прошивок і програмування ESP8266;
• Готовий yaml-файл звільняє нас від самостійного написання директив для сенсора GGreg20;
• Сервер Home Assistant надає нам можливість зручно підключати, адмініструвати та отримувати інформацію з будь-яких наших пристроїв.

На цьому все. Бажаємо успіхів!

Першу частину опису дивіться за посиланням: Підключення сенсора радіації GGreg20_V3 до сервера Home Assistant через інтеграцію ESP Home

Примітка. Дана публікація підходить для всіх версій детектора іонізуючої радіації виробництва IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3. 

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

На точність вимірювання впливають лише індивідуальні властивості встановленої в кожен конкретний детектор GGreg20_V3 трубки СБМ-20. У технічних характеристиках виробника трубок вказано граничний діапазон точності вимірювань у 20%. На практиці це означає, що два однакові пристрої GGreg20, але з різними трубками СБМ-20, можуть давати результати (не білше ніж) із зазначеним відхиленням за кількістю імпульсів.

Кроки з підключення GGreg20 до Home Assistant – продовження.

Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від Ggreg20
Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера
Крок 7. Побудувати і записати прошивку для контролера

Апаратне підключення GGreg20_V3 і контролера

На кроках 5 та 6 ми наводимо приклад підключення для ESP8266. Для контролера ESP32 все відбувається аналогічно. Відрізняється лише кількість, призначення та нумерація GPIO ESP32, як більш потужної апаратної платформи. Але загальна технологічна логіка є тотожною.

Рис. Підключення GGreg20_V3 до класичної плати NodeMCU з ESP8266

Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від GGreg20

Якщо ви вперше маєте справу з ESP8266 і не знаєте, які GPIO краще застосувати для лічильника імпульсів, рекомендуємо скористатися Стандартом планування та застосування GPIO у проектах на базі ESP8266-12 / NodeMCU / Lua, що був розроблений спеціалістами alterstrategy.lab і викладений назагал.

Наприклад, це може бути GPIO0 (D3). Цей пін зручний тим, що має вбудовану кнопку Flash у більшості пристроїв і плат на базі модуля ESP8266 – у випадку, коли потрібно перевірити як контролер рахує імпульси без сенсора, можливо імітувати імпульси кнопкою. Саме тому всі приклади у даній публікації наведено для GPIO0 (D3).

Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера

Як можна бачити, підключення доволі просте – потрібно лише подати живлення з NodeMCU для модуля GGreg20, а також підключити вихід (Out) сенсора на вхід (D3) контролера та подати загальне живлення 5V на мікро USB роз’єм плати NodeMCU.

Примітка. Зверніть увагу, що у вас взагалі може не бути GGreg20 – в цьому випадку, ви можете імітувати імпульси простим натискання кнопки Flash (GPIO0 / D3) певну кількість разів на хвилину.

Прошивка пристрою ESP з GGreg

Крок 7. Побудувати і записати прошивку для контролера

Перед побудовою прошивки необхідно провести валідацію створеного нами yaml-файлу. Це убезпечить нас від помилок у файлі, яких ми могли випадково припуститися.

Рис. YAML-код лічильника, який заплановано прошивати у контролер ESP8266

Рис. Валідація yaml-коду пройшла успішно

Рис. Запуск компіляції бінарного файлу прошивки для певного yaml-коду

Якщо контролер новий – необхідно компілювати і завантажити на ПК двійковий bin-файл прошивки у інтерфейсі ESP Home – натиснути DOWNLOAD BINARY після успішного завершення компіляції.

Рис. Компіляцію успішно завершено

Далі потрібно записати прошивку в контролер (ESP8266 / ESP32). Зробити це можливо засобами утиліти ESPHome-Flasher. Її можливо вільно знайти і скачати через мережу Інтернет.

Рис. Загальний вигляд утиліти esphome-flasher

Якщо ж контролер вже був раніше прошитий ESP Home – просто залити оновлену прошивку через радіоефір, OTA Update. Але зауважте, що ми цей варіант оновлення прошивки свідомо не розглядаємо, адже мета статті показати, як підключити новий GGreg20 і новий ESP8266 до Home Assistant.

Рис. Запуск альтернативної процедури оновлення прошивки через WiFi-ефір – OTA Update

Після прошивки і запуску нового пристрою бажано перезапустити сервер Home Assistant.

Важливо! Після запуску сервера потрібно зайти в меню Конфігурація -> Інтеграція. Знайти там новий пристрій, який ми прошили і підключити його в конфігурацію сервера, якщо він не підключився автоматично.

Висновки

Ми виконали наступні кроки з підключення GGreg20 до Home Assistant:

Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від Ggreg20
Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера
Крок 7. Побудувати і записати прошивку для контролера

Далі ми докладно розглядаємо наступні кроки – частина 3:

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

На цьому все. Бажаємо успіхів!

Якщо ви вже маєте досвід налаштування та розгортання пристроїв у середовищі ESP Home під керуванням Home Assistant, можете пропустити вступні розділи та відразу переходити до прикладу yaml-файлу конфігурації, який ви можете взяти за основу для своєї власної системи і пристроїв.

Всі приклади файлів є робочими та працюють у реально розгорнутому сервері та контролері ESP8266 з детектором GGreg20. ESP32 також підтримується ESP Home і на прикладі ESP8266, читач може зробити варіант yaml-файлу для платформи ESP32. У даній публікації ми  демонструємо роботу з ESP32 у обмеженому вигляді, оскільки з точки зору налаштувань ESP Home та Home Assistant, платформи ESP8266 та ESP32 майже не відрізняються.

Примітка. Дана публікація підходить для всіх версій детектора іонізуючої радіації виробництва IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3. 

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

На точність вимірювання впливають лише індивідуальні властивості встановленої в кожен конкретний детектор GGreg20_V3 трубки СБМ-20. У технічних характеристиках виробника трубок вказано граничний діапазон точності вимірювань у 20%. На практиці це означає, що два однакові пристрої GGreg20, але з різними трубками СБМ-20, можуть давати результати (не білше ніж) із зазначеним відхиленням за кількістю імпульсів.

Кроки з підключення GGreg20 до Home Assistant

Далі ми докладно розглядаємо кроки з підключення детектора (сенсора) GGreg20. Чесно кажучи, нам доводиться наводити багато тексту та рисунків, щоб пояснити деякі важливі моменти – через це публікація здається процедурним жахом. Це не так! Всі ці кроки є простими, автоматизованими і виконуються за 15-20 хвилин.

Сервер

Крок 1. Встановити (або запустити) сервер Home Assistant

Якщо у вас вже встановлено сервер, просто запустіть його. Якщо ж вам потрібно розгорнути  сервер, рекомендуємо переглянути розроблену нами інструкцію щодо розгортання Home Assistant у віртуальній машині під ОС Windows 10.

Плагін ESP Home для Home Assistant

Крок 2. Підключити розширення ESP Home для сервера Home Assistant через меню Supervisor -> Add-on Store

Процедура встановлення офіційного плагіна, як-от ESP Home, у Home Assistant доволі проста. Рекомендуємо переглянути Крок 8. Встановлення плагіну ESP Home (Опція) вже згаданої раніше інструкції.

YAML-конфіг нового пристрою ESP з GGreg

Це ключова частина даної публікації, яка нас цікавить більше, ніж всі інші загальні дані про підготовчі кроки середовища. На 3 і 4 кроках будемо розробляти власний конфіг для ESP з GGreg на базі реальних прикладів з нашого тестового сервера Home Assistant.

Крок 3. Скачати готовий приклад пакетного yaml-файлу конфігурації пристрою GGreg20_V3 для ESP8266 з нашого сайту

YAML-файл – це загальноприйнятий у Home Assistant текстовий скриптовий файл, у даному випадку з інструкціями для ESP Home, які застосовуються під час побудови прошивки.

Ми розробили такий файл для ESP8266 з GGreg20 та виклали його у себе на сайті для вільного скачування і використання усіма, кому потрібно підключити GGreg20 до Home Assistant через ESP Home. Скачати файл можливо за цим посиланням.

Повний файл який ви щойно скачали, має наступний вміст:

Open YAML-text

Розглянемо основні частини підготовленого нами файлу ggreg20_esp8266_esphome.yaml.

Для розрахунку значення потужності іонізуючого випромінювання мікрозіверт на годину, використовується Pulse Counter Sensor – компонент API плагіну ESP Home:

https://esphome.io/components/sensor/pulse_counter.html

За це відповідає ця частина yaml-коду:

sensor:
- platform: pulse_counter
  pin: D3
  unit_of_measurement: 'mkSv/Hour'
  name: 'Ionizing Radiation Power'
  count_mode: 
    rising_edge: DISABLE
    falling_edge: INCREMENT
  update_interval: 60s
  accuracy_decimals: 3
  id: my_doze_meter
  filters:
    - sliding_window_moving_average: # 5-minutes moving average (MA5) here
        window_size: 5
        send_every: 5      
    - multiply: 0.0054 # SBM20 tube conversion factor of pulses into mkSv/Hour 

Для розрахунку сумарної отриманої дози опромінення мікрозіверт, застосовується Integration Sensor, теж компонент ESP Home API:

https://esphome.io/components/sensor/integration.htm

За це відповідає ця частина yaml-коду:

- platform: integration
  name: "Total Ionizing Radiation Dose"
  unit_of_measurement: "mkSv"
  sensor: my_dose_meter # link entity id to the pulse_counter values above
  icon: "mdi:radioactive"
  accuracy_decimals: 5
  time_unit: min # integrate values every next minute
  filters:
    # obtained dose. Converting from mkSv/hour into mkSv/minute: [mkSv/h / 60] OR [mkSv/h * 0.0166666667].
    # if my_dose_meter in CPM, then [0.0054 / 60 minutes] = 0.00009; so CPM * 0.00009 = dose every next minute, mkSv.
    - multiply: 0.0166666667

Також, з метою можливості тестування лічильника імпульсів без сенсора GGreg20, у конфігурацію додано дискретний сенсор кнопки Flash ESP8266 – на той же GPIO0 (D3), що і Pulse Counter – але застосовується вже інший компонент ESP Home API, GPIO Binary Sensor:

https://esphome.io/components/binary_sensor/gpio.html

За це відповідає ця частина yaml-коду:

binary_sensor:
  - platform: gpio
    name: "D3 Input Button"
    pin:
      number: 0
      inverted: True
      mode: INPUT_PULLUP

Плагін ESP Home має достатню документацію на ці компоненти з прикладами, тому ми не будемо вдаватися до детальних пояснень. Де ми вважали за потрібне, ми додали коментарі всереднині yaml-коду.

Крок 4. Створити (на базі прикладу) у ESP Home відповідний yaml-файл конфігурації

Після скачування готового файлу, пропонуємо вам відкрити його будь-яким текстовим редактором і ознайомитися з його вмістом.

Далі необхідно у інтерфейсі плагіну ESP Home на веб-сторінці Home Assistant з правами доступу адміністратора, створити свій власний yaml-файл натиснувши “+” і відповівши на кілька початкових запитань майстра.

Рис. Загальний вигляд інтерфейсу плагіну ESP Home у Home Assistant

Рис. Даємо назву нашому новому пристрою

Рис. Обираємо потрібну платформу відповідно до типу контролера

Рис. Вказуємо параметри WiFi-роутера та пароль для OTA оновлення

Після завершення роботи “майстра”, в інтерфейсі ESP Home з’являється створений нами файл з базовими параметрами, які ми вже налаштували. Тепер потрібно дописати в цей файл частини, які ви знайдете у файлі ggreg20_esp8266_esphome.yaml

Рис. Базова конфігурація для ESP8266 / NodeMCU що створює “майстер”.

Для прикладу наводимо аналогічний початковий yaml-файл для ESP32. Як можна бачити, він майже не відрізняється від файлу для ESP8266.

Рис. Базова конфігурація для ESP32 / WROVER що створює “майстер”.

Якщо скомпілювати такий початковий файл – він буде працювати і робити базові речі – з’єднуватися з сервером, піднімати точку доступу для налаштувань і тому подібне. Але такий контролер не буде виконувати жодних прикладних завдань.

Саме тому вам знадобиться розроблений нами файл – потрібно скопіювати решту налаштувань з нашого файлу у ваш. Також ви можете повністю замінити вміст у вашому файлі даними з ggreg20_esp8266_esphome.yaml, звісно, якщо у вас контролер ESP8266. Якщо ж у вас контролер відрізняється – потрібно замінити відповідні частини файлу, а решту залишити без змін.

Висновки

Ми виконали наступні кроки з підключення GGreg20 до Home Assistant:

Крок 1. Встановити (або запустити) сервер Home Assistant
Крок 2. Підключити розширення ESP Home для сервера Home Assistant через меню Supervisor -> Add-on Store
Крок 3. Скачати готовий приклад пакетного yaml-файлу конфігурації пристрою GGreg20_V3 для ESP8266 з нашого сайту
Крок 4. Створити (на базі прикладу) у ESP Home відповідний yaml-файл конфігурації

Далі ми докладно розглядаємо наступни кроки:

Частина 2:

Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від Ggreg20
Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера
Крок 7. Побудувати і записати прошивку для контролера

Частина 3:

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

На цьому все. Бажаємо успіхів!

Маємо головний контролер системи, до якого нам потрібно підключити декілька пристроїв з інтерфейсом I2C. На рисунку наводимо приблизний класичний набір модулів, які може бути необхідно підключати до головного контролера (MCU).

Рис. Приклад різноманітних модулів з шиною I2C

Більшість мікроконтролерів (MCU) є мініатюрними пристроями і має дуже обмежений бюджет вільних портів вводу/виводу. Зазвичай на контролерах типу Arduino / ESP8266 / ESP32 / STM32 під шину I2C (навіть якщо їх передбачено дві) у реальності можливо зарезервувати лише один інтерфейс: два порти GPIO під сигнальні канали SDA та SCL.

Причин цьому щонайменше дві.

По-перше, GPIO порти – це коштовний ресурс на головному контролері. Вони задіяні під інші, не менш важливі зовнішні інтерфейси : UART, SPI, Deep Sleep Wakeup, входи під кнопки, виходи під актюатор(и),тощо.

По-друге, дизайн плати модуля головного контролера має враховувати обмеження за розмірами: чим більше роз’ємів встановлено на цій платі, тим більші лінійні розміри вона буде мати.

Примітка. Також всі ми знаємо, що послідовну шину I2C може бути реалізовано не лише апаратно, з фіксованими портами вводу-виводу MCU, але і програмно, коли сигнальні лінії шини можуть бути призначені на будь-які порти GPIO MCU. Ба більше, програмна реалізація шини дозволяє об’явити декілька програмних шин I2C з різними Bus_ID.

Рис. Апаратна та програмна реалізації шини I2C головного контролера

Але маніфестація кількох програмних шин I2C одночасно в межах одного MCU скорочує кількість вільних виводів під інші задачі. Через це такими можливостями мало коли користуються. Виключенням можуть бути ситуації, коли така техніка дозволяє уникати проблем, які неможливо вирішити у інший спосіб. Наприклад, колізії адресації (два різних пристрої з однаковою 7-біт адресою) та подібні проблеми. Але навіть для таких проблем ефективніше застосувати апаратний мультиплексор шин I2C, ніж кілька програмних шин I2C.

Вирішення задачі

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

На ринку є безліч подібних пристроїв, та ми наведемо приклади на пристрої власного виробництва – I2CHUB_V1, має 6 портів I2C: 3 x JST HX2.54, 3 x Dupont і два виділені порти живлення.

Рис. Модуль поділювача інтерфейсів I2CHUB_V1 як приклад

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

Рис. Приклад підключення специфічних модулів сенсорів з двома роз’ємами I2C

“Вхідний” інтерфейс кожного такого модуля підключається до MCU або попереднього модуля сенсора на шині, а “вихідний” інтерфейс дозволяє каскадом підключити наступний модуль. Деякі виробники передбачають по два інтерфейси шини I2C саме з цією метою. Але, нажаль, більшість модулів не оснащено такими можливостями. Тому розглядаємо I2C HUB як більш поширений і універсальний підхід. Нижче наводимо основні схеми підключення модулів із застосуванням поділювача / хаба.

Примітка. Коли зростає кількість з’єднань, степеневим чином зростає:
– кількість точок відмови (PoF, Point of Failure);
– ризик людської помилки під час виконання з’єднань сигналів інтерфейсу.

З міркувань захисту обладнання від виходу з ладу та помилок монтажу, з метою підвищення загальної надійності системи, радимо:

• якомога частіше застосовувати роз’єми з ключем;
• застосовувати модулі з взаємно сумісними електричними інтерфейсами та фізичними роз’ємами.

Не дивлячись на те, що ми рекомендуємо застосовувати за можливості роз’єми з ключем, ми намагаємося рахуватися з реаліями ринку електронних компонентів та враховувати потреби споживачів. І тому ми наділили поділювач I2CHUB_V1 можливістю виступати у якості конвертора типу роз’ємів з JST на Dupont і навпаки – з Dupont на JST.

Вважаємо це дуже корисною функцією, адже завдяки можливості вільно розвертати інтерфейсні кабелі JST – Dupont відповідним боком користувач може підключити до хаба практично будь-який існуючий на ринку модуль з інтерфейсом I2C. Також користувач може вільно використовувати власні штирьові кабелі Dupont – Dupont.
Для опції “Замовлення з кабелями” в модулі I2CHUB_V1 роз’єми завжди встановлюються за однаковою схемою: половина роз’ємів – 2.54 мм JST (з ключем), інша половина – штирьові роз’єми Dupont. Це робиться саме для забезпечення згаданої вище гнучкості взаємного підключення різноманітних I2C-модулів.

Схеми модульного підключення до поділювача інтерфейсів

Зірка

Найпоширеніша схема, коли всі модулі інтерфейсами I2C підключаються у поділювач. Назвемо її “Зірка”.

Рис. Приклад підключення типу “Зірка”

Каскадування

Наступна топологія є каскадом двох і більше “Зірок”. Назвемо її “Каскадування”.

Рис. Приклад підключення типу “Каскадування”

Оскільки один з портів поділювача інтерфейсів завжди задіяно як “вхід”, то в деяких ситуаціях може виникнути нестача вільних портів поділювача. Саме в цьому випадку застосовується каскадування поділювачів у необхідній кількості таким чином, щоб забезпечити бажану кількість інтерфейсних портів на шині I2C.

Наприклад, I2CHUB_V1 виробництва IoT-devices має 6 портів I2C. Якщо в проекті, за задумом, необхідно підключати до MCU більше 5 підпорядкованих пристроїв, то можливо застосувати каскадування двох поділювачів і розподілити між їх інтерфейсами відповідні підпорядковані пристрої.

Довга лінія

Остання можлива схема впровадження, яку варто навести у даній публікації – це топологія з довгою лінією передачі даних і двома віддаленими, незалежними джерелами живлення. Назвемо її “Довга лінія”.

Рис. Приклад підключення типу “Довга лінія”

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

Сумісність поділювачів з іншими системами

Якщо ви використовуєте в одному проекті модулі з різними напругами живлення, то маєте приділити особливу увагу взаємному узгодженню таких компонентів. Та якщо ви вирішили застосувати пасивний поділювач, який не має елементів перетворення чи узгодження рівня напруги, то просто враховуйте, що та напруга, яку ви подаєте на роз’єми поділювача потрапить на всі підключені до поділювача модулі через відповідні сигнальні лінії шини I2C.

Втім, оскільки класичний поділювач I2C (такий як I2CHUB_V1) є пристроєм пасивним та не перетворює напруги за рівнем, він автоматично є сумісним з будь-яким контролером, до якого ви вирішили його підключити: Arduino, STM32, ESP8266, ESP32, Raspberry Pi, etc.

Увага! Лише ви вирішуєте, з якими логічними рівнями мають працювати компоненти проекту: 1.8V, 3.3V чи 5V.

Докладні специфікації шини I2C

Для того, щоб ознайомитися докладно з усіма особливостями шини I2C, рекомендуємо читати офіційні настанови та вимоги специфікації за посиланням: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
А також інші ресурси в мережі інтернет.

Ось і все, що ми запланували розповісти у даній публікації. Ми розглянули особливості і можливості підключення підпорядкованих модулів до інтерфейсу шини 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, мінімізувати ризики і уникнути згаданих проблем.

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

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