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

Дякуємо за увагу. Ставте запитання у наших соцмережах.
Бажаємо успіхів!

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

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

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

Звісно, що кожен модуль з інтерфейсом I2C зазвичай має власні бібліотеки, розроблені виробником або небайдужими учасниками спільноти програмного забезпечення з відкритим вихідним кодом. Наприклад, модуль GGreg20_V3 має кілька таких бібліотек для популярних платформ:

Примітка. Хоча кожна сучасна платформа для IoT, як правило, забезпечує підтримку шини I2C, також має бути наявним драйвер для кожного конкретного апаратного модуля (виробник, модель, версія). Підтримка має бути як на боці платформи, так і на боці головного контролера, до якого підключається модуль.

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

У випадку ж з лічильником імпульсів на GPIO абсолютно інша ситуація: усі платформи підтримують таку функцію і дуже просто програмуються.

Замість висновків

Попри очевидні переваги шини I2C, якщо ми і приймемо в майбутньому рішення додати підтримку I2C у модуль GGreg20, то це буде ще один, альтернативний пристрій з такими можливостями. А споживачі самі зможуть обирати, який з варіантів їм підходить найкраще.

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

Бажаємо успіхів!

Шина 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, мінімізувати ризики і уникнути згаданих проблем.

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

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

1. Загальний огляд. Це панель, яка може встановлюватися на стінці корпусу для керування пристроєм. Для керування встановлений джойстик. Для індикації станів пристрою встановлений RGB світлодіод а звукові сигнали виводяться на buzzer. Взаємодія з контролером по цифровому інтерфейсу I2C; Модуль буде зручно застосувати в багатьох користувацьких проектах на основі ESP8266 чи Arduino. На панелі також встановлений роз’єм з інтерфейсом I2C, щоб було зручно підключати зовнішні пристрої – наприклад, цифровий термометр.

2. Цей модуль може Вам сподобатися наступними рішеннями:

•  В ході конструювання одного з наших пристроїв стояла задача розміщення п’яти кнопок в “тісному” корпусі. Випадково знайдений джойстик наштовхнув нас на це елегантне рішення, яке і на практиці нас не підвело. Отже, замість традиційних кнопок на I2CUI1 встановлений компактний джойстик, який в корпусі тактової кнопки об’єднує 5 кнопок (вліво, вправо, вверх, вниз, ОК); 
• Встановлений на платі розширювач GPIO PCA9538 вирішує дві задачі – зручне віддалення (наприклад, при необхідності встановлювати на стінках корпусу) панелі від головного контролера компактною дводротовою шиною I2c і одночасно встановленими популярними компонентами керування і індикації;
• Широкий діапазон напруги живлення дозволяє інтегрувати модуль в системах на  ESP8266 і Arduino;
• Зроблений апаратний захист від “брязкоту” контактів джойстика;
• Встановлений на модулі buzzer підключений окремою шиною до GPIO контролера, бо світлодіодом і джойстиком зайняті усі порти розширювача. На перший погляд, це недолік але, за нашим досвідом, buzzer-ом потрібно мати можливість програмно керувати (гучність, звукові ефекти). Якби buzzer був підключений до GPIO розширювача, було б доступне тільки програмне вкл/викл, адже розширювач портів PCA9538 не підтримує необхідний для керування режим PWM;
• Шина INT активується при кожному натисканні джойстика і ініціює переривання ПЗ для обробки станів джойстика;
• Компактність і якість виготовлення.

3. Приклад застосування модуля.

За декілька хвилин ми склали термостат, використавши:  

Звісно, що термостат вимагає розробки оригінального програмного забезпечення.

Будемо вдячні з підтримку нашої сторінки у і придбання товарів в нашому магазині. iot-devices.com.ua