Автор: Сергей Безруков (aka Ser60), sergeilb60@mail.ru
Опубликовано 19.08.2016
Создано при помощи КотоРед.

Сегодня в свете бурного развития направления IoT (Internet of Things) приёмо-передающие устройства на базе законченных радио-модулей вызывают всё больший интерес у разработчиков. Естественно встаёт вопрос о разработке программных приложений на их основе. Все фирмы-производители поддерживают программное обеспечение для своей продукции и для её широкого внедрения ищут способы упрощения средств разработки приложений. Уникальному подходу фирмы Silicon Labs для их BLE (Bluetooth Smart) устройств, и посвящена настоящая статья.

Я уже рассказывал о подходах фирм Anaren/Broadcom [1] и Cypress [2,3]. Обе они предлагают развитые интерактивные графические интерфейсы с пользователем для программирования своих BLE модулей, настолько простые, что позволяют быстро вникнуть в тему даже начинающим. Подходы этих фирм предполагают знание лишь основ технологии BLE, предоставляя среде разработки дополнить проект необходимыми техническими деталями. Прежде чем переходить к описанию подхода Silicon Labs, рассмотрим вкратце её BLE продукцию.

Бóльшую часть своих настоящих BLE чипов и модулей фирма унаследовала от финской компании Bluegiga после поглощения её в середине 2015. В состав линейки изделий фирмы хорошо зарекомендовавшие себя модули BLE112 и BLE113, выполненные на основе чипов CC2540 и CC2541 от Texas Instruments. Фирма Bluegiga ещё до поглощения разработала с нуля свой BLE стек для этих и других чипов и язык программирования BGScript, о котором речь пойдёт ниже. Имеются и комбинированные Bluettoth Smart Ready модули BT121 и BT111 способные работать с протоколами Bluetooth Classic и BLE. Заметим, что BT121 содержит микроконтроллер архитектуры ARM Cortex-M0 от ST-Micro и может также выполнять программу пользователя. Наконец, имеются совсем новые модули BGM113 и BGM111, разработанные уже после поглощения Bluegiga. Оба последних модуля основаны на новых ARM Cоrtex-M4F микроконтроллерах семейства EFR32. Мы рассмотрим подробнее работу с одним из самых новых модулей BGM111, появившегося на рынке осенью 2015.

Отличительной особенностью всех модулей фирмы является высокая чувствительность и повышенная выходная мощность (до +8 и даже +12 dBm) по сравнению с BLE модулями других фирм. Модуль BGM111 имеет малые размеры (всего 13×15×2.2 мм) и программируется через SWD/JTAG интерфейс или UART. На плате модуля установлена чип-антенна.

Для работы с модулем имеется соответствующий Кит SLWSTK6101A с JLink программатором на борту, графическим дисплеем, сенсором Si7021, и платой расширения (на снимке ниже не показана). Ethernet коннектор на плате может быть использован для программирования модуля через проводную сеть, при этом USB интерфейс используется только для питания платы. Это позволяет использовать Кит в составе прототипа устройства и программировать его дистанционно. Если эта опция не требуется, отладку можно производить и через USB интерфейс. С помощью Кита можно программировать чипы вне демо-платы.

Следует отметить, что несмотря на большую мощность (+8 dBm) и заявленную дальность связи модуля до 200 м, реализовать такую дальность на основе этих демонстрационных плат невозможно, поскольку на дочерней плате установки модуля (видимо из-за геометрических ограничений состыковки с motherboard) не соблюдены рекомендации фирмы по размерам контура земли вокруг чипа.

Перейдём к разработке программы приложения. Для этого имеется неколько возможностей. Первая – использовать API стека BLE и написать всё приложение на языке С, отладив его в среде Simplicity Studio фирмы или в среде IAR EWARM. Это наиболее сложный из рассматриваемых и в тоже время наиболее гибкий способ, позволяющий использовать все аппаратные возможности модуля и программные возможности стека BLE. В рамках одной статьи описать это нереально, для получения более развёрнутого представления рекомендуется прочитать как минимум документы [4,5]. Вторая возможность – использовать модуль в режиме NCP (Network Co-Processor), в котором МК модуля будет лишь поддерживать BLE стек и коммуницировать с внешним МК, на котором реализована вся логика приложения. При этом внешний МК может работать со стеком модуля через эксклюзивный последовательный интерфейс BGAPI (см. правую часть диаграммы ниже). Наконец, при используемом нами подходе модуль работает в режиме SoC (System on Chip) и его МК выполняет функции стека BLE и программу пользователя (левая часть диаграммы), написанной на языке BGScript.

Полное описание скриптового языка BGScript приведено в [6]. Овладеть этим языком тривиально, всё его описание занимает всего 9 неполных страниц в [6]. Для упрощения общения с BLE стеком язык BGScript имеет свои API, полное описание которых содержится в документе [7] на вебсайте фирмы. Там-же описано обращение к функциям BGAPI на языке C внешним МК при использовании модуля в режиме NCP.

Итак, что-же мы хотим запрограммировать? Для сравнения подходов фирм запрограммируем приложение, описанное в [3]. Именно, наше устройство будет предоставлять стандартные сервисы Environmental Sensing и Battery. Иными словами, устройство будет измерять температуру и влажность воздуха, а также состояние своей батареи, и отсылать эти данные клиентам по запросу после соединения. Исходный код проекта распределён по трём текстовым файлам, упомянутым в заголовочном файле проекта bgm111ess.bgproj. Это XML файл с очевидным синтексом, который определяет назначение каждого из вовлечённых файлов. После компиляции проекта получим файл bgm111ess.bin для загрузки в МК. В этом файле будет наше приложение вместе со стеком BLE.

Определение GATT сервисов, поддерживаемых нашим устройством, а также их характеристик и дескрипторов, содержится в файле gatt.xml (см. файлы проекта в приложении). Я создал его в Notepad++ с использованием UUID аттрибутов, принятых группой BLE SIG и представленных на её вебсайте [8]. Синтакс XML файла описания BLE профиля см. в [9]. Когда я делал это в первый раз, я неоднократно вспоминал с благодарностью графический интерфейс системы PSoC Creator в подходе фирмы Cypress [2,3], вставляющий все GATT аттрибуты и их UUID автоматически. Но, всё дело привычки, и буквально после пары дней работы с BGM111 я освоился и перестал считать многократное обращение к ресурсу [8] принципиальным неудобством.

Описав сервисы нашего устройства, следующим шагом является конфигурирование периферии в XML файле hardware.xml. В нашем случае для проекта потребуются 3 модуля МК: I2C интерфейс, DC-DC конвертер, и ADC для измерения напряжения батареи. Понижающий DC-DC конвертер уже имеется на плате модуля и требуется для обеспечения его малого токопотребления. При его отключении регулировка напряжения ядра осуществляется линейным стабилизатором модуля. При этом уменьшаются шумы и помехи и расширяется диапазон напряжения питания, но и ощутимо снижается эффективность использования источника питания. Для конфигурирования I2C нужно только прописать какие выводы модуля использовать для этого. В случае демо-платы сенсор Si7021 подключён к модулю через выводы PC10/PC11. Параметр sleep позволит модулю входить в режим глубокого сна EM2 в периоды неактивности, в котором его токопотребление не превосходит 2.5 мкА.

Наконец, мы вплотную подошли к описанию логики приложения на безтиповом скриптовом языке BGScript. В начале файла bgm111ess.bgs декларированы все используемые нами переменные (строки 2 – 8) и процедура чтения температуры и влажности из датчика Si7021 (строки 10 – 30). Переменные определяются с помощью служебного слова dim и представляются в МК как 32-битные знаковые числа. Вызовы подпрограмм и API функций производится посредством call. Возвращаемые API функциями значения присваиваются переменным, определённым в скобках после передачи параметров функции в строке вызова.

Остальная часть скрипта содержит функции обработки событий стека. Каждая такая функция начинается со слова event, передаваемые в функции параметры описаны в [6]. В нашем случае используются 4 события, структурно показанные ниже. Первое событие генерируется по подаче питания на модуль и содержит код инициализации системы. Второе генерируется по разрешению и запрещению клиентом передачи нотификаций об изменении параметров среды или напряжения батареи. Третье генерируется таймером, определяющим период измерения параметров среды (в нашем случае 1 сек). Наконец, последнее генерируется при разрыве соединения с клиентом, в случае чего следует возобновить передачу advertisement для обеспечения возможности новых соединений клиентов с нашим сервером. Конечно, это далеко не все события, генерируемые стеком BLE в ходе работы нашего приложения, но остальные обработчики событий будут автоматически заменены пустыми заглушками.

В обработчике первого события мы инициализируем переменные в RAM, определяем мощность передатчика и опорник АЦП, устанавливаем передачу advertisement раз в секунду на всех трёх BLE каналах (37,38,39), и разрешаем всем клиентам обнаружить наш сервер и установить с ним соединение.

По разрешении или запрещении клиентом передачи нотификаций нашим сервером, вызывается второй обработчик событий, где мы запоминаем статус разрешения посылки нотификаций (да/нет) в переменных notifyT, notifyH, notifyB, соответственно для температуры, влажности, и состояния батареи. Ниже в строках 72 – 78 показана часть кода для notifyB, остальные переменные устанавливаются аналогично. Помимо этого, мы запускаем программный таймер (строки 80 – 85) для ежесекундного измерения параметров среды. Если все нотификации будут запрещены клиентом, таймер останавливается (строки 86 – 91) и измерение всех параметров, соответственно, прекращается.

В обработчике прерываний таймера производства ежесекундных измерений мы читаем данные из сенсора Si7021 (строка 101), и если разрешена посылка соответствующей нотификации, то вычисляем значение параметра среды по сырым данным сенсора (строка 105 для температуры). Затем записываем вычисленное значение в GATT database сервера (строка 109) и посылаем его клиенту как нотификацию (строка 111). Для минимизации числа передач нотификации посылаются только если измеренное значение отличается от посланного ранее. Ниже приведён код отсылки нотификаций температуры. Обработка остальных данных производится аналогично. Данные температуры и влажности, согласно стандарту сервиса ESS, следует представлять умноженными на 100, тогда они будут автоматически форматироваться клиентом как числа с двумя дробными знаками. Данные для сервиса Battery, также согласно соответствующему стандарту, следует представить как процент по отношению к максимальному напряжению батареи (у нас 3.6В). Напряжение батареи измеряется SoC на выводe AVDD чипа с помощью внутреннего мультиплексора каналов АЦП.

Наконец, последний обработчик прерываний в случае разрыва соединения возобновляет посылку advertisement (строка 143), останавливает таймер измерений (строка 146) и запрещает нотификации параметров (строки 150 – 152).

Приложение готово, следующий этап – это его компиляция и загрузка в МК. Эти действия можно осуществить из командной строки как описано в руководствах. Однако, можно использовать и графический интерфейс. В любом случае загружаем с сайта фирмы систему Bluetooth Smart SDK и после её установки вызываем программу BG-Tool и подключаем Кит к компьютеру. Система автоматически распознает порт JLink адаптера и запросит какой Кит используется. Затем входим в закладку Upload tool, в поле Project File устанавливаем путь к файлу проекта (у нас bgm111ess.bgproj) и нажимаем Build.

Если ошибок не обнаружено, в нижней строке окна Build result получим ALL OK, и имя сгенерированного файла для загрузки автоматически появится в поле Binary File. Нажав на Upload, дожидаемся DONE в нижней строке окна загрузки и нажимаем кнопку Reset на демо-плате Кита, тем самым запуская приложение в режиме Advertising. Отметим, что приложение вместе со стеком занимает около 120К флеша.

Перед тем как тестировать приложение на соединение мне интересно было измерить токопотребление в режиме Advertising. На демо-плате Кита имеется измеритель потребляемого тока с периодом 100 микросекунд. Данные измерителя можно прочитать инструментом Energy Profiler, входящего в состав штатной системы разработки приложений фирмы Simplicity Studio. Установив систему, увидим на экране пики токопотребления в момент передачи advertisement с периодом в 1 сек, согласно установленным в программе параметрам. В верхней строке показано среднее токопотребление Avg Current за период измерений.

Но не обольщайтесь амплитудой пиков токопотребления порядка 1 мА при мощности передатчика 0 dBm. Передача adversisement занимает около 3.8 мс и разрешения дисплея просто не хватает, чтобы отобразить все результаты измерений. Для получения реальной картины следует растянуть график по обоим осям. В результате увидим следующую кривую для одного из пиков.

Точки на графике соответствуют фактически измеренным значениям тока и явно прослеживаются 3 горба при передаче advertisement на трёх каналах. Согласно ДШ, при такой мощности передатчика токопотребление должно быть около 8.2 мА. Однако, не ясно, относится-ли это только к передатчику, или ко всему чипу. Похоже, что скорее первое, и дополнительные 2 мА потребляются спящим в момент передачи ядром МК в режимe EM1. В паузах между передачей advertisement суммарное токопотребление модуля с сенсором снижается примерно до 2-3 мкА при спящем ядре в режиме EM2. Следует отметить, что фирма постоянно совершенствует стек, и где-то месяц назад при прошлом его релизе пики тока были на уровне 15 мА. Видимо, при этом МК не спал во время передачи (может ещё что-то). Потребление ядра Cortex-M4F на уровне 7-8 мА в активном режиме при тактировании на частоте 38 мгц вполне нормально. Примерно такое потребление у нас в паузах между горбами, когда ядро перестраивает радио на новую частоту. Вот ещё один график для максимальной мощности передатчика +8 dBm.

Для тестирования работы сервера в режиме соединения я использовал один из донглов, работа с которым подробнее описана в [3],

... а также систему CySmart фирмы Cypress. В результате увидим знакомую по моим прежним публикациям и ожидаемую таблицу всех обнаруженных донглом аттрибутов сервера (см. детали в [3]).

По поводу этой таблицы интересно отметить, что в ней присутствуют дескрипторы характеристик, которые я не декларировал явно в файле описания профиля gatt.xml. Вероятно, система добавляет их автоматически при компиляции проекта. К слову сказать, что в настоящей версии документа [9] вообще отсутствует возможность спецификации дескрипторов. Однако, как выяснилось, XML таг <desсriptor> поддерживается системой, и его описание просто «забыли» включить в документацию. Это, кстати, не единственный «забытый» момент.

Какой-же из трёх модулей лучше – нынешний, или описанные в [1] и [3]? Все модули имеют примерно одинаковые размеры и могут выполнять программу пользователя. У модуля на A20737A от Anaren/Broadcom [1] имеется печатная антенна, которая при всех равных обычно более эффективна чем маленькая чиповая. У модулей BGM111 и EZ-BLE от Cypress чиповыe антенны и последний по габаритам меньше всех. Далее, МК в модуле [1] имеет архитектуру Cortex-M3, а в [3] – Cotrex-M0. Модуль BGM111 содержит Cortex-M4F и по этому параметру превосходит обоих конкурентов. Кроме того, у него гораздо бóльшая выходная мощность и меньшее токопотребление. Эти обстоятельства делают модуль очень интересным для разработчиков, что подтверждается блогом на вебсайте фирмы. Потребление радио у BGM111 в режимах приёма и передачи примерно в 2 раза ниже, чем у модуля в [3]. Однако, как следует из приведённых выше измерений и данных в [2] при мощности 0 dBm, среднее потребление обоих модулей в режиме Advertising с периодом 1 сек примерно одинаковое и находится в пределах 23 – 25 мкА.

А как обстоят дела с программным обеспечением? У каждой из трёх фирм имеются свои достаточно простые и интуитивные подходы. Mодуль [1] мы программировали в системе Anaren Atmosphere путём рисования схемы алгоритма на дисплее и кода там вообще не видели (хотя можно всё писать на С на броадкомовском IDE). Модуль [3] мы программировали частично в графическом конфигураторе, частично на С с использованием системы PSoC Creator и её API. Полная длина исходного кода для нынешнего модуля и для [3] примерно одинаковая. Однако, API фирмы Cypress позволяют получить доступ к каждому винтику системы и настроить буквально каждый бит. В контрасте с этим, функции BGScript API для BGM111 (на настоящий момент) очень ограничены. В частности, ими (и языком BGScript) не поддерживаются данные с плавающей точкой, что фактически сводит на нет все преимущества архитектуры M4F для приложений, где плавающая точка существенна. Более того, код на языке BGScript не компилируется, а интерпретируется ядром. Скорость выполнения кода на BGScript всего порядка тысячи инструкций в секунду. Это делает невозможным обработку некоторых данных в реальном времени. Настройки периферии скриптом также ограничены. Например, нет контроля скорости тактирования I2C и на сегодня она фиксирована на уровне примерно 46 кгц. Пока вообще нет доступа к SPI и ЦАП. Ещё отмечу, что обработчики прерывания на языке BGScript выпоняются атомарно. Иными словами, прерывания при работе каждого обработчика запрещены. Таким образом, скрипт подходит не для всех приложений. Однако, простота его для несложных проектов подкупает, в частности открывает широкую дорогу начинающим.

Отмечу, что язык BGScript разработан фирмой Bluegiga давно и первоначально для SoC на основе процессора 8051, или вообще для использования модулей в качестве ко-процессоров. Silicon Labs/Bluegiga постоянно улучшают возможности настроек модуля, выпуская новые и новые расширения функций API. Модули BGM111/BGM113 достаточно свежие и более-менее приличная версия BGAPI для них вышла только где-то в апреле 2016. В документах [4,5] описаны примеры программирования модулей на С, что позволяет получить гораздо более гибкую конфигурацию модуля и задействовать все его функции. Однако, это несравненно более сложно, чем подход описанный здесь, и заслуживает отдельной статьи. К сожалению, на сегодняшний день даже при использовании системы Simplicity Studio фирмы, и несмотря на то, что она основана на Eclipse, в качестве компилятора для модуля BGM111 (но не для всех других продуктов фирмы) можно использовать только IAR. И для BLE приложений, конечно, нужна версия IAR без ограничения на длину кода. Однако, в планах фирмы предполагается предоставление возможности для использования GNU ARM компилятора. Будем надеяться на улучшение этой ситуации в скором будущем.

Литература

1. Разработка BLE приложений в системе Anaren Atmosphere
2. Bluetooth Smart Broadcaster на RSoC фирмы Cypress
3. Реалиазция стандартного GATT-BLE профиля на RSoC фирмы Cypress
4. Silicon Labs UG136: Silicon Labs Bluetooth® Smart SoC Application Developer's Guide
5. Silicon Labs AN945: Bluetooth® Smart Application Development with IAR
6. Silicon Labs UG173: Blue Gecko BGScript™ Developer's Guide
7. Silicon Labs Bluetooth Smart Software API Reference Manual
8. GATT Services
9. Silicon Labs UG118: Blue Gecko Bluetooth® Smart Profile Toolkit Developer's Guide

Файлы:
Архив ZIP

Все вопросы в Форум.