У ті далекі часи, коли ми почали займатися сучасною мікроелектронікою, ми мали лише загальносистемне розуміння про те, які інтерфейси та протоколи є поширеними у мікроелектроніці, чому саме вони, які у них є особливості.
У цій публікації спробуємо окреслити і розповісти про властивості шини I2C, що були для нас не очевидними і яким їх перетворити на нові можливості з тим, щоб надалі застосовувати на практиці.
Як можна бачити, див. рис.1, за даними сервісу Google Trends, шина I2C є не менш популярною ніж SPI (ці дві шини йдуть поруч у трендах), та значно популярнішою за UART.
Примітка Цікаво, що шина CAN (Controller Area Network, широко застосовується у автомобілебудівній індустрії як центральна нервова система автівки) так сильно відчула на собі наслідки кризи викликаної всесвітнім карантином, в той час, як інші три – майже не змінювали своїх позицій у згадуваності та пошуку.
Швидше за все, у цьому винні не споживачі мікроелектроніки та зачинені на карантин китайські заводи, а галузь купівлі – продажу автомобілів та супутніх товарів, бізнесова активність котрої також вимушено знижувалася на період жорсткого карантину. Проте, якщо подивитися тренди для Китаю та США – там взагалі не видно ніякого падіння, чого не можна сказати про Україну.
Переваги послідовної шини I2C
Шина I2C нам подобається завдяки декільком наявним характеристикам, якими ми радо поділимося з шановним читачем:
Поширеність і сумісність
Для шини I2C легко знайти будь-які підпорядковані (slave) пристрої. Навіть в Україні, у магазинах електроніки можливо придбати більше сотні різноманітних унікальних модулей з підтримкою шини I2C. І це не дивно, адже всі провідні виробники електроніки світу підтримують дану специфікацію.
На практиці це означає, що немає проблем купити термометр від одного виробника, а дисплей від іншого і обидва девайси будуть нормально працювати з головним контролером проекту.
За весь час нашої практики, до наших рук потрапило лише три чіпи із заявленою підтримкою I2C, що не запрацювало.
Кількість підпорядкованих пристроїв
Специфікація шини дозволяє адресувати до 127 унікальних адрес (2^7) з урахуванням декількох зарезервованих як службових.
Пристрої, що мають працювати на шині, у більшості випадків, теж забезпечують можливість апаратного чи програмного встановлення власної унікальної адреси, з якою вони будуть працювати на шині.
Таке рішення задачі адресації є достатньо гнучким і задовольняє потреби у переважній більшості випадків.
Навіть у випадках, коли між різними пристроями на шині конфлікт адресації є неминучим (наприклад, два різних пристрої мають однакові фіксовані адреси), є щонайменше два шляхи вирішення колізій.
Один з них, программный – запуск кількох шин I2C на одному мікроконтролері. Недоліком такого підходу є застосування двох додаткових портів GPIO під потреби ще однієї шини I2C.
Інший шлях, суто апаратний – застосування зовнішнього комутатора шин I2C. Прикладом такого комутатора (скоріше навіть мультиплексора, але виробник TI називає свій пристрій все ж комутатором) може слугувати TI TCA9548A. Цей пристрій за командою з головного контролера, здатен з’єднувати головну шину I2C з однією з восьми інших фізичних шин I2C по черзі. На кожній такій шині, теж може бути до 127 підпорядкованих пристроїв.
Усі зазначені можливості дозволяють вільно і майже без обмежень масштабувати обчислювальну систему, що розробляється.
Рольова модель
Шина I2C підтримує не лише класичну роботу Master – Slave, а і одночасну роботу декількох Master-пристроїв (Multi-Master з детектуванням колізій та арбітражем) на одній шині. Щоправда, на практиці, такої потреби у наших проектах ще не було, втім, така можливість є. Про те, коли і де застосовуються ці розширені можливості специфікації, дивіться за посиланням: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Довжина фізичного каналу зв’язку
Нам вдалося організувати стабільну роботу підпорядкованих пристроїв на відстані у 10 метрів від майстер-контролера. Це є більш ніж достатнім для будь-яких задач, як на наш погляд. Всі відстані що перевищують 10 метрів, мабуть краще організовувати через безпровідний зв’язок: чи то через Wi-Fi, чи то через якийсь звичайний RF трансивер із захистом від завад.
Згодом, плануємо написати про досвід організації десятиметрового провідного каналу I2C окрему публікацію у розділ нашого сайту “Електроніка”, див. alterstrategy.com/topics/electronics/.
Бюджет сигнальних ліній
Якщо порівнювати вимоги до кількості сигнальних каналів шини I2C та її найближчого конкурента, шини SPI, то отримаємо перевагу на боці I2C. У таблиці 1 наводимо порівняння шинних сигналів для обох шин, але для випадку, коли до майстер-контролера підключено не один, а два підпорядкованих пристрої.
Таблиця 1. Кількість портів для підключення двох slave- пристроїв SPI vs I2C
| Pin # | NodeMCU як Master Device | шина SPI | шина I2C |
|---|---|---|---|
| 1 | SCLK <-> SCLK / SCL | SCLK | SCL |
| 2 | MISO <-> MOSI / SDA | MOSI | SDA |
| 3 | MOSI <-> MISO / SDA | MISO | SDA |
| 4 | CS1 <-> CS1 / - | CS1 (slave1) | - |
| 5 | CS2 <-> CS2 / - | CS2 (slave2) | - |
| 6 (опц.) | INT <-> INT / INT | INT | INT |
Як видно з таблиці, головний контролер потребує лише два сигнальні канали (читай порти вводу-виводу) для взаємодії з двома пристроями на шині I2C, і навпроти, п’ять портів вводу-виводу знадобиться, у випадку вирішення аналогічної задачі з використанням шини SPI.
Як опцію, у таблиці наведено сигнал INT, що не входить до складу шин. Це сигнал зворотного зв’язку від підпорядкованих пристроїв до майстер-контролера і використовується для ініціювання переривання і запуску обробника подій на майстер-контролері. Наводимо сигнал через те, що його теж потрібно включати до бюджету обов’язкових у системі і резервувати під нього відповідний вивід контролера.
Примітка. Зауважте також, що виводи живлення VCC та GND у таблиці 1 не показано свідомо.
На додачу зазначимо, менша кількість інтерфейсних сигналів, автоматично означає менше роз’ємів та меншу кількість провідників, що в свою чергу зменшує кількість точок відмови.
Якщо вас зацікавило, на які саме виводи необхідно підключати SPI чи I2C пристрої до NodeMCU / ESP8266, рекомендуємо переглянути наш Стандарт планування та застосування пінів alterstrategy.com/recommended-pin-use-standard/
Гаряче приєднання і від’єднання
Шина I2C має дуже гарну властивість, яку ми свого часу перевірили на практиці і зараз використовуємо в усіх наших пристроях. Йдеться про можливість для користувача приєднувати та від’єднувати підпорядковані пристрої на ходу. Погодьтеся, що це дуже зручно і ба більше, буденно більшості користувачів. Спробуйте пояснити користувачеві, що сенсор температури не можна висмикувати з роз’єму, бо весь пристрій зависне.
Стосовно SPI. Як вже зазначалося, у випадку кількох пристроїв, майстер-контролер обов’язково має виконувати арбітраж сигналів CS1, CS2, CSn. Бо якраз через цей сигнал інтерфейсу, підпорядкований spi-пристрій дізнається, що потрібно обов’язково вивільнити MISO та почати ігнорувати що приходить каналом MOSI. Що буде відбуватися, коли користувач висмикне роз’єм підпорядкованого пристрою у довільний момент? – Треба перевіряти, але цей кейс точно не співпадає зі настановами із взаємодії пристроїв по шині SPI. Задач, що вимагають два і більше пристроїв на шині, буде багато, а тому варто враховувати ці особливості (недоліки закреслено).
Якщо вам цікаво почитати про проблеми, що виникають з кількома пристроями на шині SPI, рекомендуємо переглянути дану публікацію: “WHAT COULD GO WRONG: SPI”
Детектування підключення, відключення пристроїв та помилок
Оскільки шина I2C підтримує концепцію адресації підпорядкованих пристроїв, але не підтримує на рівні заліза подій підключення і відключення, то найперший доступний метод детектування підключеного до шини пристрою, полягає у періодичному опитуванні усіх присутніх майстер-пристроєм шляхом перебору всього пулу можливих адрес на шині. У відповідь на такий запит майстер-контролера, відкликається лише той пристрій, котрий отримав по шині свою адресу. Як результат опитування, майстер контролер має список наявних на шині адрес.
Це не складний і достатній метод, у поєднанні з можливістю “гарячої заміни”, легко може бути реалізовано для розумного пристрою.
Іншим методом є детектування через порт зворотного зв’язку INT, яким обладнано деякі підпорядковані пристрої. У своїй практиці ми зустрічали чимало пристроїв, котрі вміють генерувати переривання через INT для більшості важливих подій. Але, як ми зазначали вище, цей метод вартує резервування додаткового порту вводу-виводу контролера. З іншого боку, застосування каналу INT, вивільняє головний контролер і шину від необхідності постійного опитування, заощаджує пам’ять та ресурс батареї.
Детектування підключення чи відключення пристроїв і їх функцій без перевантаження, буде гарним UX/UI ходом з боку розробника і стане до вподоби користувачам.
Ідентифікація підключених пристроїв
Ба більше, підключення і відключення пристроїв онлайн, з нормальним відпрацюванням на апаратному рівні; ідентифікація пристрою та його функціональності в системі без перевантаження; може бути також доповнене точною ідентифікацією цих пристроїв.
Ніхто нам не заважає мати у файлі конфігурації перелік адрес пристроїв, що входять до складу системи. А тому, ми можемо магічним чином показувати користувачеві, що саме підключено чи відключено, або що не працює. З точки зору підтримки користувача, можемо засобами індикації надавати рекомендацію перевірити кабель саме ось того конкретного сенсора і так далі.
Висновок
Описані у цій статті можливості надихають на створення розумних (у прямому сенсі цього слова) пристроїв. Вірний вибір технологічної шини, відкриває можливості до побудови правильного дизайну, і навіть гейміфікації процесу експлуатації та деінде маркетингу.
Бажаємо вам успіху!
