І дійсно, чому б не додати на модуль такий зручний інтерфейс? Пропонуємо до вашої уваги наш черговий матеріал, де ми цього разу розмірковуємо про переваги та недоліки оснащення модуля детектора іонізуючої радіації GGreg20_V3 інтерфейсом I2C.
Одразу зазначимо, що серед інших інтерфейсів передачі даних нам дуже подобається послідовна шина I2C за її простоту, функціональність та надійність роботи. Ви можете ознайомитися з іншими публікаціями, де ми розглядаємо цю чудову шину:
Як правильно вибрати I2C чіпи. Або про приховану програмну проблему вибору
апаратних модулів / How to choose the right I2C chips. Or the hidden software problem of
choosing hardware modules
Application of I2C bus interface splitter
Втім, під час роботи над GGreg20_V3 нашою метою було і є забезпечити якомога ширшу сумісність цього нашого продукту з різними системами.
Ось подивіться:
(1) Коли якийсь модуль чи мікросхема має інтерфейс комунікації I2C (чи SPI, UART), це автоматично вимагає написати для такого пристрою низькорівневий драйвер-коннектор.
(2) Також такий пристрій взагалі не може інтегруватися з іншими компонентами, які заздалегідь не підтримують певний інтерфейс обміну даними чи керування, як-от I2C. Буває купа проектів, у яких немає I2C, або ж під шину I2C не вистачає вільних GPIO.
(3) Модуль вимірювання радіації, за певних умов, має бути спроможним застосовуватися у польових умовах, без підключення до головного контролера. Користувач має мати змогу використати такий пристрій незалежно від умов, в яких він опинився. Без програмування чи апаратних доробок.
(4) Оснащення модуля інтерфейсом I2C вимагає розташування на модулі вбудованого контролера-компаньйона, який забезпечує підготовку даних для споживача та комунікацію у режимі підпорядкованого пристрою (Slave Device) відповідно до специфікації I2C. Хоча це може бути простий і недорогий контролер, його наявність підвищує вартість, а також збільшує розміри модуля. Також потрібно виділити додаткове місце на платі модуля під площадки вибору адреси.
(5) Модуль з інтерфейсом I2C обов’язково потребує наявності головного контролера та дисплею, щоб ним можливо було користуватися за призначенням. І це при тому, що на модулі вже є вбудований контролер – компаньйон. Головні контролери бувають дуже різні. Хтось використовує Raspberry Pi, або ж Arduino, а комусь важливо мати можливість застосувати ESP32 / ESP8266. Саме тому ми не ставимо головний контролер на плату модуля GGreg20. Ми вважаємо, що користувач має право обирати контролер, платформу чи середовище розробки незалежно та самостійно. А наша задача – забезпечити якомога ширшу сумісність та універсальність нашого продукту.
З електричної точки зору, оснащення пристроїв даної категорії інтерфейсом I2C переваг теж не має, адже живлення та інтерфейс передачі даних що у I2C-варіанті, що у варіанті з імпульсним виходом, як у GGreg20_V3, потребують однакової кількості сигнальних дротів у шлейфі. Гарячу заміну, яку підтримує шина I2C, для модулів даного типу теж важко назвати бажаною, вже не кажучи про обов’язковість наявності такої функції.
На Рис. наводимо схематичні зображення двох модулів – поточної версії GGreg20 без I2C, та версії з інтерфейсом I2C, щоб показати, наскільки довелося б змінити модуль з урахуванням реальних розмірів (10х10 мм) додаткової мікросхеми вбудованого контролера-компаньйона.
Рис. Якби GGreg20_V3 мав інтерфейс I2C (червоним показано вбудований контролер-компаньйон, що забезпечує режим I2C Slave Device)
Єдиними перевагами для обґрунтування доцільності оснащення нашого модуля радіації інтерфейсом I2C є наступні:
- можливість підключення декількох пристроїв на I2C-інтерфейс головного контролера;
- розрахунок користувацьких значень засобами вбудованого контролера-компаньйона.
Але якщо ретельно зважити потенційні здобутки та цілком конкретні втрати від запровадження I2C у даному пристрої, стане очевидним, що для користувача краще мати універсальний модуль з широкою драйверною підтримкою і можливістю застосування у “ручному” режимі, ніж отримати купу переваг шини I2C, якими ще потрібно зуміти скористатися.
| Інтерфейс I2C | Інтерфейс лічильника імпульсів на порту вводу-виводу (GPIO pulse counter) | |
| Автономне використання в “ручному” режимі | Ні | Так |
| Потребує вбудований контролер – компаньйон | Так: – вища вартість; – більші розміри. | Ні |
| Драйверна підтримка | Відсутня / дуже обмежена | Найширша |
| Вимоги до апаратної обв’язки | Високі: – головний контролер; – дисплей. | Низькі / відсутні |
| Вимоги до кваліфікації користувача | Високі: – програмування embed.; – адміністрування/конфіг; – інтерфейси/протоколи; – електроніка/інтеграція. | Низькі / відсутні |
Додатково до вже викладеного вище наведемо дві ключові проблеми, котрі ми хотіли б окреслити для потенційних користувачів. Цих проблем немає в GGreg20_V3, але їх неодмінно матиме (у тих чи інших варіаціях) модуль вимірювання радіації з інтерфейсом I2C.
Проблема #1 Польові умови / Надзвичайна ситуація
Обдумайте таку ситуацію: у вас в шухляді лежить сенсор радіації і чекає, коли ж ви його нарешті почнете програмувати, а в наступний момент вам вже потрібно якнайшвидше покинути будинок з одним наплічником у руках і, можливо, мерщій починати вимірювати рівень радіації, бо настала ситуація природного чи техногенного лиха, і ви знаходитеся поруч з епіцентром таких подій.
Ми в Україні дуже добре знаємо ці обставини і враховуємо накопичений у найважчі для країни часи досвід, щоб зробити системний дизайн наших продуктів якомога кращим.
Наш модуль GGreg20_V3 достатньо лише заживити від павербанка (чи навіть кількох батарейок АА/ААА) чи сонячної панелі – і все: можна вручну проводити вимір за спалахами світлодіода та секундоміром чи власним відліком.
Кількість спалахів за хвилину помножена на коефіцієнт перетворення – і є рівень радіації у mkSv/hour.
Коефіцієнт перетворення для трубки SBM20 є рівним 0.0054. Таким чином маємо просту формулу:
CPM x 0.0054 = mkSv/hour.
де CPM – кількість спалахів на хвилину (Counts per Minute).
Для Києва [20 – 48] спалахів – це нормальний рівень (0.10 – 0.26 mkSv/h).
На противагу GGreg20_V3, модуль з інтерфейсом I2C в польових умовах буде дуже складно використати за призначенням. Адже модуль також потребує наявності головного контролера, дисплея, засобів програмування, розробки програмного коду, та спеціальних знань і навичок, що дозволять взаємно підключити необхідні компоненти та запрограмувати їх. Це означає, що звичайний користувач без спеціальних знань не зможе провести вимірювання сенсором з інтерфейсом I2C, навіть якщо він, за гарним збігом обставин, матиме такий у своєму наборі доступних інструментів.
Проблема #2 Драйверна підтримка
Навіть якщо все гаразд з обстановкою, що оточує користувача, і модуль сенсора радіації експлуатується в умовах цивілізації, все одно з варіантом дизайну модуля, що має інтерфейс I2C є проблеми. Проблеми виникають у користувачів, які хочуть використовувати улюблені системи / платформи / середовища / архітектури розробки для IoT.
Систем і смаків дуже багато, і навіть самі передові і популярні системи мають драйвери далеко не для всіх пристроїв, що зазвичай купують та намагаються підключити споживачі.
Завдяки неоднорідності протоколів інтеграції іноді доводиться писати драйвер самостійно, або чекати кілька років, доки розробники системи звернуть увагу на цей конкретний комерційний пристрій і розроблять відповідний драйвер-конектор.
Наведемо порівняльну таблицю поширених платформ з вбудованою підтримкою I2C сенсорів радіації та платформ з підтримкою лічильника імпульсів на GPIO, щоб читач міг осягнути масштаб цієї проблеми.
| Платформа | Модуль сенсора радіації з I2C, вбудована драйверна підтримка платформою | Модуль сенсора радіації З імпульсним виходом, вбудована драйверна підтримка (GPIO pulse counter, external ISR) платформою |
| Arduino | Ні | Так |
| NodeMCU (Lua) | Ні | Так |
| MicroPython | Ні | Так |
| ESPHome / Home Assistant | Ні | Так |
| Espressif ESP-IDF | Ні | Так |
| STM32 | Ні | Так |
| Tasmota | Ні | Так |
Ці дані дуже промовисто вказують, що сенсор з імпульсним виходом, такий як GGreg20_V3, набагато легше підключити до будь-якої платформи, або ж використовувати модуль взагалі автономно, за необхідності.
Звісно, що кожен модуль з інтерфейсом I2C зазвичай має власні бібліотеки, розроблені виробником або небайдужими учасниками спільноти програмного забезпечення з відкритим вихідним кодом. Наприклад, модуль GGreg20_V3 має кілька таких бібліотек для популярних платформ:
| Platform | Link |
| Arduino contributed library | https://www.arduino.cc/reference/en/libraries/ggreg20_v3/ |
| ESPHome / Home Assistant example | https://github.com/iotdevicesdev/ggreg20-v3-homeassistant-esphome-example |
| Tasmota driver example | https://github.com/iotdevicesdev/ggreg20-v3-tasmota-esp32-driver |
| NodeMCU (Lua) example | https://github.com/iotdevicesdev/ggreg20-v3-nodemcu-lua-example |
| NodeMCU (Lua) full functional driver | https://alterstrategy.com/product/radcounter/ |
Примітка. Хоча кожна сучасна платформа для IoT, як правило, забезпечує підтримку шини I2C, також має бути наявним драйвер для кожного конкретного апаратного модуля (виробник, модель, версія). Підтримка має бути як на боці платформи, так і на боці головного контролера, до якого підключається модуль.
Наявність бібліотек, подібних до тих, що наведено у таблиці, вже добре. Але це не дає жодних гарантій, що ці бібліотеки підтримуються їх авторми та є актуальними, а також що користувач знайде таку бібліотеку саме до своєї улюбленої платформи і зможе її інтегрувати до неї і запрограмувати кінцевий пристрій.
У випадку ж з лічильником імпульсів на GPIO абсолютно інша ситуація: усі платформи підтримують таку функцію і дуже просто програмуються.
Замість висновків
Попри очевидні переваги шини I2C, якщо ми і приймемо в майбутньому рішення додати підтримку I2C у модуль GGreg20, то це буде ще один, альтернативний пристрій з такими можливостями. А споживачі самі зможуть обирати, який з варіантів їм підходить найкраще.
Купуйте детектор іонізуючої радіації GGreg20_V3 з імпульсним виходом.
Бажаємо успіхів!
