Які фактори слід врахувати при виборі інтегрованого Wi-Fi MCU для малопотужного пристрою?

Мотивація цього питання випливає з того, що деякий час тому я створив простий доказ концепції (PoC) крайнього пристрою IoT за допомогою мікроконтролера та мережевого процесора CC3100 Wifi . Однією з проблем цього прототипу було те, що конфігурація потребувала значної кількості енергії. Таким чином, він не міг подолати переваги існуючого пристрою меншої потужності, який міг би прослужити більше 2 - 10 років залежно від вибору акумулятора та частоти використання.

Залежно від застосування, в поточному продукті використовується 6В постійного струму батарея ємністю від 1400 мАг до 2400 мАг. Пристрій має зондуючий елемент малої потужності та привідний механізм. Найімовірніше, що навантаження складе близько 100 байт. Частота спілкування буде приблизно кожні дві хвилини під час пікової активності. Завдяки прогресу в IoT та вимогах ринку цей PoC привернув певну увагу.

За пропозицією небагатьох постачальників платформи IOT я дивлюся на бездротовий MCU CC3200 від Texas Instrument насамперед тому, що він є спадкоємцем CC3100. На системному рівні, коли він не використовується, живлення CC3100 можна повністю відключити. Це суттєва перевага для малої потужності на системному рівні. При виявленні активності чутливий елемент прокидає мікроконтролер через переривання. Є й інші інтегровані модулі Wi-Fi MCU, такі як ESP8266 , BCM43362 , ATWINC1500B , 88MC200 та багато інших. Я використовую показники ULPBench, щоб зробити аналіз перших порядків мікроконтролерів низької потужності з подальшим аналізом, як описано вЯк вибрати мікроконтролер для додатка малої потужності? щоб вибрати мікроконтролер низької потужності. Я використовував такі параметри, як активний режим виведення струму на частоту та поточний малюнок різних режимів низької потужності, щоб зробити обгрунтований вибір. Отже, щоб підтримувати параметр низької потужності та додати можливості IoT, які критичні параметри (можливо, пов'язані з бездротовим зв’язком), на які слід звернути пильну увагу при виборі інтегрованого Wi-Fi MCU?

Список літератури:

• Wi-Fi SimpleLink ™ CC3100 / CC3200 Wi-Fi Інтернет-на-чіпі Мережева підсистема Управління живленням
• Як вибрати модуль Wi-Fi?

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

Витримуючи зв’язок як постійну (тобто той самий протокол зв'язку та частоту ЕМ), то вибір найкращого MCU - це лише питання належного об'єднання цих двох параметрів. Ось як я створив єдине числове значення, яке я міг би порівняти для всіх варіантів:

1. Створіть прогнозований профіль діяльності для пристрою (як часто він спілкується і на який термін) протягом періоду - скажімо, протягом тижня.
2. Обчислити поточний розіграш на частоті ЕМ, що використовується для часу протягом вибраного періоду, коли комунікація активна - тобто 10 мкА (частота 900 МГц) протягом 2 с при 1000 х активності в тиждень означатиме 20 000 мкА-с / тиждень.
3. Обчислити поточний розіграш для часу протягом вибраного періоду, коли пристрій перебуває у режимі низької потужності за замовчуванням - тобто нічия 10 нА за [7 днів x 24 год. X 60 хв. Х 60 с. - 1000 х 2 с активності] означало б 6288 АА -с / тиждень.
4. Додаючи 2 вихідні поточні розіграші 26,028 мкА / тиждень для цього гіпотетичного MCU.
5. Цей обчислений щотижневий розіграш поточного тиску можна порівняти для всіх MCU.

Я знаю, що це дуже спрощений спосіб перегляду діяльності MCU - тобто тільки що розглянуті два стани: простої та спілкування ... але я вважаю, що будь-які інші держави будуть пропорційно і незначно внести в одну з цих 2. Наприклад, витрачена потужність для обчислень (циклів інструкцій) можна поставити разом із станом зв’язку і, швидше за все, матимуть дуже малий внесок у потужності порівняно з підсистемою зв'язку. Справа в тому, що перегляд цих 2 станів є достатнім для процесу відбору.

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

Ви справді вимикаєте всі мікросхеми та мікросхеми, коли вони простоюють? Я знаю, що деякі дошки та щити для любителів не завжди повністю відключають все, що ви очікуєте.

Якщо це привід, чи можете ви використовувати легший двигун або зменшити тертя в приводному ходу? Більша картина, чи можете ви перепроектувати керований вантаж, щоб мати меншу масу, або бути краще збалансованим?

Якщо це комунікація, почніть з перегляду частоти комунікацій. Які чинники зумовили існуюче рішення "дві хвилини"? Чи можете ви зробити жертви, щоб спілкуватися рідше? Чи можете ви перейти на модель pub-sub і відповідати меншою кількістю байтів, коли умови дозволяють?

Переоцініть протокол. Кожен байт, який ви голите, означає економію 1% від вашого поточного бюджету на потужність РФ. Надсилання будь-яких булевих значень? Використовуйте бітові прапори, а не ASCII "Y" або "N". Переконайтеся, що ви використовуєте найменший можливий контейнер - не передайте 16-бітове ціле число, якщо число має допустимий діапазон лише 0-99. Більшість протоколів, що живлять акумулятор, намагаються максимально стиснути його; наприклад, якщо ви повідомляєте про масив елементів 5x5, адреса повинна бути лише 5-бітним полем, а не 8-бітовим байтом. Використання процесорних циклів для стиснення, пов'язаних із стисненням, призводить до набагато меншого загального енергоспоживання, ніж передача непотрібних біт.

Якщо велика потужність - це процесор (сумнівний, але можливий), чи можете ви робити хитрощі, як попередньо обчислені таблиці пошуку, або навіть перевантажувати якусь роботу на віддалений сервіс?

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

Зверніть пильну увагу на стан потужності, які пропонуються, з точки зору вашої всієї системи (регулятори, осцилятори, кондиціонування сигналу датчиків). Можливо (малоймовірно), що ваш 2-х хвилинний активний стан виграє від менш глибокого сну, ніж звичайний робочий стан.

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

Для активного стану розгляньте свої найбільш оперативні оперативні пам'яті або обчислюйте інтенсивні операції та порівняйте їх, використовуючи найближчі еквівалентні нестандартні деталі, які ви можете знайти (виходячи з архітектури процесора, швидкості та пам'яті). У вашій заявці здається, що підготовка корисного навантаження та шифрування може бути досить тривіальною, але загалом це не очевидне припущення. Стани утримування можуть дозволити інтеграцію датчиків без збереження / відновлення стану, наприклад.

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

Ви не будете знати абсолютного найкращого дизайну, поки не будете переглянуто більше одного дизайну - параметри занадто багато (і до цього часу ваш продукт починає старіти), тому аспекти вищого рівня в потоці дизайну все ще залишаються важливий. Якщо ви можете оптимізувати свою архітектуру для зменшення подій на 5%, це повинно бути помітно в режимі автономної роботи.