Простые устройства
Просто об устройствах

Интеллектуальное запирающее устройство с батарейным питанием и подключением к облаку

Запирающее устройство с батарейным питанием и интегрированным Wi-Fi на базе беспроводного МК CC3220S и драйвера двигателя постоянного тока DRV8837 – референсная разработка Texas Instruments.

Желание избавиться от громоздких ключей, контролировать замок, находясь в любом месте, и получать оповещения о состоянии входа в помещение стимулирует спрос на интеллектуальные запирающие устройства с подключением к интернету. Рассматриваемый пример демонстрирует, каким образом SimpleLink™ Wi-Fi® позволяет разрабатывать интеллектуальные замки с батарейным питанием со встроенным Wi-Fi для прямого подключения к интернету.

Особенности:

  • Расчетное время работы от батареи – 1 год 3 месяца с использованием четырех батареек типа АА без разрывов соединения
  • Прямое подключение к облаку, позволяющее осуществлять удаленный мониторинг и управление
  • Встроенное Wi-Fi-радио, сетевой процессор и МК для оптимизации разработки в части энергопотребления
  • Различные способы подключения к Wi-Fi – с помощью BLE, AP и Smart Config™
  • Широкий диапазон встроенных функций безопасности, необходимых для защиты приложений, подключенных к облаку:
    • безопасная загрузка образа МК;
    • внутренний HTTPS-сервер для раздачи через AP;
    • MQTT через TLS с брокером интернета вещей (IoT) Eclipse;
    • безопасная беспроводная загрузка (OTA) с использованием Dropbox™;
    • уникальный 128-битный идентификатор устройства.
  • Драйвер двигателя с интегральными FET-транзисторами, позволяющий реализовать простой и компактный проект с минимальным количеством дискретных компонентов

Области применения:

  • Электронные интеллектуальные запирающие устройства
  • Дверные тач-панели и считыватели 

Описание системы

Данная референсная разработка демонстрирует, как создать электронное интеллектуальное запирающее устройство с батарейным питанием с интегрированным Wi-Fi. Этот проект показывает, как может быть использован беспроводной МК (SoC) SimpleLink Wi-Fi CC3220S в качестве основного системного контроллера и сетевого процессора для создания высокоинтегрированного изделия. В разработке TIDC-01005 CC3220S используется совместно с DRV8837 – низковольтным драйвером коллекторного двигателя постоянного тока на 1,8 А для формирования ядра электронного запирающего устройства, оснащенного Wi-Fi. В проекте также представлен беспроводной МК с Bluetooth® CC2640R2F для демонстрации подключения к Wi-Fi через BLE. В проекте используются комплекты разработки LaunchPad™ и DRV8837EVM, благодаря которым оценка и воспроизведение дизайна становится простой задачей. Программное обеспечение для TIDC-01005 основано на SDK SimpleLink, благодаря чему обеспечивается максимальная портируемость в рамках платформы SimpleLink.

TIDC-01005 может быть подключен к точке доступа (AP) Wi-Fi с использованием как SimpleLink SDK Explorer, так и мобильного приложения SimpleLink Wi-Fi Starter Pro. Когда разработка подключается к AP, она устанавливает безопасное соединение с облаком, что позволяет пользователю удаленно управлять запирающей системой и наблюдать за ее состоянием. Интеграция Wi-Fi в замок исключает необходимость в формировании отдельного беспроводного моста для соединения системы с сетью Wi-Fi и экосистемой IoT. Кроме демонстрации удаленного доступа к запирающей системе, TIDC-01005 показывает, как CC3220S может быть использован для реализации быстродействующего OTA-обновления ПО замка, а также демонстрирует применение нескольких устройств CC3220S в качестве средств обеспечения безопасности.

Двумя основными требованиями для TIDC-01005 были способность работы с низким потреблением мощности и наличие интегрированных функций безопасности. Возможность поддержки Wi-Fi-соединения при малом потреблении является критичной для электронных запирающих устройств, оснащенных Wi-Fi, поскольку они, в основном, питаются от батарей. Помимо этого, в проекте электронного интеллектуального запирающего устройства должны быть предусмотрены различные функции безопасности, которые гарантируют надежную работу компонента в рамках системы контроля доступа. TIDC-01005 демонстрирует, как достичь очень малого значения потребляемого тока с использованием CC3220S при создании системы, которая всегда подключена к сети Wi-Fi. В проекте также показаны ключевые особенности функций безопасности:

  • Безопасная загрузка кода приложения
  • Раздача через AP с использованием аутентификации WPA2 и HTTPS
  • Раздача Wi-Fi с безопасным простым сопряжением через BLE
  • Безопасные сокет-соединения с облаком для обмена сообщениями и обновлений OTA
  • OTA-обновления с использованием нескольких средств обеспечения безопасности, таких как:
    • проверка целостности файлов;
    • верификация подписи;
    • защищенные файлы;
    • пакетная защита.

Многие функции, реализованные в приложении TIDC-01005, основаны на прикладных библиотеках работы с сетью, доступных в SimpleLink SDK, включая SNTP, MQTT и HTTP. Данные протоколы, а также функции для реализации ПО, применимы во многих других системах автоматизации зданий, имеющих связь по Wi-Fi. В частности, многие части разработки TIDC-01005 могут применяться в проектах дверных тач-панелей и считывателей.

Блок-схема TIDC-01005 приведена на рисунке 1.

Рис. 1. Блок-схема TIDC-01005

Рис. 1. Блок-схема TIDC-01005

Референсная разработка TIDC-01005 показывает, как создать малопотребляющее решение на основе микроконтроллера (с подсистемой связи по Wi-Fi), который управляет драйвером двигателя электронного интеллектуального запирающего устройства. TIDC-01005 также демонстрирует вариант подключения к Wi-Fi-сети через задание первоначальных настроек посредством BLE и использование интерфейса I2C для взаимодействия с блоком MEMS-датчиков IMU.

От системы требуются максимальное время автономной работы и малая стоимость обслуживания. В существующих системах с батарейным питанием требование энергоэффективности часто затрудняет использование новых беспроводных интерфейсов связи, таких как Wi-Fi, BLE или Sub-1GHz. Внедрение беспроводных интерфейсов связи может также вызвать проблемы, связанные с обеспечением безопасности системы. Из-за этого оба требования – по низкому энергопотреблению и наличию встроенных функций безопасности – были приняты в качестве наиболее приоритетных для устройств, использованных в данном проекте. Система-на-чипе SimpleLink Wi-Fi и IoT CC3220 позволяет разрабатывать электронные интеллектуальные запирающие устройства, дверные тач-панели и считыватели, благодаря продвинутой архитектуре, специально разработанной для малопотребляющих Wi-Fi-устройств с большим набором интегрированных средств безопасности.

Кроме упомянутых требований к SoC CC3220, важным было и требование легкого перехода на другие стандарты связи. Портируемость также имеет большое значение, поскольку конкретная реализация системы связи зависит от рынка и целевого сценария использования. Электронные интеллектуальные запирающие устройства, дверные тач-панели и считыватели могут использоваться как в офисных, так и в жилых зданиях, каждое из которых имеет свои сложности в обеспечении связи. Для гибкости применения и достижения максимального уровня повторного использования с разными технологиями в качестве основы ПО проекта был выбран SimpleLink Software Development Kit (SDK). SimpleLink SDK включает как общий интерфейс с RTOS, так и набор драйверов аппаратной части и сетевых служб для различных проводных и беспроводных решений связи на основе платформы SimpleLink. Все сетевые службы, использованные в демонстрации дверного замка с Wi-Fi, построены на основе библиотеки SlNetSock, которая позволяет портировать ключевые функции работы с сетью на различные сетевые стеки (например, драйвер SimpleLink Wi-Fi или Ethernet NDK).

Представленная референсная разработка построена на базе микросхемы Wi-Fi-микроконтроллера CC3220S, беспроводного BLE-микроконтроллера CC2640R2F и низковольтного драйвера DRV8837 для коллекторного двигателя постоянного тока до 1,8 А.

Микросхема CC3220 — часть платформы SimpleLink MCU, поддерживающей Wi-Fi, Sub-1Ghz и хост-МК. Для нее имеется общая простая в использовании среда разработки (SDK) и большой набор инструментов. Достаточно один раз интегрировать платформу SimpleLink MCU в изделие, чтобы потом при различных изменениях добавлять любое сочетание микросхем из этого набора, со 100% повторным использованием кода.

Начните разработку для IoT с однокристальной Wi-Fi-сертифицированной микроконтроллерной SoС со встроенной поддержкой связи по Wi-Fi. Семейство устройств SimpleLink CC3220x, созданное для IoT, является однокристальным решением с двумя физически независимыми МК на борту. Микросхема имеет как прикладной процессор на основе микроконтроллера ARM Cortex-M4 с 256 кбайт пользовательской RAM и опциональной XIP Flash 1 Мбайт, так и сетевой процессор, на котором выполняются все логические уровни Wi-Fi и интернет-соединений. Эта система на основе ROM содержит радио стандарта 802.11b/g/n, и включает MAC-уровень с мощным криптоускорителем для  безопасного скоростного выхода в интернет с 256-битным шифрованием.

Семейство CC3220x — часть второго поколения семейства решений интернет-на-чипе от Texas Instruments. В этом семействе представлены новый функционал и возможности, которые еще больше упрощают соединение устройств с интернетом, среди них:

  • IPv6
  • Улучшенное подключение к Wi-Fi
  • Уменьшенное потребление энергии
  • Повышенная безопасность файловой системы (поддерживается только устройствами CC3220S и CC3220SF)
  • Режим точки доступа с подключением до четырех станций
  • Большее количество BSD-сокетов, открытых одновременно: до 16 сокетов, 6 из которых защищенные
  • Поддержка HTTPS
  • Поддержка RESTful API
  • Библиотека шифрования с несимметричными ключами

Данные МК поддерживают топологии «станция», «точка доступа» (AP) и «Wi-Fi Direct». Устройство также поддерживает частную и корпоративную безопасность WPA2. Подсистема включает встроенные стеки TCP/IP и TLS/SSL, HTTP-сервер и многие интернет-протоколы. На устройстве реализуются многие способы раздачи Wi-Fi, включая HTTP на основе режима AP, технологию Smart Config и WPS2.0.

Подсистема управления питанием имеет интегрированные DC/DC-преобразователи, поддерживающие широкий диапазон питающих напряжений. В данной подсистеме реализованы такие режимы малого потребления как режим глубокого сна, гибернация с RTC (с потреблением всего 4,5 мкА) и режим выключения (с потреблением лишь 1 мкА).

Устройство оснащено большим количеством периферии, включая быстрый параллельный интерфейс камеры, I2S, SD, UART, SPI, I2C и 4-канальные АЦП.

Семейство устройств SimpleLink CC3220x доступно в трех различных вариантах микросхем: CC3220RCC3220S и CC3220SF. Чипы CC3220R и CC3220S имеют 256 кбайт выделенной для приложений встроенной RAM для кода и данных, ROM с внешним загрузчиком из последовательной Flash-памяти и драйверы периферии. Устройство CC3220SF имеет 1 Мбайт выделенной для приложений XIP Flash и 256 кбайт RAM для кода и данных, ROM с загрузчиком для внешней Serial Flash, драйверы периферии. Варианты CC3220S и CC3220SF имеют дополнительные функции безопасности, такие как шифрованные и аутентифицированные файловые системы, шифрование и аутентификация IP пользователя, защищенная загрузка (аутентификация и проверка целостности образа приложения на Flash во время загрузки) и так далее.

Семейство устройств CC3220x – это полное платформенное решение, включающее ПО, примеры приложений, руководства пользователя и программиста, референсные разработки и онлайн-сообщество E2E. Семейство микросхем СС3220x также является частью номенклатуры SimpleLink MCU и поддерживает экосистему разработчика SimpleLink.

Микросхема CC2640R2F – это беспроводной микроконтроллер, предназначенный для задач с Bluetooth 4.2 и Bluetooth 5 Low Energy. Микроконтроллер является членом линейки эффективных сверхмаломощных 2,4-ГГц-устройств SimpleLink CC26xx. Сверхмалые токи активных режимов работы радиомодуля и микроконтроллера, а также потребление тока в режиме малой мощности дают возможность длительного времени работы от батарей и позволяют использовать небольшие плоские батареи, а также устройства сбора энергии (Energy Harvesting). SimpleLink BLE CC2640R2F содержит 32-битное ядро ARM Cortex-M3, работающее с частотой 48 МГц, в качестве основного процессора, и обширный набор периферии, в состав которой входит уникальный сверхмаломощный контроллер датчиков. Данный контроллер идеален для работы со внешними датчиками и автономного сбора аналоговых и цифровых данных, пока остальная система находится в спящем режиме. Таким образом, CC2640R2F оптимален для решения большого круга задач, в которых важны длительный период работы от батареи, небольшой форм-фактор и простота использования. Системы контроля питания, тактирования, а также радиосистема беспроводного МК CC2640R2F требуют особой настройки и управления со стороны ПО для корректного функционирования, и этот функционал уже встроен в TI-RTOS. Компания Texas Instruments рекомендуют использовать данный фреймворк для разработки всех приложений с использованием устройства. Контроллер Bluetooth Low Energy и хост-библиотеки хранятся в ROM и частично выполняются на выделенном процессоре ARM Cortex-M0 в блоке радио. Данная архитектура позволяет улучшить общие показатели системы и потребление мощности, при этом освободив значительное количество Flash-памяти для приложения разработчика.

Семейство DRV883x — интегральное решение драйвера двигателя для поворотных камер, потребительских устройств электроники, игрушек и других низковольтных применений с управлением движением, питающихся от батарей. Устройство может управлять двигателем постоянного тока либо другими устройствами, например, соленоидами. Выходной каскад драйвера состоит из силовых N-канальных MOSFET, образующих Н-мост для управления обмоткой мотора. Внутренний генератор накачки заряда формирует необходимые напряжения для управления затворами.

Семейство устройств DRV883x может обеспечить до 1,8 А выходного тока. Устройство функционирует при напряжениях питания двигателя 0…11 В, а напряжение питания самого устройства лежит в диапазоне 1,8…7 В. DRV8837 имеет входной PWM-интерфейс (IN1-IN2), а DRV8838 управляется парой PH-EN. Оба интерфейса совместимы с устройствами промышленного стандарта. Внутренние функции по аварийному отключению реализованы для защиты от превышения тока, короткого замыкания, блокировки при недостаточном напряжении и перегреве.

Теоретическая часть проекта 

Интерфейс между CC3220S и CC2640R2F

CC2640R2F используется в TIDC-01005 для выбора Wi-Fi-сети и ввода пароля через интерфейс BLE. В данном проекте CC3220S играет роль основного контроллера системы (простой прикладной процессор или SAP), а CC2640R2F выступает в качестве сетевого BLE-процессора (простого сетевого процессора или SNP). Использование решения на основе SAP и SNP упрощает разработку, так как позволяет абстрагироваться от протокола BLE и реализовать функционал BLE посредством отправки предопределенных команд в CC2640R2F по унифицированному интерфейсу сетевого процессора (NPI) от TI.

В качестве последовательного протокола обмена NPI поддерживает как UART, так и SPI, но в TIDC-01005 реализован только UART. В дополнение к используемым стандартным линиям данных TX и RX UART, NPI также задействует три дополнительных сигнала между процессорами, что дает хосту возможность производить сброс SNP и индикацию готовности устройства к отправке или приему данных. Данные дополнительные сигналы называются RESET, Master Ready (MRDY) и Slave Ready (SRDY).

Взаимодействие между CC3220S и DRV8837

Драйвер коллекторного двигателя постоянного тока DRV8837 используется для формирования контролируемого тока двигателя. В рамках данного проекта для управления DRV8837 CC3220S задействует трехвыводной интерфейс, состоящий из двух сигналов GPIO и одного сигнала PWM. На рисунке 2 показана упрощенная схема интерфейса между CC3220S и DRV8837, где в качестве контроллера выступает МК CC3220.

Рис. 2. Упрощенная схема подключения DRV8837

Рис. 2. Упрощенная схема подключения DRV8837

DRV8837 ведет себя в соответствии со входной схемой PWM-сигнала, называемой интерфейсом IN-IN. В рамках данного проекта управляющий интерфейс настроен таким образом, что один вывод GPIO CC3220 используется для управления IN1, а PWM контролирует IN2 (таблица 1).

Таблица 1. Управляющие сигналы на входах DRV8837/8

nSLEEP IN1 IN2 Результат
0 Х Х Движение по инерции
1 0 0 Движение по инерции
1 0 1 Обратное направление вращения
1 1 0 Прямое направление вращения
1 1 1 Торможение

В коде ПО TIDC-01005 выводы P16 и P17 соответствуют выводам IN1 и IN2 соответственно. P16 конфигурируется как стандартный GPIO, а P17 настраивается в качестве выхода PWM. Вывод P18 CC3220 настраивается как GPIO и подключается к выводу nSLEEP DRV8837. При прямом вращении двигателя на оба вывода P18 (nSLEEP) и P16 (IN1) подается логический высокий уровень, а для вращения мотора на постоянной скорости скважность импульсов на выходе PWMP17 (IN2) фиксируется. Посредством изменения скважности импульсов на P17 при высоком уровне на P16 мотор переключается между прямым направлением вращения и торможением, что позволяет реализовать прямое вращение с управляемой скоростью. Для придания двигателю обратного вращения P18 (nSLEEP) устанавливается в логическое высокое состояние, а P16 (IN1) удерживается в логически низком состоянии. Таким образом, выход PWM на P17 установлен для фиксированной скважности. При управлении скважностью на P17 при низком уровне на P16 двигатель переключается между режимами реверса и холостого хода, что позволяет ему вращаться в обратном направлении с контролируемой скоростью. 

Архитектура программного обеспечения

ПО, поставляемое для TIDC-01005, является многопоточным приложением на основе ранее выпущенных наборов ПО CC3220 SDK, SimpleLink SDK BLE Plugin и Sensorand Actuator Plugin. ПО TIDC-01005 использует TI-RTOS для поддержки многопоточности и TI-Drivers в качестве первичного интерфейса управления аппаратной периферией (например, модулями обмена данными, таймерами и цифровыми входами/выходами). На рисунке 3 показана общая структура программного обеспечения.

Рис. 3. Структура ПО дверного замка с Wi-Fi

Рис. 3. Структура ПО дверного замка с Wi-Fi

Программное обеспечение TIDC-01005 демонстрирует многие функции, поддерживаемые проектом электронного интеллектуального запирающего устройства с Wi-Fi, включая управление драйвером двигателя для приведения запорной части в движение, чтение данных с датчиков, управление соединением по Wi-Fi (включая процедуру подключения), отправку и получение сообщений через облако, обновление программного обеспечения по эфиру. Каждая из этих функций управляется различными программными модулями приложения, где каждый модуль состоит из одной и более служб TI-RTOS. В дополнение к службам, предназначенным для каждой функции, ПО содержит общий модуль дверного замка с Wi-Fi, отвечающий за создание всех остальных потоков, и управляющий модуль, обрабатывающий такие запросы системного уровня как, например, сигналы сброса. Деление ПО на отдельные блоки и распределение индивидуальных сервисов для каждой функции помогает сделать разработку более модульной, благодаря чему она может быть с легкостью изменена для других задач. В таблице 2 приведено описание каждого программного модуля и связанных с ним файлов исходного кода.

Таблица 2. Программные модули дверного замка с Wi-Fi

Модуль Файлы исходных кодов Описание
Модуль приложения дверного замка с Wi-Fi wifi_doorlock_app.h/.c Запускает приложение дверного замка с Wi-Fi, инициализируя систему, и создает потоки
Модуль управления control_task.h/.c Обрабатывает запросы системного уровня, такие как сигналы сброса
Управление соединением Wi-Fi network_if.h/.c Подключает CC3220 к AP на основе профилей или принимает события процедуры начального подключения
Раздача Wi-Fi provisioning_task.h/.c Начинает или останавливает процесс начального подключения и выполняет автомат состояний для обработки событий этого процесса
MQTT-клиент mqtt_client_task.h/.c и mqtt_client_cbs.h/.c Выполняет клиент MQTT, принимает входящие MQTT-сообщения, публикует сообщения MQTT для сигнализации о состоянии устройства и запускает события на основе сообщений MQTT
Wi-Fi OTA cloud_ota_task.h/.c Выполняет автомат состояний обновления по эфиру OTA
Контроллер двигателя motor_driver_if.h/.c Управляет двигателем на основе сообщений MQTT, полученных из облака
Сенсорный модуль bmi160_support.h/.c Если доступен, настраивает инерциальный модуль и считывает с него данные от MEMS-датчиков

На рисунке 4 изображена общая схема работы программного обеспечения, производящего инициализацию системы и создание всех программных задач.

Рис. 4. Общая схема работы программы

Рис. 4. Общая схема работы программы

Управление сетевым подключением

Подключение к локальной сети (CC3220 к AP) в TIDC-01005 обслуживается независимо от службы начального подключения к Wi-Fi. Причина этого разделения состоит в том, что нет необходимости выбирать имя сети и вводить пароль каждый раз, когда происходит попытка подключения к Wi-Fi. Профиль, хранящийся во внешней последовательной Flash-памяти СС3220S, используется для подключения системы к ранее выбранной Wi-Fi-сети в большинстве попыток подключения. Кроме того, управление подключением было реализовано как отдельный поток, так как процедура начального подключения (Wi-Fi Provisioning) не должна автоматически включаться при неудачной попытке автоматического подключения к сети на основе сохраненного профиля.

Когда сетевое подключение установлено и поток выполняется, он, в первую очередь, осуществляет проверку на наличие сохраненного в последовательной Flash-памяти профиля. Если профиль отсутствует, система будет считать, что попытка автоматического подключения потерпит неудачу и, следовательно, перейдет к одному из доступных режимов начального подключения. Если же профиль существует, поток ожидает заведомо определенное количество времени для проверки результата автоматического подключения к AP на основе сохраненного профиля. Если подключение успешно установлено, поток подключения переходит в спящий режим и будет в нем находиться до тех пор, пока не произойдет событие отключения. Если устройство не подключается к AP на основе сохраненного профиля, система выдержит паузу определенной длительности перед новой попыткой подключения. Причиной, по которой система сначала пребывает в ожидании, является вероятность того, что AP, описываемая сохраненным профилем, существует, но была неактивна либо находится вне зоны доступа во время попытки подключения.

Сервис подключения к сети также отвечает за инициацию процедуры начального подключения. Когда производится первый запуск системы пользователем либо сброс к заводским настройкам, в последовательной Flash-памяти нет профилей. Следовательно, один из вариантов начального подключения (АP, Smart Config или BLE) должен запуститься до того, как система будет использована по назначению. При отсутствии профилей процесс начального подключения запускается службой сетевого подключения.

На рисунке 5 показан автомат состояний управления сетевым подключением.

Рис. 5. Граф автомата состояний потока управления сетевым подключением

Рис. 5. Граф автомата состояний потока управления сетевым подключением

Первоначальное подключение к Wi-Fi

TIDC-01005 – это система без пользовательской панели управления, как и большинство электронных интеллектуальных замков. В ней отсутствует традиционный пользовательский интерфейс (например, клавиатура, дисплей и тому подобное), при этом она должна каким-либо образом получить SSID и пароль Wi-Fi-сети, к которой замок будет подключаться. TIDC-01005 поддерживает несколько методов первоначального подключения, включая вариант «работа в качестве точки доступа (AP)», Smart Config от TI и вариант задания SSID и пароля через BLE. CC3220 способен выполнять режимы AP и Smart Config одновременно, что избавляет пользователя от необходимости ручного переключения между этими режимами. Получение настроек сети через BLE недоступно во время режимов AP и Smart Config, поэтому пользователю необходимо переключаться между этими режимами вручную.

Получение настроек сети через AP является наиболее распространенным методом. В этом варианте электронный замок сам временно создает свою собственную Wi-Fi-сеть, то есть выступает в качестве точки доступа (AP). Данный метод позволяет таким устройствам как смартфон, планшет или ПК подключиться к AP по Wi-Fi и передать информацию о желаемом будущем сетевом подключении напрямую в устройство. CC3220 принимает идентификационные данные сети через Restful API при помощи собственного HTTP-сервера.

Важно защитить соединение между устройством, отправляющим идентификационные данные сети, и CC3220 во время получения настроек сети через AP. Для защиты этих данных и чтобы удостовериться, что пользователь по ошибке не отправляет их другому устройству, TIDC-01005 задействует WPA2-аутентификацию при подключении станции к AP CC3220. TIDC-01005 также сконфигурирован для переадресации входящих соединений на защищенный HTTPS-порт и установки сессии TLS, в рамках которой передаются идентификационные данные.

Smart Config – это проприетарный способ раздачи от TI, использующий смартфон или планшет для широковещательной передачи идентификационных данных сети WiFi устройству TI. Неподключенное устройство может сканировать эфир на предмет широковещательных пакетов Smart Config во время работы в режиме станции или AP.

CC3220 имеет интегрированный код, необходимый для работы AP и получения настроек сети через Smart Config в микропрограмме сетевого процессора. Это избавляет пользователя от выделения значительного количества памяти приложения для этой первоначальной процедуры. Вместо этого в приложении необходимо выполнить следующее:

  • отправить команду старта процесса первоначального подключения сетевому процессору;
  • обработать асинхронные события во время раздачи;
  • остановить первоначальное подключение по завершении процесса.

Для управления процессом первоначального подключения в приложении важно понимать внутреннюю последовательность операций сетевого процессора. Когда первоначальное подключение запускается впервые, CC3220 переходит в состояние конфигурирования, в котором ожидает приема параметров сети. После получения параметров устройство осуществляет попытку подключения к сети и дает обратную связь пользователю в случае успеха.

В примере кода wifi_doorlock режимы «AP и Smart Config» управляются выделенной для этого задачей. Эта задача остается в состоянии Idle до того момента, когда процедура первоначального подключения будет запущена задачей «network connection». Когда автомат состояний первоначального подключения запущен, задача «AP и Smart Config» переводит сетевой процессор в режим «provisioning state» и обрабатывает асинхронные запросы до тех пор, пока система не будет успешно подключена к сети (рисунок 6). В случае перезапуска приложения система всегда будет пытаться подключиться к сети, используя сохраненный профиль и пропустить процесс первоначального подключения, если это возможно.

Рис. 6. Автомат состояний сервиса первоначального подключения

Рис. 6. Автомат состояний сервиса первоначального подключения

Второй метод первоначального подключения к Wi-Fi – получение настроек Wi-Fi через BLE. Основным преимуществом использования BLE является то, что для пользователя это более простая и привычная процедура с использованием смартфона или планшета. Для одной из мобильных операционных систем ввод настроек сети через AP потребует от пользователя следующих действий:

  • открыть приложение настройки, отключить в нем мобильное устройство от используемой на данный момент сети Wi-Fi;
  • подключиться к Wi-Fi от точки доступа AP, созданной подключаемым электронным замком;
  • ввести идентификационные данные той сети Wi-Fi, к которой потом должен подключиться электронный замок;
  • перейти обратно к исходной сети Wi-Fi, чтобы убедиться, что процедура начальной настройки успешна.

При раздаче через BLE процесс может быть успешно выполнен даже без вмешательства пользователя с целью изменить Wi-Fi-сеть на ту, к которой подключено мобильное устройство. Процесс начальной настройки через BLE имеет следующую последовательность:

  1. начинается поиск устройств BLE;
  2. узел подключается к устройству BLE и проходит аутентификацию с кодовым словом;
  3. пользователь записывает SSID, Ключ безопасности и Имя устройства в соответствующие поля характеристик BLE;
  4. пользователь записывает значение 0x01 в поле Provisioning Start для сигнализации о том, что должен быть проверен новый профиль;
  5. CC3220S отключается от BLE, считывает значения, записанные в поля характеристик, запускает сетевой Wi-Fi-процессор и делает попытку подключиться с этим профилем;
  6. CC3220S ожидает получения IP-адреса, после чего отключает Wi-Fi и останавливает сетевой Wi-Fi-процессор;
  7. запускается рестарт поиска устройств BLE;
  8. мобильное устройство переподключается к системе через BLE и считывает значение Provisioning Status (успех или ошибка);
  9. в случае успеха CC3220 добавляет информацию о сети Wi-Fi как сохраняемый профиль, покидает состояние раздачи, после чего подключается к сети Wi-Fi.

Даже в том случае, если весь процесс, реализованный в системе, потребует больше шагов, для пользователя это будет проще, так как ему необходимо предпринять лишь действия пунктов 2, 3 и 4.

В приложении TIDC-01005 начальная настройка через BLE реализована с использованием модифицированной версии примера из SimpleLink SDK Bluetooth Plugin. В программном обеспечении TIDC-01005 поток BLE выделен для обслуживания обмена данными с CC2640R2F на время подключения системы. Поскольку в системе не предусмотрен аппаратный режим совместной работы Wi-Fi и BLE, сетевой Wi-Fi-процессор в приложении отключается на период активности интерфейса BLE, и работа BLE останавливается, пока активен Wi-Fi. Для обеспечения раздельности BLE и Wi-Fi все операции, связанные с Wi-Fi, например, проверка принятых идентификационных данных, обрабатываются службой сетевого интерфейса вместо службы начального подключения через BLE (рисунок 7).

Рис. 7. Граф первоначального подключения к Wi-Fi получением настроек через BLE

Рис. 7. Граф первоначального подключения к Wi-Fi получением настроек через BLE

Отправка и прием сообщений через облако

После того как плата референсной разработки TIDC-01005 успешно подключилась к сети с доступом к интернету, устройство задействует протокол Message Queue Telemetry Transport, или MQTT (транспортный протокол сообщений телеметрии) для отправки сообщений и их получения из облака. Отправка и получение сообщений через облако делает возможным мониторинг и управление системой из любого места, пока у пользователя есть доступ к интернету. Для управления системой пользователь просто отправляет в систему сообщение через облачный сервер с другого клиента, такого как смартфон, планшет или ПК. Когда облачный сервер получает сообщение, предназначенное для конкретного конечного устройства, он пересылает устройству данное сообщение. Система TIDC-01005 также обладает возможностью отправки команд обновлений состояния клиентам, которые делали запрос об этом через облачный сервер (то есть при открытии замка одним членом семьи другие могут получить автоматическое уведомление на свой смартфон).

В референсной разработке замок может управляться (запираться/отпираться) посредством отправки сообщений на CC3220 через облако. Состояние замка («заперто» или «открыто») может быть проверено запросом к облаку (считывание нового состояния замка). По умолчанию ПО, поставляемое вместе с TIDC-01005, использует для обработки обмена сообщениями через облако открытый брокер Eclipse IoT MQTT. Однако при создании реального запирающего устройства на основе TIDC-01005 облачный брокер должен быть обновлен пользователем до конечной рабочей версии.

MQTT – это легкий протокол связи «машина-машина». MQTT основывается на модели обмена сообщениями публикации/подписки и разработан для использования поверх протокола TCP/IP. Ключевым преимуществом MQTT является то, что он не требует большого объема памяти и пропускной способности сети. Также MQTT обеспечивает быстрое время отклика и простоту масштабирования для приложений с необходимостью малого энергопотребления. Данные особенности делают MQTT идеальным протоколом обмена для встраиваемых решений обеспечения связи, питающихся от батарей, таких как электронные интеллектуальные замки и дверные тач-панели и считыватели.

Для обмена данными с облаком TIDC-01005 использует библиотеку MQTT client из SDK SimpleLink Wi-Fi CC3220. При создании приложения на основе библиотеки MQTT за реализацию функционала клиентской части MQTT будут ответственны два программных потока: основной поток MQTT и поток MQTT client. Основной поток MQTT настраивает параметры соединения MQTT, устанавливает соединение с брокером MQTT, создает поток MQTT client и затем обрабатывает все сообщения, полученные через функции обратного вызова (callbacks) MQTT client. В потоке MQTT client выполняется служба, реализованная в библиотеке MQTT и предназначенная для получения входящих сообщений от соединения MQTT и дальнейшей их передачи в функцию обратного вызова MQTT client.

В рамках TIDC-01005 служба MQTT client реализована в виде автомата состояний, который ожидает подключения системы к локальной сети и затем осуществляет попытку подключения к брокеру MQTT. Когда система подключена к локальной сети и брокеру, служба MQTT запускает обработку принятых сообщений в главном цикле. Главный цикл потока MQTT (состояние соединения клиента MQTT) подразумевает пользовательскую модификацию, в зависимости от нужд приложения. На рисунке 8 изображена схема автомата состояний службы MQTT client.

Рис. 8. Главный цикл потока MQTT

Рис. 8. Главный цикл потока MQTT

Когда система успешно переходит в состояние MQTT Connected, служба MQTT client TIDC-01005 начинает функционировать в качестве интерфейса для предоставления пользователю доступа к электронному интеллектуальному замку через облако. В TIDC-01005 клиентская служба использует сообщения по нескольким темам MQTT для обеспечения удаленного управления системой.

Сообщения, полученные клиентом, обрабатываются в соответствии с деревом решений, показанным на рисунке 9.

Рис. 9. Обработка сообщений MQTT

Рис. 9. Обработка сообщений MQTT

Обновления по беспроводному каналу

OTA – вид обновления программного обеспечения, при котором оно загружается в систему по воздуху, а затем устанавливается. Системы с Wi-Fi могут получать обновления ПО напрямую с облачных серверов, что облегчает поставщикам задачу распространения обновлений ПО сразу для большого количества устройств, физически расположенных в различных регионах.

Важным для всех продуктов, подключаемых к пирам через интернет, является поддержка обновлений ПО, необходимых, чтобы все компоненты программного обеспечения, отвечающие за функции безопасности, оставались актуальными в течение всего срока службы программного продукта. Например, со временем может возникнуть необходимость обновления файлов, нужных для поддержки аутентификации TLS и интернет-подключения к пирам. Помимо поддержки жизненного цикла безопасности продукта, обновления программного обеспечения также позволяют разработчикам добавлять новые функции для конечных потребителей уже после продажи продукта.

SDK SimpleLink Wi-Fi содержит библиотеку OTA, которая может быть использована для быстрой реализации обновлений OTA в приложении. Библиотека включает поддержку API как Dropbox, так и GiHub, и при этом может быть модифицирована для поддержки альтернативных сетей доставки контента (CDN). TIDC-01005 демонстрирует решение OTA-обновлений для электронного интеллектуального WiFi-замка с использованием библиотеки OTA с API Dropbox.

Процесс OTA в приложении дверного замка с Wi-Fi реализован в виде программной службы, выполняемой в собственном автомате состояний. Когда запускается служба OTA, пользователю будет запрещено инициировать обновление OTA до тех пор, пока система не произведет успешное подключение к локальной сети и не получит IP-адрес. Когда система подключена, служба переходит в ждущий режим, в котором находится до тех пор, пока OTA-обновление не будет инициировано пользователем. Пользователь может запустить OTA-обновление с использованием MQTT, опубликовав сообщение для устройства CC3220 по теме Lock OTA. Когда служба OTA запущена, она переходит в состояние OTA Run, в котором скачивает компоненты обновления ПО и записывает их в файловую систему до тех пор, пока обновление не будет скачано полностью. После того как все компоненты загружены и сохранены во внешней последовательной Flash-памяти, служба OTA отправляет управляющей службе запрос на сброс для инициации перезагрузки системы и выполнения загруженного ПО. На рисунке 10 показан граф автомата состояний, реализующего сервис OTA.

Рис. 10. Автомат состояний службы OTA

Рис. 10. Автомат состояний службы OTA

Библиотека OTA, используемая в данном примере, реализует клиент HTTP, который поддерживает Dropbox API и может быть использован для загрузки обновлений ПО. Исходные файлы для реализации простого клиента HTTP – это файлы OtaHttpClient.h/.из библиотеки OTA. 

Средства обеспечения безопасности

Продукты и системы IoT, такие как электронные интеллектуальные запирающие устройства, могут содержать частную или ограниченную информацию или обмениваться ею, поэтому безопасность – важное требование проекта. Частная информация может содержать пароли, ключи, данные аутентификации, настройки, личную информацию, интеллектуальную собственность поставщика и тому подобное. В случае электронного интеллектуального запирающего устройства поддержка функции безопасности имеет особую важность, так как замки предназначены для обеспечения безопасности зданий.

TIDC-01005 демонстрирует несколько ключевых функций безопасности электронного интеллектуального замка с Wi-Fi. Среди них:

  • безопасная загрузка (Secure boot);
  • защищенные сокеты;
  • обновления по беспроводному каналу с использованием цифровых подписей, безопасных файлов и с пакетной защитой;
  • защищенная файловая система.

Безопасная загрузка означает процесс верификации программного обеспечения, которое было загружено из внешней памяти во внутреннюю память встроенного процессора. CC3220S имеет механизм безопасной загрузки, встроенный в его ROM-загрузчик, чтобы помочь обезопасить устройство от загрузки из его внешней последовательной Flash-памяти кода, не подписанного приемлемой цифровой подписью. В процессе безопасной загрузки CC3220S подтверждает целостность и аутентичность исполняемого двоичного файла (образа МК). Инструмент UniFlash ImageCreator для устройств CC3120 и CC3220 может быть использован для генерации образов с цифровыми подписями, которые могут быть записаны во внешнюю последовательную Flash-память и использованием CC3220S. Безопасная загрузка – это важная функция для электронных интеллектуальных замков, поскольку позволяет разработчикам обезопасить систему от взлома вредоносным кодом. Такой взлом может повлечь за собой прекращение корректной работы системы или подвергнуть ее риску несанкционированного доступа.

Устройства SimpleLink Wi-Fi CC3x20 имеют встроенные, соответствующие стандартам безопасные стеки транспортного уровня (TLS/SSL), которые являются сетевыми протоколами, следующими парадигмам шифрования, разработанным для обеспечения безопасности обмена данными по соединению TCP/IP. Использование таких сокетов позволяет защитить информацию, отправляемую пирам через интернет. Встраивание в устройство стеков TLS/SSL позволяет упростить код, необходимый для создания защищенных сокет-соединений, и оставляет память свободной для приложения пользователя. В TIDC-01005 используются защищенные сокет-соединения во время первоначального подключения к Wi-Fi через AP (сервер HTTPS), при обмене данными с IoT-брокером Eclipse для мониторинга и управления запирающим устройством (клиент MQTT по TLS) и при проведении обновлений ПО по беспроводному каналу через Dropbox (клиент HTTPS). 

Защищенные сокеты основываются на различных алгоритмах шифрования. В устройствах SimpleLink Wi-Fi CC3x20 аппаратные ускорители используются для работы в условиях существенных вычислительных нагрузок, связанных этими алгоритмами шифрования. Загрузка такими операциями аппаратных ускорителей позволяет освободить сетевой процессор для выполнения остальных задач и ускорить время соединения с TLS/SSL.

При создании защищенного сокет-соединения сервер отправляет письмо клиенту, содержащему цепочку сертификатов сервера. Клиент должен определить, является ли цепочка сертификатов корректной для данного соединения, и, в частности, проверить, что текущие дата и время входят в период достоверности сертификата сервера. В TIDC-01005 используется реализация простого протокола сетевого времени (SNTP) для автоматического получения с NTP-сервера текущих времени и даты и подстройки внутреннего RTC CC3220S. Дата и время RTC, в таком случае, используются для проверки подлинности сертификатов сервера при использовании защищенных сокетов.

Устройства SimpleLink Wi-Fi CC3x20 требуют наличия внешней энергонезависимой памяти (NVM) в виде устройства последовательной Flash-памяти (SFLASH). Данные, хранящиеся в SFLASH, организованы в файловую систему, которая может быть доступна из приложения МК через API, встроенный в хост-драйвер SimpleLink Wi-Fi. CC3220S содержит несколько встроенных средств обеспечения безопасности файловой системы, призванных помочь разработчикам в защите информации, хранящейся в этой системе. Вот некоторые из ключевых средств безопасности, применяемых в TIDC-01005:

  • шифрование – файлы сохраняются и шифруются с использованием стандартного алгоритма AES-128;
  • защита от клонирования – все содержимое файловой системы доступно для чтения только того экземпляра устройства, который первым загрузил образ, поскольку образ шифруется с ключом, уникальным для конкретной микросхемы CC322x;
  • контроль доступа – доступ к файлам может быть ограничен настоящим владельцем, который может задать тип доступа к каждому файлу (запись, чтение и так далее);
  • проверка целостности – целостность структуры файловой системы проверяется на предмет наличия изменений;
  • механизм восстановления – файловая система может быть возвращена к начальному запрограммированному состоянию.

Для некоторых, особых системных файлов средства безопасности включены по умолчанию. Например, сервисный пакет и каталог доверенных корневых сертификатов должны быть на всех устройствах созданы как защищенные подписанные файлы. Для CC3220S исполняемый двоичный файл также должен быть создан как защищенный подписанный файл. В дополнение к этим особым файлам частный ключ, используемый HTTPS-сервером, при работе приложения также должен быть настроен в качестве защищенного файла. По умолчанию, частный ключ – это защищенный файл, но без проверки подписи и публичного права записи, в предлагаемом для TIDC-01005 пакете UniFlash ImageCreator (создание имиджа для загрузки во Flash).

Для защиты системы во время таких полевых обновлений ПО как обновления программного обеспечения по беспроводному каналу, TIDC-01005 применяет два дополнительных средства безопасности. CC3220S имеет опцию создания защищенных файлов. В это время для создаваемого файла резервируются два банка внешней последовательной Flash-памяти. Резервирование двух банков памяти позволяет хранить одновременно две копии файла. В процессе OTA-обновлений во второй банк памяти параллельно текущей версии защищенного файла записывается его новая копия. После завершения загрузки новая версия безопасного файла фиксируется (в качестве актуальной версии) только после того, как приложение произведет проверку файла на целостность.

CC3220S также имеет функцию, называемую «пакетная защита», которую разработчики могут использовать для поддержания целостности системы во время обновления совокупности защищенных файлов, рассматриваемых в качестве пакета. Так как тестирование ПО обычно производится на системе с набором файлов определенной версии, важно для всех файлов пакета применить обновление в один момент времени. Пакетная защита дает разработчику возможность фиксации или отката к предыдущей версии сразу всех файлов пакета для предотвращения ситуации, в которой система будет содержать смешанные файлы из разных версий ПО.

Использование безопасных файлов и функций пакетной защиты важно для проектов электронных интеллектуальных запирающих устройств, поддерживающих OTA-обновления, поскольку это помогает разработчикам поддерживать целостность системы и гарантировать, что замок всегда будет находиться в рабочем состоянии. Обновления по беспроводному каналу, которые по умолчанию производится в приложении TIDC-01005, включают в себя пакетную защиту всех файлов обновления. 

Малое потребление

Используемые встроенные драйверы (TI-Drivers) включают в себя контроль питания и переводят микроконтроллерную подсистему CC3220S в режим малого потребления, когда система простаивает. В TIDC-01005 МК переходит в режим LPDS каждый раз при выполнении нулевой задачи. Подсистема сетевого процессора CC3220S использует политику, называемую «Продолжительный период сна» (LSI), для увеличения продолжительности времени, которое WiFi NWP проводит в энергосберегающем режиме между моментами активной работы радиопередатчика AP и передачи широковещательных сообщений. Это значительно снижает среднюю потребляемую мощность. Максимальная продолжительность спящего режима, по умолчанию допускаемая в ПО TIDC-01005, составляет 500 мс, однако реальное значение времени, проводимого Wi-Fi NWP в режиме LPDS, зависит от параметров точки доступа (например, интервала радиопередачи и значения DTIM). Приложение SNP, разработанное для CC2640R2F, включает схему встроенного контроллера питания для минимизации потребляемой мощности в те моменты, когда интерфейс сетевого процессора неактивен. DRV8837 также поддерживает спящий режим с малым потреблением, в который устройство переходит, когда CC3220S устанавливает низкий уровень на выводе nSLEEP. TIDC-01005 разработан так, чтобы держать DRV8837 в спящем режиме все время, кроме моментов получения команд блокировки/разблокировки замка от клиента MQTT и соответствующего управления двигателем.

Рассмотрим ряд измерений потребляемой мощности TIDC-01005 при тестировании системы.

Аппаратура, программное обеспечение, условия испытаний и их результаты

TIDC-01005 основан на оценочных модулях (EVM) CC3220S-LAUNCHXLLAUNCHXL-CC2640R2DRV8837EVM и BOOSTXL-SENSORS. В разделе «Аппаратная часть» дано описание совместного использования оценочных модулей, включая необходимые модификации аппаратной части для работы демо. Данная референсная разработка основана на существующем программном приложении для CC2640R2F и содержит руководство по программному обеспечению CC3220S, которые могут быть использованы совместно для оценки системы. В разделе «Программное обеспечение» предоставлено руководство пользователя ПО. В частности, этот раздел освещает процесс сборки приложения для CC2640R2F, а также поясняет, как пользоваться приложением CC3220S.

Для оценки TIDC-01005 необходимы следующие устройства:

  • CC3220S-LAUNCHXL;
  • LAUNCHXL-CC2640R2F;
  • BOOSTXL-SENSORS;
  • DRV8837EVM;
  • коллекторный двигатель постоянного тока на 6 В;
  • 5 соединительных проводов;
  • двухвыводный джампер;
  • кабель micro-USB (из состава LaunchPad).

Ниже вы прочтете описание настроек EVM, включая необходимые модификации устройств, и способ их соединения для запуска демо TIDC-01005.

Для запуска демонстрации CC3220S LaunchPad должен быть настроен в соответствии с джамперами, выделенными на рисунке 11. Расположение джамперов на штыревой линейке SOP зависит от того, происходит ли отладка ПО или его самостоятельная работа от внешней последовательной Flash-памяти.

Рис. 11. Конфигурация джамперов CC3220S-LAUNCHXL

Рис. 11. Конфигурация джамперов CC3220S-LAUNCHXL

Платформа CC3220S-LAUNCHXL должна быть доработана для измерения потребляемого тока. Доработка описана в разделе «Тестирование и результаты», так как не является необходимой для работы приложения и демонстрации системы.

Перед подключением CC2640R2F LaunchPad к CC3220S LaunchPad для работы демо все джамперы должны быть сняты. Однако перед снятием всех джамперов и соединением устройств должен быть выполнен порядок действий для программирования LAUNCHXL-CC2640R2, приведенный в разделе «Программное обеспечение». На рисунке 12 показан запрограммированный LAUNCHXL-CC2640R2.

Рис. 12. Конфигурация CC2640R2F LaunchPad™

Рис. 12. Конфигурация CC2640R2F LaunchPad™

Исходная настройка портов ввода-вывода при использовании проекта SNP CC2640R2F, входящего в BLE plugin, приводит к конфликтам с выводами CC3220S LaunchPad и Sensor Booster Pack. Для обеспечения нормальной работы всех трех плат, соединенных вместе, необходимо пересобрать приложение SNP (simple_np) из SimpleLink CC2640R2F SDK с обновленной настройкой выводов. Процесс обновления расположения выводов CC2640R2F (pinmapping) поясняется в разделе «Программное обеспечение» и приводит к следующим кросс-соединениям между CC3220S и CC2640R2F (таблица 3).

Таблица 3. Расположение выводов CC3220S и CC2640R2F

CC3220S CC2640R2F
Вывод 3 (UART0 TX) DIO 2 (UART RX)
Вывод 4 (UART0 RX) DIO 3 (UART TX)
Вывод 62 (MRDY) DIO 21 (MRDY)
Вывод 8 (SRDY) DIO 11 (SRDY)
Вывод 7 (RESET) BPRST (RESET)

Все выводы, описанные в таблице 3, соединяются между собой при сборке демо, за исключением цепи RESET. Для подключения вывода 7 CC3220S к выводу BPRSTCC2640R2F можно использовать простую двухвыводную перемычку при сборке LaunchPad’ов и BoosterPack’ов, в соответствии с описанием, приведенным в разделе «Сборка оценочных модулей».

В Sensor Booster Pack задействован только датчик BMI160 для TIDC-01005. Когда датчик BMI160 активирован, он подает сигнал готовности данных на CC3220S, используя вывод запроса прерывания, и передает данные в CC3220S по I2C. В таблице 4 перечислены выводы, используемые для работы интерфейса между CC3220S и BMI160.

Таблица 4. Выводы CC3220S, используемые BMI160.

Вывод CC3220S Назначение
Вывод 1 Тактовая I2C
Вывод 2 Данные I2C
Вывод 61 Прерывание

По умолчанию микросхема DRV8837 на плате DRV8837EVM управляется бортовым МК MSP430™, а плата в целом питается через разъем micro-USB. Для управления DRV8837 от CC3220S модификацию DRV8837EVM и подключение к LaunchPad CC3220S необходимо выполнить в следующей последовательности:

  1. Демонтировать R3 и R4 (ноль-омные резисторы) с нижней стороны DRV8837EVM для разрыва цепей IN1/IN2 между DRV8837 и MSP430 (рисунок 13);
  2. Запитать DRV8837 от LaunchPad CC3220S путем подключения выводов «5-V» и GND-разъема J23 LaunchPad CC3220S к разъему J1DRV8837EVM (рисунок 14)
  3. Подключить к контрольным точкам IN1 и IN2 DRV8837EVM цепи, соответствующие контактам P16 и P17 LaunchPad CC3220S.
Рис. 13. Расположение R3 и R4 на нижней стороне DRV8837EVM

Рис. 13. Расположение R3 и R4 на нижней стороне DRV8837EVM

Рис. 14. Выделенные контакты J1 и IN1/IN2 на верхней стороне DRV8837EVM

Рис. 14. Выделенные контакты J1 и IN1/IN2 на верхней стороне DRV8837EVM

В данном примере для управления DRV8837 используются два GPIO и один PWM-сигнал. В таблице 5 приведен список необходимых соединений между LaunchPad и доработанным DRV8837EVM при использовании прилагаемого референсного ПО.

Таблица 5. Перечень соединений LaunchPad CC3220S с DRV8837EVM

LaunchPad CC3220S DRV8837EVM
P18 nSleep (JP2)
P16 IN1 (TP1)
P17 IN2 (TP2)
5 V VM (J1)
GND GND (J1)

Для точного измерения энергопотребления двигателя требуются дополнительные модификации. Их описание приведено в разделе «Тестирование и результаты».

При сборке демо TIDC-01005 платы CC3220S-LAUNCHXL, LAUNCHXL-CC2640R2, и BOOSTXL-SENSORS должны быть объединены в стек путем соединения 20-выводных разъемов оценочных модулей в следующем порядке (цифра 1 соответствует верхней плате стека, 3 – нижней):

  1. BOOSTXL-SENSORS;
  2. CC3220S-LAUNCHXL;
  3. LAUNCHXL-CC2640R2.

После объединения в стек плат LaunchPad и BoosterPack убедитесь, что двухконтактный джампер расположен на Sensor Booster Pack по горизонтали между J4-J6 и J2-J6 и соединяет вывод 7 CC3220S с выводом BPRSTCC2640R2F. Рисунок 15 иллюстрирует результат сборки.

Рис. 15. Стек из LaunchPad™ и BoosterPack™

Рис. 15. Стек из LaunchPad™ и BoosterPack™

Последним шагом будет подключение полученного стека к DRV8837EVM в соответствии с таблицей 5 при помощи соединительных проводов (соединения показаны на рисунке 16). Вся система может питаться через USB-кабель, подключенный к разъему USB на плате CC3220S LaunchPad.

Рис. 16. Расположение соединительных проводов для подключения DRV8837EVM к системе

Рис. 16. Расположение соединительных проводов для подключения DRV8837EVM к системе

Программное обеспечение

Программное обеспечение, созданное для данной референсной разработки, основано на SimpleLink SDK и направлено на обеспечение максимальной портируемости кода в рамках платформы SimpleLink. Используя платформу SimpleLink, разработчики могут однократно уделить время разработке ПО, после чего использовать его повторно для разных МК с интегрированной технологией проводной или беспроводной связи. Данная особенность увеличивает гибкость разработок и позволяет создать линейку продуктов, в которой все устройства основаны на одном и том же коде ядра.

ПО данной референсной разработки показывает, как при помощи беспроводных МК с Wi-Fi SimpleLink может быть создан дверной замок с Wi-Fi и несколькими встроенными функциями безопасности. В частности, ПО показывает, как реализовать следующие основные функции электронного интеллектуального запирающего устройства с Wi-Fi:

  • первоначальное подключение к Wi-Fi (через AP, SmartConfig и BLE);
  • SNTP для получения сетевого времени и подстройки системного RTC;
  • MQTT над TLS для управления и мониторинга состояния дверного замка через защищенное соединение с сервером;
  • OTA-обновления ПО через HTTPS с Dropbox API v2;
  • управление двигателем посредством DRV8837;
  • управление питанием для продления времени работы от батареи.

На данный момент создавать и производить сборку исходных кодов можно только в Code Composer Studio™ (CCS), однако проект может быть перемещен и в другие среды разработки и компиляторы, такие как IAR или GCC. Для использования примера необходимо скачать следующее ПО:

  • последнюю версию Code Composer Studio;
  • UniFlash 4.3 (с ImageCreator);
  • SimpleLink Wi-Fi CC3220 SDK (v2.10.00.04);
  • SimpleLink SDK Bluetooth Plugin (v1.40.00.42);
  • SimpleLink SDK Sensor and Actuator Plugin (v1.20.00.02);
  • SimpleLink CC2640R2 SDK (v1.50.00.58).

После установки инструментов и SDK запустите инсталлятор программного обеспечения TIDC-01005. Инсталлятор по умолчанию будет пытаться поместить ПО в SDKCC3220. Если стандартный путь, используемый инсталлятором, не совпадет с реальным расположением SDK CC3220 в ПК, он должен быть актуализирован. После установки в папку RTOSdemos контроллера CC3220 SDK, должен быть извлечен zip-архив, содержащий пакет ПО (извлеченное содержимое должно в итоге находиться в папке <Директория установки SDK>/simplelink_cc32xx_sdk_2_10_00_04/examples/rtos/CC3220S_LAUNCHXL/demos).

Установленный пакет содержит файлы исходного кода ПО совместно с проектом UniFlash (формат .zip), который предоставляет собой два разных варианта оценки системы. 

Независимо от способа, используемого для оценки приложения CC3220S, в CC2640R2F сначала должно быть загружено приложение SNP (simple_np). Ниже приведена последовательность шагов по доработке и сборке проекта simple_np:

  1. импортируйте проект simple_np из SDK CC2640R2 в рабочее пространство (workspace) CCS;
  2. кликните правой кнопкой мыши по проекту simple_np_cc2640r2lp_app, появившемуся в обозревателе проектов, и выберите меню Properties;
  3. откройте представление Predefined Symbols в окне Project Properties (из меню Build → ARMCompiler → PredefinedSymbols).
  4. убедитесь в том, что имеются следующие дефайны:
  • NPI_USE_UART
  • POWER_SAVING
  1. откройте используемый в проекте файл board_cc2640r2lp.h (из <Директория установки SDK>\simplelink_cc2640r2_sdk_1_50_00_58\examples\rtos\CC2640R2_LAUNCHXL\blestack\simple_np\src\app\board_cc2640r2lp);
  2. измените определения Board_MRDY и Board_SRDY в соответствии с листингом 1.
  3. кликните правой кнопкой мыши по проекту simple_np_cc2640r2lp_app рабочего пространства и выберите RebuildProject.

Листинг 1. Обновленные определения SRDY и MRDY

150 /* MRDY/SRDY Board */

151 #define Board_MRDY                                   IOID_21 // IOID_23      /* MRDY */

152 #define Board_SRDY                                   IOID_11 //IOID_12       /* SRDY */
JavaScript

В результате пересборки приложения в папке проекта FlashROM_StackLibrary генерируется файл с именем simple_np_cc2640r2lp_app.hex. Для загрузки файла simple_np_cc2640r2lp_app.hex в LAUNCHXL-CC2640R2 используйте инструмент Flash Programmer 2. После того как программирование платы завершено, все ее джамперы могут быть сняты, как описано в разделе «Аппаратная часть».

Для немедленной оценки ПО с использованием предварительно подготовленного проекта UniFlash сделайте следующее:

  1. скачайте CC3220 SDK и wifi_doorlock.zip (следуйте указаниям в описании начала работы с программным обеспечением для установки демо wifi_doorlock);
  2. откройте UniFlash и выберите LaunchPad CC3120/CC3220 или CC3220;
  3. Нажмите на «Start Image Creator» (для CC3120/CC3220);
  4. откройте меню «ManageProjects»;
  5. нажмите «Import Project from ZIP file»;
  6. перейдите к примеру wifi_doorlockв CC3220 SDK, и выберите файл «.zip» последней версии в папке uniflash (wifi_doorlock / uniflash / wifi_doorlock_RS_tirtos <version>.zip);
  7. найдите проект UniFlash с именем «wifi_doorlock_RS_tirtos» в списке доступных проектов;
  8. нажмите на «OpenProject»;
  9. подключитесь к CC3220S-LAUNCHXL, нажав кнопку «Connect» справа;
  10. нажмите кнопку «Generate Image» (с символом пламени справа);
  11. нажмите «Program Image» («Create & Program») в верхней части страницы «Generate Image».

В результате этих действий во внешнюю последовательную Flash-память CC3220S будут загружены ПО и связанные с ним системные файлы. Пример, приведенный в пакете UniFlash, разработан для отображения изменений состояния приложения посредством вывода сообщений отладки в последовательный терминал. Для того чтобы увидеть отладочные сообщения, откройте приложение последовательного терминала, к которому подключен LaunchPad, и подключитесь к COM-порту с именем «XDS110 ClassApplication/User UART». В таблице 6 приведены необходимые настройки последовательного порта.

Таблица 6. Необходимые настройки последовательного порта

Параметр Значение
Скорость передачи данных 115200
Биты данных 8 бит
Контроль четности
Стоповые биты 1 бит
Управление потоком

После успешного подключения к последовательному терминалу перезапустите CC3220S, нажав кнопку RESET на верхней стороне CC3220S-LAUNCHXL. Приложение загрузится из внешней Flash-памяти и начнет выполняться. После перезагрузки приложение проверит, существует ли сетевой профиль в системе CC3220S. Если он существует – система автоматически подключится к AP. В противном случае система будет ожидать получения настроек Wi-Fi от соединения Bluetooth Low Energy. На рисунке 17 показаны сообщения, появляющиеся в терминале при запуске системы и ожидании первоначальной настройки Wi-Fi-сети.

Рис. 17. Вывод сообщений отладки в последовательный терминал при первом запуске приложения

Рис. 17. Вывод сообщений отладки в последовательный терминал при первом запуске приложения

Для подключения устройства к сети и оценки остальных возможностей ознакомьтесь с тем, как подключить CC3220 к сети. При работе с предварительно подготовленным проектом UniFlash Image-Creator система по умолчанию задействует управление питанием.

Загруженное ПО включает в себя исходные файлы и предварительно подготовленный проект CCS, что позволяет пользователям быстро начать отладку, изменение и пересборку кода, используемого в разработке. После того как программное обеспечение успешно извлечено в папку демо CC3220S RTOS SimpleLink Wi-Fi SDK, оно может быть напрямую импортировано в рабочее пространство CCS. Достаточно выполнить следующие действия:

  1. кликните правой кнопкой мыши по «Project Explorer»;
  2. в меню «Import» выберите вариант «CCSProject»;
  3. перейдите к папке «wifi_doorlock»SDK (<Директория установки SDK>/simplelink_cc32xx_sdk_2_10_00_04/examples/rtos/CC3220S_LAUNCHXL/demos/wifi_doorlock);
  4. нажмите кнопку «ОК»;
  5. в окне «Import» в списке «Discovered Projects» появится проект с именем «wifi_doorlock_CC3220S_LAUNCHXL_tirtos_ccs». Выделите проект, затем нажмите «Finish».

После импортирования этого проекта также будет импортирован проект tirtos_build для CC3220S, если он еще не был создан в рабочем пространстве.

Примечание: Для успешной сборки проекта wifi_doorlock сначала должны быть добавлены в то же рабочее пространство и успешно собраны библиотека OTA и драйвер хоста SimpleLink Wi-Fi. 

Перед сборкой проекта wifi_doorlock_CC3220S_LAUNCHXL_tirtos_ccs пользователи также должны импортировать и собрать библиотеки OTA и драйвера хоста SimpleLink Wi-Fi из SDK. Для импортирования и сборки библиотеки OTA необходимо выполнить следующие шаги:

  1. кликните правой кнопкой мыши по ProjectExplorer;
  2. в меню «Import» выберите вариант «CCSProject»;
  3. перейдите к папке source/ti/net SDK;
  4. нажмите кнопку «ОК»;
  5. в списке обнаруженных проектов выберите OTA library и нажмите на «Finish».

Перед сборкой библиотеки OTA должны быть произведены некоторые изменения в свойствах проекта. Они могут быть внесены в следующем порядке:

  1. кликните правой кнопкой мыши по проекту OTA в рабочем пространстве и выберите «Properties»;
  2. из списка в левой части окна CCS Project Properties выберите «Resource → Linked Resources»;
  3. перейдите на вкладку Linked Resources;
  4. измените все пути, помеченные как «Invalid Locations», заменив символ «PROJECT_LOC» на «ORIGINAL_PROJECT_ROOT»;
  5. из списка в левой части окна CCS Project Properties выберите «Build → ArmCompiler → Optimization»;
  6. измените «Optimization leve»l на «2» – «Global Optimizations»;
  7. выберите «Select Build → Arm Compiler → Advanced Options → Runtime Model Options»;
  8. разрешите опцию размещения каждой функции в отдельной подфункции (установите на «on»);
  9. по завершении всех правок нажмите «Apply», затем → «Close».

Для импортирования и сборки библиотеки драйвера хоста SimpleLinkWi-Fi сделайте следующее:

  1. кликните правой кнопкой мыши по «Project Explorer;
  2. в меню «Import» выберите вариант «CCSProject»;
  3. перейдите к папке source/ti/drivers/net/wifiSDK;
  4. нажмите «ОК»;
  5. в списке обнаруженных проектов выберите проект «simplelink» и нажмите «Finish»;
  6. когда проект появится в рабочем пространстве, кликните по нему правой кнопкой мыши;
  7. из списка в левой части окна CCS Project Properties выберите «Build → ArmCompiler → Optimization»;
  8. измените «Optimization level» на «4» – Whole Program Optimizations;
  9. выберите «Build → Arm Compiler → Advanced Options → Runtime Model Options»;
  10. разрешите опцию размещения каждой функции в отдельной подфункции (установите на «on»);
  11. для применения изменений нажмите «Apply», затем → «Close».

После внесения изменений обе библиотеки могут быть пересобраны, после чего может быть успешно собран проект wifi_doorlock_CC3220S_LAUNCHXL_tirtos_ccs.

По умолчанию контроль питания в приложении CCS настроен как неактивный, что позволяет отладчику поддерживать соединение с CC3220S при выполнении приложения wifi_doorlock. При неактивной политике управления питанием приложение может отлаживаться при условии, что в файловую систему CC3220 были заранее добавлены необходимые пользовательские файлы. В другом варианте для правки и пересборки приложения может использоваться проект CCS с последующей заменой файла mcuimg.bin в прилагаемом проекте UniFlash Image Creator. Раздел «Пользовательские файлы» поясняет, как добавить необходимые пользовательские файлы при отладке приложения с использованием CCS.

Программное обеспечение дверного замка с Wi-Fi было разработано так, чтобы имелась возможность отключения различных модулей в процессе разработки и оценки. Управление включением и отключением модулей обеспечивается рядом определений в начале файла wifi_doorlock_app.h. В частности, нередко требуется отключение процесса получения первоначальных настроек (Wi-Fi provisioning) во время разработки, заменив его статически определенным набором аутентификационных данных для подключения к тестовой сети. Установка определений APSC_PROVISIONING и BLE_PROVISIONING в «0» вместо «1» приводит к игнорированию этого этапа и использованию статически определенного набора аутентификационных данных, находящегося в wifi_doolock_app.h для подключения системы к сети.

Примечание: По умолчанию контроллер питания в проекте CCS отключен, чтобы оставить систему подключенной к CCS IDE во время отладки. Активируйте контроллер питания посредством внесения символа USE_POWER_POLICY в список предопределенных символов приложения wifi_doorlock_CC3220S_LAUNCHXL_tirtos_ccs. 

Пользовательские файлы

Приложение-пример дверного замка с Wi-Fi для успешной работы требует наличия определенных файлов в файловой системе. Они уже включены в качестве составляющей части предварительно подготовленного проекта UniFlash Image Creator, но пользователю необходимо загрузить их в последовательную Flash-память перед отладкой приложения с использованием CCS. В таблице 7 представлен список файлов, наличие которых в файловой системе необходимо для работы демо и его функций.

Таблица 7. Пользовательские файлы, необходимые для работы демонстрационного приложения дверного замка с Wi-Fi

Файл Назначение
dummy-root-ca-cert Пустая цепочка сертификатов, используемая в целях верификации двоичного кода приложения для оценки защищенной загрузки (должна быть заменена пользователем при производстве)
dummy-trusted-ca-cert
dummy-trusted-cert
dummy_ota_vendor_cert.der Пустой сертификат, используемый для проверки подписи каждого файла в пакете обновления OTA в процессе OTA-обновления (должен быть заменен пользователем при производстве)
dummy-root-ca-cert Сертификат и приватный ключ для запуска внутреннего HTTP-сервера с безопасным соединением (HTTPS).

Примечание: Вместо одиночного сертификата сервер может использовать цепочку сертификатов в формате PEM (должен быть заменен пользователем при производстве)

dummy-root-ca-cert-key
eclipsecert.der Корневой сертификат сервера Eclipse IoT MQTT, используемый клиентом для проверки сервера во время соединения TLS
digicertca.der Корневой сертификат api.dropboxapi.com, используемый CC3220 для проверки сервера Dropbox во время соединения TLS

Корневые сертификаты для сервера Eclipse и Dropbox можно найти с помощью такого сайта как ssltools.com либо таких инструментов как Open SSL или Curl. Пустые сертификаты и ключи расположены в SimpleLinkWi-Fi SDK в директориях tools/cc3220_tools/certificate-playground и tools/cc3220_tools/ota-example-cert.

Примечание: Пустые сертификаты и ключи используются только в целях демонстрации и разработки. Получение актуальных сертификатов и ключей для подписывания кода и SSL/TLS является задачей разработчика. 

Если пример запускается «из коробки», то в первую очередь будет запущен процесс первоначального подключения к Wi-Fi-сети. Изначально используется режим ввода сетевых настроек через BLE, однако система может быть переключена на использование методов подключения через AP или Smart Config посредством удержания переключателя на правой стороне CC3220S LaunchPad в течение 3 секунд.

  • Для настроек сети Wi-Fi с помощью BLE сначала необходимо загрузить мобильное приложение SimpleLink SDK Explorer для Android или iOS. Затем следуйте инструкциям в файле README.html для примера ble_wifi_provisioning плагина SimpleLink SDK Bluetooth.
  • Для подключения через AP или Smart Config загрузите мобильное приложение SimpleLink Starter Pro для Android или iOS. Затем следуйте инструкциям в мобильном приложении либо смотрите указания в Task3 из SimpleLink Academy Training for Wi-Fi Provisioning.

Примечание: Первоначальное подключение к сети Wi-Fi c вводом настроек через AP для демо дверного замка с Wi-Fi обладает одним основным отличием от тренинга SimpleLink Academy – AP SimpleLink защищена паролем. При работе через SimpleLink Starter Pro в качестве ключа безопасности введите 1234567890 для подключения к устройству mysimplelink-xxxxxx. Значение пароля по умолчанию (1234567890) принято таковым для упрощения демо и должно быть изменено при реализации конечного приложения для обеспечения безопасности.

В процессе раздачи на терминале появляется несколько сообщений. Устройство выводит сообщение при добавлении нового профиля, успешном подключении к AP, получении IP-адреса и в случае, когда при использовании мобильного устройства для первоначального подключения CC3220 подтверждает, что ввод настроек сети прошел успешно.

Примечание: Стандартный метод подтверждения входит в процесс первоначального подключения через AP или Smart Config, но сообщение может быть изменено разработчиком для конечного варианта проекта. Если же сообщение о подтверждении не принято через AP или Smart Config (даже в случае, когда терминал показывает, что был добавлен профиль и устройство подключилось к AP), профиль все равно остается корректным и сохраняется в устройстве. Сброс CC3220S-LaunchPad вызывает перезапуск приложения, и происходит попытка подключения к сохраненному профилю.

При первом запуске подключения через BLE мобильное устройство, используемое для ввода Wi-Fi-настроек, должно быть сопряжено с системой TIDC-01005 с использованием безопасного простого сопряжения BLE. Когда мобильное устройство подключается по BLE к системе TIDC-01005 впервые, устройство предлагает пользователю ввести ключ сопряжения. Ключ, необходимый для сопряжения с системой, отображается на экране ПК, как показано на рисунке 18. Успешное введение ключа позволяет осуществить BLE-сопряжение двух устройств.

Рис. 18. Ключ для безопасного простого сопряжения по BLE, отображаемый в окне терминала на ПК

Рис. 18. Ключ для безопасного простого сопряжения по BLE, отображаемый в окне терминала на ПК

Когда устройства сопряжены, пользователь должен ввести аутентификационные данные в мобильном приложении SimpleLink SDK Explorer (рисунок 19), после чего нажать кнопку «Provision» для их отправки системе по BLE.

Рис. 19. GUI SimpleLink™ SDK Explorer при первоначальном подключении по BLE

Рис. 19. GUI SimpleLink™ SDK Explorer при первоначальном подключении по BLE

Когда данные аутентификации будут успешно записаны, МК CC3220S считывает их из CC2640R2 по NPI и проверяет соединение. Если соединение устанавливается корректно и пользователю дается подтверждение, профиль добавляется в файловую систему CC3220S и используется для дальнейшей работы приложения.

CC3230S автоматически подключается к профилю в файловой системе для всех последующих перезапусков приложения.

По завершении процесса первоначальных настроек Wi-Fi начинает работу остальная часть демо дверного замка. Основные сетевые функции, используемые в демо дверного замка с Wi-Fi – это SNTP, MQTT и HTTP. Сразу после подключения к интернету CC3220 должен обновить свой RTC на основе сетевого времени для последующего создания безопасных сетевых подключений (SSL/TLS). Когда RTC настроен на текущее время, CC3220 может установить MQTT-соединение с брокером Eclipse MQTT (iot.eclipse.org) для оповещения удаленного пользователя о своем состоянии и получения команд о блокировке или разблокировке.

CC3220S получает текущие дату и время с использованием SNTP. Подключение к серверу NTP, запрос даты и времени и интерпретация временной метки осуществляется при помощи NetUtils и библиотек SNTP, включенных в SDK CC3220. Эти библиотеки используют предопределенный набор NTP-серверов для запроса даты и времени. Код приложения, используемый для формирования запроса и обновления значения RTC, можно найти в функции setTime(), определенной в начале wifi_doorlock_app.c.

Примечание: Часы реального времени (RTC-устройства) должны быть синхронизированы для проверки того, что используемые пирами сертификаты имеют актуальный срок действия. Без синхронизации RTC с текущим сетевым временем подключение к серверу может потерпеть неудачу либо устройство может оказаться в незащищенном соединении.

После синхронизации RTC по текущему времени сети CC3220 подключается по TLS к брокеру MQTT с использованием библиотеки MQTT из SimpleLink SDK. В библиотеке MQTT реализован набор функций, которые могут быть использованы для работы в качестве клиента MQTT без подключения к специальному серверу. В данном примере – к открытому брокеру eclipse (iot.eclipse.org).

В рамках данного демо CC3220 подписывается на четыре темы:

  1. /Broker/To/cc32xx/doorLock;
  2. /cc3220/doorLock/<Unique Device ID>/LockStatus;
  3. /cc3220/doorLock/<Unique Device ID>/LockControl;
  4. /cc3220/doorLock/<Unique Device ID>/LockOTA.

В именах тем <UniqueDevice ID> обозначает 128-битный уникальный идентификатор устройства (в шестнадцатеричном формате), встроенный в каждое из устройств CC3220S. Данный ID делает темы, используемые каждым устройством, уникальными, благодаря чему устройства не будут получать сообщения, предназначенные для других систем. Актуальные имена тем, используемые для конкретного устройства, выводятся в верхней части последовательного терминала при перезапуске приложения. Приложение динамически назначает имена тем, считывая ID устройства с сетевого процессора и вводя значение ID в строки имен тем перед их использованием в приложении.

На данный момент в демо используются только темы 2, 3 и 4. Тема 2 может быть использована устройством-пиром для получения текущего состояния замка. CC3220 публикует состояние замка в формате JSON в отклике на любое сообщение, получаемое по теме 2. Для предотвращения получения устройством собственного отклика на запрос статуса устройством используется отдельная тема. CC3220 публикует состояние замка по теме /cc3220/doorlock/<UniqueDevice ID>/LockState.

В таблице 8 приведен формат JSON-сообщения, отправляемого по теме LockState.

Таблица 8. Формат данных по теме LockState

Состояние Данные
Заперто {«state»: «locked»}
Открыто {«state»: «unlocked»}

Тема 3 может быть использована для изменения состояния замка («заперто» или «открыто»). Например, для перевода демо в состояние «заперто» пользователь должен опубликовать сообщение «lock» по теме 3. Для перевода демо в состояние «открыто» пользователю необходимо опубликовать сообщение «unlock» по теме 3. В зависимости от того, какая команда получена по теме 3, двигатель вращается по часовой стрелке или против нее. При работе демо, пока оно подключено к терминалу, полученные команды выводятся на экран совместно с данными чтения сенсора при управлении двигателем.

На рисунке 20 показан пример выводимых в терминале сообщений.

Рис. 20. Вывод отладки после отправки сообщения «lock» по теме «Lock Control»

Рис. 20. Вывод отладки после отправки сообщения «lock» по теме «Lock Control»

Тема 4 используется для команды устройству по инициации OTA-обновления. Когда устройство получает любое сообщение, опубликованное по теме 4, запускается автомат состояний OTA. Подробное описание реализации OTA приведено в разделе об обновлении по беспроводному каналу..

Каждый раз, когда CC3220 получает сообщение по теме, на которую он подписан, или публикует по теме «Lock State», устройство выводит в последовательный терминал отладочное сообщение. Данная функция может быть использована для мониторинга откликов системы при отладке. Любой клиент MQTT, способный подключиться к брокеру Eclipse IoT, может быть использован для тестирования функционала демо, задействовав имена тем, показанные здесь. Например, мобильные приложения, упомянутые в тренинге Wi-Fi MQTT SimpleLink Academy, могут быть использованы для изучения поведения удаленного клиента, который управляет состоянием демо и наблюдает за ним.

Установление соединения MQTT по TLS обеспечивается благодаря использованию защищенного порта MQTT (8883) и включает корневой сертификат для сервера eclipse, чтобы обеспечить возможность для CC3220 проверить цепочку сертификатов сервера. Корневой сертификат сервера Eclipse должен быть добавлен в файловую систему CC3220S перед запуском демо (что уже сделано в предоставляемом пакете UniFlash). В приложении путь к этому файлу в файловой системе, а также защищенный порт MQTT, указаны в контекстной структуре клиента MQTT, если в начале файла ifi_doorlock_app.c имеется определение SECURE_CLIENT.

Ввиду того, что ПО, предоставляемое для демо, собрано для использования с преднастроенным брокером, имеются и некоторые ограничения при реализации. Взаимная аутентификация не поддерживается демо, поскольку в брокере Eclipse отсутствует механизм, необходимый для идентификации устройства CC3220S. Взаимная аутентификация может быть реализована пользователем при использовании настоящего сервера для конечного продукта. Также в демо отсутствует шаг проверки доменного имени, и неактивна опция проверки имени корневого сертификата сервера в каталоге сертификатов. Шаг проверки каталога сертификатов должен быть отключен при использовании certificate playground в процессе разработки, так как он не включает весь актуальный перечень доверенных корневых сертифицирующих организаций. Для конечной системы должен быть использован конечный каталог сертификатов, и TI рекомендует как разрешать проверку каталога сертификатов, так и проверять доменное имя.

Примечание: Срок действия корневого сертификата для брокера Eclipse со временем истекает. Пользователь должен убедиться в том, что сертификат, загружаемый в последовательную Flash-память – самой последней версии, иначе возможен сбой подключения к брокеру.

В дополнение к возможности удаленного управления и мониторинга состояния через MQTT, CC3220 позволяет обновить ПО через облако. В данной референсной разработке используется библиотека OTA из состава CC3220 SimpleLink SDK для реализации OTA-обновлений из облака. В рамках данной разработки в качестве сети доставки контента (CDN) выбран Dropbox, но реализация OTA может быть изменена для поддержки иных CDN.

При запуске демо из предподготовленного проекта UniFlash Image Creator для выполнения обновлений системой используется переконфигурированная учетная запись Dropbox. Когда демо уже подключено к сети, и пользователь проверил возможность связи с замком через брокер MQTT, может быть запущено OTA-обновление из облака путем публикации сообщения по теме 4 от другого клиента, подписанного CC3220, что было рассмотрено в описании отправки и получения сообщений (MQTT). Получение сообщения по теме 4 сигнализирует приложению wifi_doorlock перейти к шагу «RUN» автомата состояний OTA.

Когда OTA работает, демонстрационная программа устанавливает безопасное HTTP-соединение с сервером Dropbox и проверяет, есть ли доступная версия программного обеспечения с более высоким номером версии, чем та, которую устройство выполняет в настоящее время. Если найдено обновление – устройство загружает все компоненты OTA в файл .tar и сохраняет его в файловой системе в режиме защищенного файла. Когда обновление успешно и полностью загружено, автомат состояний OTA запрашивает системный сброс. Управляющая служба выполняет его, и система перезагружается с новой версией ПО. Если перезагрузка системы происходит успешно, и она вновь подключается к сети, система фиксирует новую версию ПО, обозначая ее как актуальную для всех будущих перезапусков.

Для выполнения OTA-обновления, поддерживаемого данной разработкой, с использованием своего аккаунта Dropbox и образа OTA, вам необходимо выполнить следующие шаги:

  1. создайте и настройте аккаунт разработчика Dropbox в соответствии с шагами 1…10 «Getting Started With the Dropbox™ Cloud Delivery Network (CDN)» из отчета о применении «CC3x20 SimpleLink Wi-Fi and Internet of Things Over-the-AirUpdate»;
  2. Обновите файл otauser.h библиотеки OTA, как указано в шаге 10 «Getting Started With the Dropbox™ Cloud Delivery Network (CDN)» из отчета о применении «CC3x20 SimpleLink Wi-Fi and Internet of Things Over-the-AirUpdate»;
  3. откройте файл OtaJson.c в библиотеке OTA и увеличьте размер MAX_METADATA_FILENAME до 150 (это позволит использовать более длинные имена путей к файлам обновления в аккаунте Dropbox и может быть при необходимости настроено);
  4. откройте файл OtaArchive.h библиотеки OTA и увеличьте значение определения MAX_BUNDLE_CMD_FILES до 12, чтобы все пользовательские файлы образа wifi_doorlock могли быть включены в пакет;
  5. откройте файл ota.h библиотеки OTA и увеличьте значение OTA_BLOCK_SIZE до 11000;
  6. сделайте пересборку библиотеки OTA и убедитесь, что новая библиотека связана с приложением wifi_doorlock в рабочем пространстве;
  7. сделайте пересборку приложения wifi_doorlock;
  8. откройте предподготовленный проект UniFlash Image Creator для приложения wifi_doorlock, после чего замените файл mcuimg.bin двоичным файлом приложения wifi_doorlock, собранного в шаге 7;
  9. перепрограммируйте LaunchPad новым приложением, содержащим ваши данные аккаунта Dropbox и информацию о директориях;
  10. (опционально) чтобы убедиться в корректности работы обновленного ПО, сделайте небольшое изменение в приложении wifi_doorlock, затем пересоберите его. Например, попробуйте увеличить значение определения APPLICATION_VERSION в wifi_doorlock_app.h;
  11. (опционально) замените файл mcuimg.bin в проекте UniFlash двоичным файлом, созданным в шаге 10.
  12. нажмите кнопку «Generate Image» в UniFlash Image Creator;
  13. на странице «Generate Image» нажмите кнопку «Create OTA»;
  14. при вводе имени файла приватного ключа OTA нажмите «Browse» и выберите файлder из SDK (<Директория установки SDK>/<SDK Version>/tools/cc32xx_tools/ota-example-cert/dummy_ota_vendor_key.der);
  15. нажмите кнопку «Create OTA» в диалоге, когда будет показан корректный приватный ключ;
  16. сохраните сгенерированный файл и загрузите его в аккаунт Dropbox в папку, совпадающую с определением OTA_VENDOR_DIR файла otauser.h (например, Apps/OTA_R2/OTA_R2_MCU/);

После выполнения этих шагов и программирования LaunchPad новым ПО может быть выполнено OTA-обновление путем следования этим же шагам при оценке приложения из предподготовленного проекта UniFlash Image Creator.

Тестирование и результаты

Производительность TIDC-01005 оценивалась на основе комбинации тестов на прохождение/непрохождение и измерений энергопотребления ключевых компонентов системы. Следующие разделы представляют собой описание самих тестов и их результатов. 

Тесты на прохождение/непрохождение

Таблица 9 представляет собой набор тестов на прохождение/непрохождение, использованных для оценки производительности TIDC-01005. Все тесты были выполнены с использованием ПО, предоставляемого с TIDC-01005 и аппаратной конфигурации, описанной в разделе  о необходимой аппаратуре и программном обеспечении

Таблица 9. Результаты тестов на прохождение/непрохождение

Описание теста Результат
Предоставление доступа к новой сети Wi-Fi с использованием точки доступа AP Успешно
Предоставление доступа к новой сети Wi-Fi с использованием T ISmartConfig Успешно
Предоставление доступа к новой сети Wi-Fi с использованием BLE Успешно
Автоматическое подключение по сохраненному профилю при сбросе/выходе из гибернации, если профиль существует Успешно
Получение системой команд из облака на запирание/отпирание и соответствующее управление двигателем Успешно
Отправка системой состояния замка в облако при запросе пользователя Успешно
Успешное обновление ПО системы и использование OTA-обновления на основе облака Успешно

Измерения потребляемой мощности

Энергопотребление – это ключевая характеристика электронных интеллектуальных запирающих устройств, зачастую оснащенных батарейным питанием. Для системы TIDC-01005 было произведено несколько измерений энергопотребления, которые могут быть использованы для оценки срока службы батареи системы электронного интеллектуального замка на основе представленных устройств. В частности, были измерены значения мощностей, потребляемых CC3220S (хост-МК и сетевым Wi-Fi-процессором), CC2640R2F (беспроводной МК Bluetooth Low Energy) и DRV8837 (низковольтный драйвер коллекторного двигателя постоянного тока), так как подсистемы беспроводной связи и двигателя обычно имеют наибольший вклад в среднее значение мощности, потребляемой системой. Измерения мощности выполнялись с выключенными датчиками, отключенной службой датчиков в ПО и исключенной из схемы измерений платы BOOSTXL-SENSORS.

Потребление мощности CC3220S измерялось во время разных действий, происходивших в процессе штатной работы системы. Потребление мощности во время настройки параметров Wi-Fi CC3220S не измерялось, поскольку это требуется лишь при первом включении системы и, вероятнее всего, в дальнейшем применяется лишь несколько раз за весь период ее работы. Во время настройки параметров Wi-Fi через AP потребление CC3220S выше, чем во время обычного функционирования, в котором CC3220S работает в режиме станции. Мощность, потребляемая при работе с BLE, отражает активную мощность МК. Также не измерялось потребление в процессе OTA-обновлений по эфиру, так как они могут иметь место лишь несколько раз за все время жизни продукта и не внесут значительный вклад в среднюю потребляемую системой мощность.

Когда период первоначального подключения к сети Wi-Fi завершен, и система успешно подключилась к сети Wi-Fi, начинается режим штатного функционирования. В течение этого периода система пытается удерживать МК CC3220S и сетевой процессор в режиме малого энергопотребления, сокращенно – LPDS, за исключением следующих ситуаций:

  • приема AP-маячка либо иного широковещательного пакета;
  • отправки сообщения «Keep-alive» в точку доступа;
  • отправки сообщения «Keep-alive» на сервер MQTT;
  • получения сообщения от сервера;
  • отправки сообщения на сервер.

Потребление мощности CC3220S измерялось, когда система находилась в подключенном состоянии ожидания (получая AP-маячки) и когда система получала или отправляла сообщения брокеру MQTT. Потребление мощности CC2640R2F производилось как при использовании BLE, так и в режиме Idle после завершения процесса первоначального подключения к Wi-Fi. Потребление мощности DRV8837 измерялось в моменты, когда DRV8837 управлял двигателем, подключенным к нагрузке, а также при удержании в спящем режиме. 

Испытательный стенд

Потребление модулей CC3220S, CC2640R2F и DRV8837 измерялось независимо, с использованием Keysight DC Power Analyzer (Keysight N6700 Power Modules). Во время тестирования анализатор мощности постоянного тока питал каждое устройство постоянным напряжением и измерял потребление тока. 

Во время измерения потребляемой мощности CC3220S, платы CC3220S и CC2640R2F не были соединены, что позволяло питать устройства независимо. При этом между платами, были сохранены лишь соединения, необходимые для NPI. Также был убран резистор R141 CC3220S LaunchPad. R141 использовался для формирования низкого уровня напряжения на входе одного из переключателей CC3220S LaunchPad (SW2 в Rev. A). Резистор должен быть убран при измерении мощности как на CC3220S, так и на CC2640R2F LaunchPad, поскольку вывод, используемый переключателем – это P4, который используется для NPI и может повысить потребление мощности, пока NPI не задействован (рисунок 21).

Рис. 21. Расположение R141 на CC3220S LaunchPad™

Рис. 21. Расположение R141 на CC3220S LaunchPad™

При питании CC3220S LaunchPad от анализатора мощности постоянного тока плата была настроена в соответствии с разделом «Battery Powering Onlythe CC3220 and U8 (Onboard Serial Flash)» руководства пользователя «CC3220 SimpleLink™ Wi-Fi® Launch Pad™ Development Kit Hardware User’s Guide», и работала в автономном режиме (была запрограммирована, а не загружена через отладчик), чтобы выполнять задачи микроконтроллера по управлению питанием.

Анализатор мощности при питании CC3220S LaunchPad был настроен на выходное напряжение постоянного тока 3,3 В. В качестве точки доступа во время тестов использовалась Netgear AT&T hotspot при отсутствии других подключенных станций. Измерения велись в трех разных режимах работы, возникавших при штатном функционировании системы:

  • TIDC-01005 простаивает в подключенном к AP состоянии;
  • TIDC-01005 получает запрос о состоянии замка и отправляет данные о состоянии в облако;
  • TIDC-01005 получает из облака команду блокировки/разблокировки и включает выход PWM для управления драйвером двигателя.

Примечание: При использовании конфигурации LaunchPad в соответствии с разделом «Battery Powering Only the CC3220 and U8 (Onboard Serial Flash)» руководства пользователя «CC3220 SimpleLink™ Wi-Fi® LaunchPad™ Development Kit Hardware User’s Guide» канал обратных данных UART отключается и вывод отладки становится недоступен.

Для точного измерения потребления мощности CC2640R2F должны быть сняты все джамперы CC2640R2 LaunchPad. В отчете о применении «Measuring Bluetooth Low Energy Power Consumption» есть пример LaunchPad со снятыми джамперами. При снятых джамперах CC2640R2F питался посредством подключения выходов VDD анализатора мощности к одному из выводов 3V3 LaunchPad, а вывода GND — к одному из контактов GND-платы. При измерении потребления мощности было настроено выходное напряжение постоянного тока 3,3 В. 

Примечание: При измерении мощности со снятыми джамперами JTAG программирование и отладка микросхемы становится невозможной.

Для точного измерения мощности, потребляемой ИС DRV8837 модуля DRV8837EVM, необходима некоторая аппаратная доработка в соответствии с разделом «Аппаратная часть». Полный список доработок аппаратной части для точного измерения энергопотребления DRV8837 (рисунок 22):

  • уберите резисторы R3 и R4 (0 Ом) с нижней стороны DRV8837EVM;
  • уберите регулятор напряжения с низким падением LP2985 (REG1) с нижней стороны DRV8837EVM;
  • уберите подтягивающий резистор R1 вывода DIR с верхней стороны DRV8837EVM;
  • уберите МК MSP430G2131 (U1) DIR с верхней стороны DRV8837EVM.
Рис. 22. Нижняя сторона DRV8837EVM с выделенными компонентами, которые необходимо убрать

Рис. 22. Нижняя сторона DRV8837EVM с выделенными компонентами, которые необходимо убрать

После того как все модификации выполнены, для измерения энергопотребления необходимо создать следующие соединения с DRV8837EVM (рисунок 23):

Рис. 23. Верхняя сторона DRV8837EVM с выделенными компонентами, которые необходимо убрать

Рис. 23. Верхняя сторона DRV8837EVM с выделенными компонентами, которые необходимо убрать

  • подключите контрольные точки IN1 и IN2 к контактам P16 и P17 CC3220 LaunchPad соответственно;
  • подключите верхний контакт JP2 (nSleep) к контакту P18 CC3220 LaunchPad;
  • подключите нижний контакт JP2 (VCC DRV8837) к одному из выводов 3V3 CC3220 LaunchPad;
  • подайте питание через J1 (VM и GND).

При тестировании TIDC-01005 микросхема DRV8837 питалась от входного напряжения 5 В.

Результаты тестирования

Средний ток, потребляемый CC3220 в режиме idle connected (подключен к AP и принимает только AP-маячки или широковещательный трафик) с LSI 400 мс при получении нескольких DTIM составлял около 377 мкА. Мощность, потребленная в режиме idle connected, дает наибольший вклад в общее значение среднего энергопотребления, поскольку основную часть активного времени система должна проводить в именно этом режиме. Рисунок 24 отображает график измеряемого тока.

Рис. 24. График потребления тока CC3220S, в зависимости от времени в режиме idle connected при LSI, равном 400 мс

Рис. 24. График потребления тока CC3220S, в зависимости от времени в режиме idle connected при LSI, равном 400 мс

Когда из облака отправляется сообщение в TIDC-01005, CC3220S получает оповещение о том, что в буфере AP через DTIM для него появился пакет. В отклике на индикацию трафика CC3220S выходит из режима малого потребления и опрашивает AP на предмет сообщения. Влияние на энергопотребление системы может быть разным и зависит от того, какое именно сообщение было получено. Первым типом сообщения является команда блокировки/разблокировки. Когда приходит данная команда, сетевой процессор активизируется, получает сообщение и отправляет команду хост-МК. Последний, в свою очередь, обрабатывает команду и формирует управление двигателем в соответствующем направлении в течение двух секунд. Средний ток потребления CC3220S в процессе выполнения команды блокировки/разблокировки составлял порядка 12,1 мА, что проиллюстрировано на рисунке 25.

Рис. 25. Потребляемый ток CC3220 в рабочем цикле блокировки или разблокировки

Рис. 25. Потребляемый ток CC3220 в рабочем цикле блокировки или разблокировки

На данном графике первый пик тока после курсора отражает момент детектирования сообщения сетевым процессором и выхода из режима малого потребления для поллинга AP. По получении сообщения МК активизируется сетевым процессором, после чего сообщение отправляется в МК на обработку. Потребляемый ток сохраняет среднее значение на уровне 11…12 мА в течение всех двух секунд, пока МК активен и управляет двигателем. Пики меньшей амплитуды возникают в активном режиме МК и отражают прием сообщений в соответствии с работой AP-маячка. Эти сообщения приема маячка возникают ввиду того, что CC3220S ожидает продолжения LSI до момента, когда будет достигнут таймаут получения сообщения. Снижение задержки достигается благодаря тому, что CC3220S не сразу входит в LSI, когда системе отправляется несколько сообщений с малым интервалом, причем эта отправка не оказывает большого влияния на потребление мощности.

Вторым типом сообщений, которые может получать TIDC-01005, является запрос состояния замка. Когда приходит такой запрос, сетевой процессор переходит в активный режим, получает сообщение и пересылает запрос в хост-МК. Последний, в свою очередь, обрабатывает запрос и дает ответ, отправляя сообщение с информацией о состоянии замка обратно в облако. Средний ток, потребляемый CC3220S при ответе на запрос о состоянии замка, составляет примерно 11,8 мА. На рисунке 26 изображен график потребления тока для рассматриваемого случая.

Рис. 26. Потребление тока CC3220 при запросе о состоянии замка

Рис. 26. Потребление тока CC3220 при запросе о состоянии замка

Аналогично ситуации с командой блокировки/разблокировки, первым пиком от курсора является момент детектирования полученного сообщения и активизации для поллинга AP. Когда сообщение получено, оно направляется в МК на обработку. На графике рисунка 26 видно, что ток значительно возрастает в средней части цикла, в которой происходит передача состояния замка в облако (MQTT-брокер). По получении и подтверждении сообщения брокером MQTT система переходит к состоянию idle connected. Из графика видно, что система снова ожидает возникновения таймаута перед возвратом в настроенный режим LSI.

Средний ток, потребляемый CC2640R2F SNP (при advetrizing, сопряжении и обмене аутентификационными данными AP) составил около 211,8 мкА. Во время простоя (до и после ввода Wi-Fi-настроек), среднее потребление тока CC2640R2F было измерено на уровне 40 мкА. На рисунках 27 и 28 показаны графики потребления тока при обоих измерениях.

Рис. 27. Потребление CC2640R2F в процессе начального подключения

Рис. 27. Потребление CC2640R2F в процессе начального подключения

Рис. 28. Потребление CC2640R2F при простое

Рис. 28. Потребление CC2640R2F при простое

Также измерялось энергопотребление DRV8837 в моменты событий блокировки/разблокировки. В частности, измерялся ток, потребляемый при питании двигателя от 5 В и управлении исполнительным механизмом от DRV8337. В качестве исполнительного механизма использовался дверной засов. Среднее значение потребляемого тока при блокировке/разблокировке засова составляло порядка 77,6 мА и 73,1 мА соответственно в течение двухсекундного интервала управления двигателем. Рисунки 29 и 30 отражают график потребления.

Рис. 29. Ток DRV8837 во время блокировки двери

Рис. 29. Ток DRV8837 во время блокировки двери

Рис. 30. Ток DRV8837 во время разблокировки двери

Рис. 30. Ток DRV8837 во время разблокировки двери

В промежутках между событиями управления блокировкой CC3220S ИС DRV8837 удерживалась в спящем режиме. Средний ток драйвера двигателя при удержании DRV8837 в спящем режиме был равен около 0,099 мкА, это измерение можно увидеть на рисунке 31.

Рис. 32. Ток спящего режима DRV8837

Рис. 32. Ток спящего режима DRV8837

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

Оценка срока службы батареи

Данные из раздела «Результаты тестирования» могут быть использованы для оценки срока службы батареи, от которой питается система в данном проекте. На основе этих результатов и с учетом допущения, что электронное интеллектуальное запирающее устройство закрывается или открывается 24 раза в день, пользователи могут оценить мощность, потребляемую каждой подсистемой.

Основными параметрами подсистемы Wi-Fi, влияющими на оценку срока службы батареи, являются:

  • напряжение питания CC3220: 3,3 В;
  • ток в состоянии idle connected: 377 мкА;
  • средний ток в течение события блокировки/разблокировки: 12,12 мА;
  • длительность события «блокировка»: 2 с;
  • средний ток при чтении состояния замка: 11,82 мА;
  • длительность события «lock status»: 1,6 с.

Формула 1 дает среднюю мощность Wi-Fi в простое:

s1

Формула 2 дает среднюю мощность Wi-Fi за день, с учетом блокировки/разблокировки:

s2

Формула 3 дает среднюю мощность Wi-Fi за день, с учетом проверки состояния замка:

s3

Формула 4 помогает подсчитать примерное среднее значение мощности Wi-Fi:

s4

Основными параметрами подсистемы BLE, влияющими на расчетное время работы от батареи, являются:

  • напряжение питания CC2640R2F: 3,3 В;
  • среднее значение потребляемого CC2640R2F тока после раздачи: 40,23 мкА.

По формуле 5 получаем среднюю мощность BLE:

s5

Основными параметрами подсистемы управления двигателем, влияющими на расчетное время работы от батареи, являются:

  • напряжение питания двигателя DRV8837: 5 В;
  • среднее значение потребляемого тока DRV8837 в спящем режиме: 0,099 мкА;
  • средний ток при закрытии засова: 77,62 мА;
  • средний ток при открытии засова: 73,15 мА;
  • среднее время управления двигателем: 2 с.

По формуле 6 высчитывается средняя мощность драйвера двигателя в простое:

s6

Средняя мощность драйвера двигателя во время блокировки вычисляется по формуле 7:

s7

Расчет по формуле 8 дает среднюю мощность драйвера двигателя во время разблокировки:

s8

Формула 9 дает оценку средней мощности драйвера двигателя:

s9

Используя расчеты мощности, потребляемой подсистемами Wi-Fi, BLE и драйвера двигателя, пользователи могут оценить общее значение средней мощности, потребляемой системой (формула 10):

s10

Оценка общего значения средней мощности, потребляемой системой, может быть использована для оценки времени работы от батареи с использованием теоретической энергоемкости источника питания. Для данного расчета энергетическая емкость принимается равной 18000 мВт⋅ч, и вычисление времени работы от батареи ведется по формуле 11:

s11

Оригинал статьи

Исчтоник: Компэл

Добавить комментарий

Защитный код
Обновить

Обсудить эту статью на форуме (0 ответов).

Copyright 2019 © simple-devices.ru.
При использовании материалов ссылка на simple-devices.ru обязательна.