Какие факторы следует учитывать при выборе встроенного wifi MCU для маломощного периферийного устройства?

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

В зависимости от применения в текущем продукте используется батарея 6 В постоянного тока емкостью от 1400 мАч до 2400 мАч. Устройство имеет чувствительный элемент малой мощности и исполнительный механизм. Полезная нагрузка, скорее всего, будет около 100 байтов. Частота общения будет примерно каждые две минуты во время пиковой активности. Благодаря достижениям в области IoT и рыночным требованиям этот PoC привлек к себе некоторое внимание.

По предложению нескольких поставщиков платформы IOT, я смотрю на беспроводной микроконтроллер CC3200 от Texas Instrument прежде всего потому, что он является преемником CC3100. На системном уровне, когда он не используется, питание CC3100 может быть полностью отключено. Это значительное преимущество для низкой мощности на уровне системы. Когда активность обнаружена, чувствительный элемент активирует микроконтроллер через прерывание. Есть и другие интегрированные микроконтроллеры Wi-Fi, такие как ESP8266 , BCM43362 , ATWINC1500B , 88MC200 и многие другие. Я использую результаты ULPBench, чтобы выполнить анализ первого порядка микроконтроллеров с низким энергопотреблением, а затем выполнить анализ, такой как описанный вКак выбрать микроконтроллер для приложений с низким энергопотреблением? чтобы помочь выбрать микроконтроллер с низким энергопотреблением. Я использовал такие параметры, как потребление тока в активном режиме на частоту и потребление тока в различных режимах с низким энергопотреблением, чтобы сделать осознанный выбор. Итак, чтобы сохранить опцию низкого энергопотребления и добавить возможность IoT, на какие критические параметры (возможно, связанные с беспроводной связью) я должен обратить пристальное внимание при выборе встроенного микроконтроллера Wi-Fi?

Ссылки:

• SimpleLink ™ CC3100 / CC3200 Wi-Fi Интернет на кристалле Подсистема управления питанием
• Как выбрать свой модуль Wi-Fi?

Поскольку вашим самым важным ограничением является низкое энергопотребление, я думаю, что вы уже обращаете внимание на 2 наиболее важных параметра: потребление тока в активном режиме на частоту и потребление тока в различных режимах с низким энергопотреблением.

Удерживая связь как постоянную (т. Е. Тот же протокол связи и частоту EM), затем выбор лучшего MCU - это просто вопрос правильного объединения этих двух параметров. И вот как я мог бы создать одно числовое значение, которое я мог бы сравнить по всем параметрам:

1. Создайте прогнозируемый профиль активности для устройства (как часто он общается и как долго) в течение периода, скажем, в течение недели.
2. Вычислить потребление тока на частоте ЭМ, используемое для времен за выбранный период, когда связь активна - т. Е. Потребление 10 мкА (при частоте 900 МГц) в течение 2 с при 1000-кратной активности в неделю будет означать 20 000 мкА-с / неделя.
3. Вычисление потребления тока для времен за выбранный период, когда устройство находится в режиме по умолчанию с низким энергопотреблением - то есть потребление 10 нА при [7 дней x 24 часа x 60 минут x 60 с - 1000 x 2 с активности] будет означать 6028 мкА -с / нед.
4. Добавление 2 дает 26 028 мкА-с / неделя для этого гипотетического MCU.
5. Это вычисленное еженедельное потребление тока затем можно сравнить для всех MCU.

Я знаю, что это очень упрощенный способ просмотра активности MCU - то есть только что рассмотрены 2 состояния: режим ожидания и связь ... но я верю, что любые другие состояния будут иметь пропорциональный и незначительный вклад в одно из этих 2. Например, использованная мощность поскольку вычисления (циклы инструкций) могут быть объединены вместе с состоянием связи и, скорее всего, будут иметь очень небольшой вклад с точки зрения мощности по сравнению с подсистемой связи. Дело в том, что рассмотрения этих двух состояний достаточно для процесса выбора.

Там нет волшебной пули, поэтому я думаю, что совет будет до боли очевидным. Сначала начните раскалываться с крупнейшими потребителями электроэнергии.

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

Если это привод, можете ли вы использовать более легкий двигатель или уменьшить трение в трансмиссии? Более масштабная картина: можете ли вы реорганизовать ведомую нагрузку, чтобы она имела меньшую массу или была лучше сбалансирована?

Если это общение, начните с рассмотрения частоты общения. Какие факторы привели к существующему «двухминутному» решению? Можете ли вы пойти на жертвы, чтобы общаться реже? Можете ли вы переключиться на модель pub-sub и отвечать меньшим количеством байтов, когда позволяют условия?

Переоцените протокол. Каждый байт, который вы бреете, представляет собой экономию в 1% от вашего текущего бюджета мощности RF. Отправка каких-либо логических значений? Используйте битовые флаги, а не ASCII 'Y' или 'N'. Убедитесь, что вы используете наименьший возможный контейнер - не передавайте 16-битное целое число, если допустимый диапазон числа составляет всего 0-99. Большинство протоколов с батарейным питанием стараются максимально сжать его; например, если вы сообщаете о массиве 5x5 элементов, адрес должен быть только 5-битным полем, а не 8-битным байтом. Использование циклов ЦП для логики, связанной со сжатием, приводит к гораздо меньшему потреблению общей мощности, чем передача ненужных битов.

Если большое энергопотребление - ЦП (сомнительно, но возможно), можете ли вы сделать трюки, такие как предварительно вычисленные таблицы поиска, или даже перенести часть работы на удаленный сервис?

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

Обратите особое внимание на предлагаемые состояния питания, рассматриваемые с точки зрения всей вашей системы (регуляторы, генераторы, преобразование сигналов датчиков). Возможно (маловероятно), что ваше 2-минутное активное состояние выиграет от менее глубокого сна, чем нормальное рабочее состояние.

Наименьшее полезное состояние должно составлять большую часть вашего потребления энергии. То, как это вам удастся, зависит от того, можете ли вы работать напрямую от источника питания без регулятора, минимального рабочего напряжения и т. Д.

Что касается активного состояния, рассмотрите наиболее интенсивную оперативную память или вычислительные операции и сравните их, используя ближайший эквивалент готовых частей, которые вы можете найти (в зависимости от процессора, скорости и архитектуры памяти). В вашем приложении кажется, что подготовка полезной нагрузки и шифрование могут быть довольно тривиальными, но в целом это не является очевидным предположением. Состояния хранения могут разрешать интеграцию датчика без сохранения / восстановления состояния, например.

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

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