О работе с Bluetooth модулями AMS001/002 фирмы Zentri

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

Фирма Zentri, недавно вошедшая в состав компании Silicon Labs, известна своими Bluetooth и WiFi модулями, использующими уникальный подход к разработке приложений на их основе. Уникальность состоит в упрощении реализации передачи данных за счёт использования программных продуктов фирмы, загружаемых в модули вместе со стеками соответствующих протоколов. Но, как это часто бывает на практике, чем проще общение с модулем, тем жёстче ограничения на его использование и ниже гибкость. Однако, для многих несложных IoT приложений ограничения эти вполне приемлимы, а простота использования приводит к быстрой разработке устройств даже при отсутствии у разработчика надлежащих глубоких знаний в области беспроводных технологий. Некоторые WiFi модули фирмы могут быть запрограммированы приложениями, разработанными в среде ZentriOS SDK фирмы. При этом достигается максимальная универсальнось и гибкость настройки приложений. Однако, Bluetooth модули этой системой не поддерживаются.

На момент написания статьи у фирмы имеется всего два Bluetooth модуля – AMS001 и AMS002. Оба модуля сертифицированы под протокол Bluetooth 4.1 с максимальной мощностью передачи +4dBm и имеют чувствительность -94dBm. Различаются модули наличием в первом из них понижающего DC-DC конвертера, что снижает среднее токопотребление в 2 раза как в режиме приёма, так и передачи. Соответственно, он несколько дороже его младшего брата. Здесь рассмотрен способ использования модулей, требующий минимального объёма программирования путём использования интерфейса с загруженной в модули легковесной операционной системой ZentriOS-S.

Пожалуй, операционная система слишком громкое название для этого программного продукта. Их у фирмы имеется несколько и ориентированы они под определённую область применения и периферию внутреннего МК. С фабрики модули приходят с установленным программным продуктом Zentri-AMS001/002. Продукт, кoторый мы будем использовать называется Zentri-I2CM. Он позволяет модулю работать в роли Peripheral и включает драйвер интерфейса I2C – отсюда и его название. Детали о других продуктах фирмы можно найти по ссылке [1]. Для загрузки каждого программного продукта у фирмы имеется приложение Zentri BLE Manager для iOS/Android смартфонов и планшетов Подробнее о работе с ним можно прочитать по ссылке [2], где всё подробно расписано в картинках. Для загрузки нового продукта в модуль следует создать аккаунт на сайте Zentri DMS [3], зарегистрировать там свой модуль, и далее использовать аккаунт для OTA (Over The Air) апдейтов. Это единственный способ загрузить в модуль иной программный продукт фирмы. При этом будет задействован Ваш смарт девайс, который должен иметь поддержку WiFi и Bluetooth 4.1+, поскольку загрузка ПО будет производиться в модуль через него. Отмечу, что у меня были проблемы с загрузкой ПО, вытянувшиеся в месячную переписку с тех-поддержкой фирмы. Мы никак не могли понять почему у них всё работает, а у меня, несмотря на их советы - нет, какие-бы телефоны и пр. я не использовал. В конце концов, мне пришлось выслать им свои «проблемные» модули. Оказалось, причина была всё-же в их приложении Zentri BLE Manager. Сейчас они его подправили и всё загружается без проблем. Тех-поддержка фирмы реально работает и достаточно быстро.

Для работы с модулями была собрана следующая тестовая схема. С помощью модуля IC1, целью является реализация дистанционного включения/выключения светодиода LED1 и чтения температуры с датчика IC3. Микросхема IC2 представляет собой сдвоенный ключ для отключения выводов 4 и 5 модуля от шины I2C, поскольку в перерывах между работой I2C интерфейса модуля на этих выводах присутствует уровень лог. нуля. Ключ управляется драйвером I2C автоматически через вывод 13 модуля. В чём мудрость или необходимость этого решения я не понял, но таковы правила игры. На тестовой плате (см. фото ниже) ключ IC2 ради простоты не устанoвлен и резисторы R2 и R3 непосредственно соединены с соответствующими выводами модуля.

Для предварительного знакомства с модулем использовался последовательный интерфейс связи с ним через USB-UART мост на основе CP2104 (на схеме показан пунктиром). Через этот проводной интерфейс (а также через безпроводный Bluetooth) в модуль можно посылать команды или изменять значения его переменных. Последние можно сохранить в энерго-независимой памяти модуля. Примерами команд являются установка и чтение логических уровней на вывoдах GPIO, генерация PWM, коммуникация с внешними устройствами через интерфейсы I2C, SPI, и.т.д. Всего имеется 3 режима работы модуля: локальный командный режим (local command), режим потоковой передачи данных (stream), и удалённый командный режим (remote command). Функционирование модуля в этих режимах графически представлено ниже:

В первом режиме подача команд в командный процессор модуля осуществляется через проводной UART интерфейс и выводы GPIO2/3. Во третьем – тоже самое, но через безпроводный Bluetooth интерфейс. Во втором режиме модуль работает как UART-Bluetooth мост: всё, что он принимает через Bluetooth передаётся на UART выводы и наоборот, минуя интерпретатор команд. Подробнее об этих режимах и переходах из одного в другой можно прочитать по ссылке [4]. Здесь будет рассказано об использовании модуля в каждом из этих режимов.

Работа с модулем через локальный UART интерфейс

Для работы в этом режиме предполагается дополнить модуль устройством связи через UART. Это может быть, например, внешний МК, передающий команды модулю и принимающий и декодирующий его ответы, и/или изменяющий настройки модуля установкой значений его переменных. В нашем случае в качестве такого устройства я задействовал терминальную программу TeraTerm и вводил команды модулю через клавиатуру компьютера и USB-UART конвертер. Для начала полезно будет ознакомиться какие переменные имеются в настройках модуля и на что они влияют. При подаче команды get al модуль выводит на экран терминала значения всех своих переменных, как показано ниже.

Из них имена, начинающиеся с bl, соответствуют настройкам Bluetooth части. Те, что начинаются с bu соответствуют bus usage, в нашем случае устаовлен режим подачи локальных комманд через UART. Далее идёт перечисление функций, реализованных на каждом из 15 выводов GPIO, и в конце – всякие системные настройки. Подробнее о значениях переменных и их использовании можно прочитать по ссылке [5]. Таким образом, в этих модулях можно лишь изменять значения вышеперечисленных переменных и нет возможности сохранить в модуле иных данных пользователя.

Как я уже упоминал, помимо значений переменных в модуль можно посылать и команды. Список команд и их синтаксис доступен по ссылке [6]. В частности, для мигания светодиодом через UART интерфейс следует проделать следующее:

1. Настроить вывод порта, подключённый к светодиоду (GPIO9 в нашем случае), на работу в режиме stdio подачей команды gfu 9 stdio
2. Подать команду gdi 9 ohi для зажигания светодиода.
3. Подать команду gdi 9 olo для его гашения.

На терминале это выглядит следующим образом:

Как видно, модуль подтверждает выполнение каждой команды (эту опцию можно отключить). Можете поверить мне на слово, что светодиод при этом действительно мигает. Для последующего мигания первую команду можно не подавать, т.к. вывод порта уже настроен. Можно сохранить эту настройку в памяти модуля подачей команды save. При этом после следующего сброса модуля его порт GPIO9 уже будет автоматически настроен на режим stdio.

Для выдачи на терминал значения температуры следует посылать в модуль команды, имеющие также смысл и для датчика температуры. В случае TMP112 для этого следует:

1. Настроить датчик на производство единичного измерения с последующим уходом в сон. Для этого в его регистр с адресом 01 нужно загрузить код 0хЕ1. При заземлении вывода 4 датчика его I2C адрес, согласно ДШ, будет 72 (0x48). Посылаем в модуль команду i2cwr 72 hex 01 e1. На логическом анализаторе процесс коммуникации с датчиком выглядит так:

Как видно из графика, драйвер I2C автоматически формирует сигнал переключения для IC2 на выводе GPOI8 (нижняя осциллограмма). Лучше-бы он это делал когда уровень на выводах SDA/SCL установится в лог. 1. Кроме того, несмотря на установку частоты тактирования линии I2C в 100 кгц (i2 b s: 100), она тактируется на 384 кгц. Мммммда... Хорошо, что наш сенсор работает на частоте тактирования до 400 кгц.

2. Настроить датчик на чтение значения температуры из его регистра номер 0 посылкой в модуль команды i2cwr 72 hex 0 с очевидным синтаксисом.

3. Произвести чтение двух байтов значения температуры подачей в модуль команды i2crd 72 hex 2. На терминале при этом показываются прочитанные данные, которые, как следует из осциллограммы ниже, соответствуют реальности. Из них 12 – шестнадцатиричное значение целой части температуры (0х12 = 18°C), a 50 – дробной (0х50 = 5/16). Ноль в конце дробной части в значение температуры не входит, т.к. сенсор имеет только 12-битное разрешение.

Работа с модулем через Bluetooth интерфейс

Проделаем теперь тоже самое в режиме подачи команд модулю через его безпроводный интерфейс. Для передачи комманд сначала воспользуемся донглом CY5677 фирмы Cypress и их системой CySmart. У фирмы также имеется версия этой системы для смартфонов, поддерживающих Bluetooth 4.1. В этом случае донгл не нужен, но на компьютере мне удобнее.

После запуска системы и окончания сканирования Bluetooth устройств, увидим наш модуль в списке под именем AMS-693F. Последние 4 символа в дефолтном имени модуля (имя можно изменить) соответствуют последним двум байтам его индивидуального Bluetooth адреса (подчёркнуто красным). Дефолтное состояние модуля после включения соответствует режиму передачи извещений (Advertising) при выходной мощности +4dBm.

Интересно сразу оценить токопотребление модуля в таком режиме. Для этого я временно отключил от модуля всю остальную часть схемы и измерил токопотребление инструментом Atmel Power Debugger, работающем вкупе с приложением Data Visualizer. Для уменьшения токопотребления в перерывах между посылкой извещений я предварительно сконфигурировал модуль на работу в режиме low power advertising установкой значения 10 в переменную sy a t. Модуль перейдёт в указанный режим через 10 секунд после ресета. Как следует из графика ниже, максимальное токопотребление модуля составило около 13мА при посылке извещений с периодом около 0.6 сек. Помимо основных пиков на осциллограмме также видны вторичные пики токопотребления, следующие с периодом 1 сек. Думаю, это связано с обработкой неких событий ОС по таймеру.

Растянув основной пик по оси Х, отчётливо увидим 3 скачка токопотребления при отсылке извещений (advertisements) на 3-х каналах в соответствии с протоколом. Отсылка их занимает около 4 мс и ещё примерно 3 мс модулю требуется на разгон своих тактовых генераторов и подготовку пробуждения из сна. В период пробуждения его среднее токопотребление оказалось около 240 мкА.

Модуль выдерживает заявленные в ДШ параметры по максимальному токопотреблению. Это, в общем, относится и к паузам между посылкой извещений, как видно из следующего графика. Следует отметить, однако, что данный модуль не является рекордным по экономичности среди Bluetooth модулей разных производителей.

Но вернёмся к цели нашего приложения и системе CySmart. Выбираем модуль в списке обнаруженных Bluetooth устройств и устанавливаем соединение с ним. Модуль сразу запрашивает изменение периода соединений с донглом в соответствии с его настройками. Если согласимся, CySmart автоматически перестроит донгл на такой период. Если откажемся, то модуль установит свой период в соответствии с таковым у донгла. В следующем окне системы нажимаем на Discover all attributes и получаем список сервисов, предлагаемых модулем. Из них нас интересует только сервис показанный ниже. Его дефолтное UUID оговорено в ДШ и может быть изменено при необходимости. В сервис включены 3 характеристики, расположенные по адресам 0х0042, 0х0045, 0х0048. Производим чтение их значений, кликнув мышкой на Read All Characteristics. Согласно документации [4], первая характеристика служит для передачи данных/команд модулю. Вторая – для приёма данных из модуля. И третья – для изменения режима работы модуля. Напомню, что имеется всего 3 режима (local, stream, remote) и мы собираемся работать с последним. Однако, дефолтный режим работы после установки соединения с модулем – это режим потоковой передачи данных (stream mode – подчёркнуто красным; дефолтное значие можно изменить). Для передачи команд модулю через Bluetooth следует перейти в режим remote, записав в характеристику по адресу 0х0049 значение 03. В окне терминала при этом модуль сигнализирует переход из режима STREAM_MODE в REMOTE_MODE. Теперь всё готово для подачи в модуль команд.

Каждая команда должна состоять не более чем из 20 байтов (для более длинных команд их следует передавать в несколько этапов) и заканчиваться символами конца строки “rn” (ASCII коды 0х0D и 0х0A). Это необходимо интерпретатору команд ZentriOS-S для определения конца команды. Для зажигания светодиода записываем в характеристику по адресу 0х0043 строку “gdi 9 ohirn” (в байтах это 67:64:69:20:39:20:6F:68:69:0D:0A), как и выше, а для гашения - “gdi 9 olorn” (67:64:69:20:39:20:6F:6C:6F:0D:0A).

Для дистанционного чтения температуры, в модуль следует подать теже самые команды, что и в случае проводного интерфейса выше, явно дополнив каждую из них символами “rn”. Команды также следует записывать в характеристику по адресу 0х0043. Однако, имеется и небольшое отличие. Во-первых, в CySmart следует разрешить приём всех нотификаций модуля. Это достигается кликанием мышкой на Enable All Notifications, или просто записью значения 03:00 в CCCD дескриптор по адресу 0х0047. И во-вторых, следует разрешить модулю передачу хедеров, предшествующих данным, засылкой в него команды установки соответствующей переменной “set sy c h” (73:65:74:20:73:79:20:63:20:68:20:31:0D:0A). Её, как и всякую иную переменную можно сохранить в модуле и не передавать впоследствии. Без всего этого прочитать значение температуры не удастся. По подаче команды чтения регистра температуры сенсора “i2crd 72 hex 2rn” (69:32:63:72:64:20:37:32:20:68:65:78:20:32:0D:0A), прочитанное из датчика значение передастся донглу как нотификация (для этого мы их и разрешали) и будет доступно через характеристику по адресу 0х0046 (подчёркнуто красным). В результате чтения получим следующую картину:

Как видно, принятые данные соответствуют трём текстовым строкам, разделённых символами “rn” (0D:0A). Первая строка (байты 30:30:36 в шестнадцатиричной системе) - это ASCII коды строки “006”. В этом хедере показывается сколько информационных байтов данных принято во второй строке, включая символы “rn” в её конце. В нашем случае информационные байты (31:32:41:30), соответствуют ASCII кодам строки “12A0”, примерно той-же, что мы видели в окне терминала выше. Принятая строка в свою очередь подразделяется на целую часть температуры (0x12 = 18°C) и её дробную часть (0xA0 = 10/16). На третью принятую строку (3E:20) можно не обращать внимание. Она состоит из символов готовности интерпретатора команд, отображаемых в окне терминала как “> ” (с пробелом на конце). Отмечу, что модуль передаёт статус выполнения всех команд как нотификации, декодировав которые в соответствии с форматом [4], можно судить об успехе выполнения поданных команд.

Для работы с модулем без системы CySmart и донгла была собрана следующая тестовая схема на основе Bluetooth 4.1 модуля IC1 фирмы Cypress:

После подачи питания на схему программа загруженная в IC1 производит установку соединения с модулем AMS001, перевод его в режим remote, и разрешение на посылку им нотификаций как указано выше. При этом светодиод на схеме сначала мигает с периодом 0.5 сек во время сканирования Bluetooth устройств модулем, и по завершении соединения горит постоянно. Для упрощения реализации соединения в программу занесён Bluetooth адрес модуля AMS001. Далее ожидается нажатиe на кнопку, по совершении которого в модуль AMS001 засылается запрос на измерение температуры датчиком TMP112 с последующей передачей её на IC1. Принятая схемой температура показывается на ЖКИ. Последующие нажатия на кнопку приводят к включению и выключению светодиода на схеме AMS001. ЖКИ работает в режиме мультиплекса 1:3, модули семейства CYBLE оснащены аппаратным ЖКИ драйвером. Программа разработана в системе PSoC Creator, исходный текст программы прилагается. Для программирования и отладки использовался штатный программатор MiniProg3. Подробнее о работе с Bluetooth модулями фирмы Cypress можно прочитать в моих статьях [8, 9]. Обе схемы собраны на беспаячных монтажках.

Работу модулей можно проследить с помощью донгла NFR51-DONGLE фирмы Nordic Semiconductor с загруженным в него приложением сниффера протокола Bluetooth LE. Для этого также понадобятся приложение ble-sniffer фирмы и система Wireshark с соответствующим плагином для Bluetooth. О всём этом см. подробнее в [9]. Как следует из нижеприведённого лога, модуль AMS001 (Slave) находился в режиме передачи извещений (строки с номерами 6 – 9) до соединения с модулем CYBLE (строка 10). Далее произошло согласование периода соединений между модулями (строки 33 – 36), перевод модуля AMS001 в режим remote (строки 38 – 41), засылка запроса на измерение температуры (строки 42 – 45), запрос на её чтение (строки 48 – 51), разрешение посылки нотификаций (строки 52 – 55), и далее чтение температуры и моргание светодиодом по нажатии на кнопку. Заметим, что после разрешения отсылки нотификаций модуль AMS001 отсылает в них статус исполнения в ответ на посылку в него каждой команды. Т.о. модуль работает в соответствии с ожиданием. Отмечу, что пустые строки удалены из лога фильтром Wireshark.

Реализация беспроводного UART

В заключении отмечу применение модулей для популярного приложения беспроводного UART. Интересно, что для этого не нужно вообще ничего программировать, поскольку данное приложение готово к использованию прямо “из коробки” (см. подробнее [10]). Для этого, естественно, понядобятся 2 модуля. Модули не должны быть одинаковыми. В моём эксперименте один из них AMS001 (нижний, где использована та-же монтажка, что и ранеее), а другой – AMS002. Оба модуля подключены к компьютеру через USB-UART мосты на основе CP2104.

В нижний модуль загружен тот-же программный продукт, что и ранее (Zentri-I2CM). По подаче питания на модуль он работает в роли Peripheral, начинает посылки извещений о своём существовании, и ожидает соединения с ним. Для того, чтобы второй модуль смог послать запрос на соединение с первым, он должен работать в роли Central. Для этого в него следует загрузить программный продукт Zentri-DUAL. Подключаем оба модуля в USB порты одного или разных компьютеров и открываем Tera-Term приложения для каждого из них. По умолчанию оба модуля работают в режиме подачи локальных команд. Для проверки правильности установки надлежащих программных продуктов я подал в них команды ver. Как видно из лога сессии, программные продукты в первом модуле (слева) и во втором (справа) такие, как должны быть.

Для сканирования вторым модулем Bluetooth устройств в него следует подать команду scan high. Через пару секунд в окне терминала покажется список обнаруженных устройств, среди которых окажется и первый модуль. В нашем случае список состоит только из нашего модуля, где он указан под номером 1. Для инициализации соединения с модулем под этим номером в списке, в окне второго подаём команду con 1. При этом соединение установится и оба модуля автоматически перейдут в режим потоковой передачи данных stream. Теперь текст, печатаемый в окне первого модуля, передастся через Bluetooth второму и отобразится в его окне. И наоборот. Соединение и, следовательно, обмен данными модулей происходит с дефолтным периодом 7.5 мс.

Неколько замечаний. Во-первых, для надёжной работы мостов и UART интерфейсов модулей на высоких скоростях следует использовать 4-проводный UART с задействованием сигналов RTS и CTS. Таковой уже реализован в модулях (и USB мостах), я его не использовал исключительно в целях простоты. Если передавать данные со скоростью печатания на клавиатуре человеком, достаточно и 2-проводного UART. Во вторых, внимательный читатель может заметить, что в нашем эксперименте инициализация соединения может быть совершена только вторым модулем. Для исключения этого недостатка следует загрузить программный продукт Zentri-DUAL в оба модуля. При мощности передачи +4dBm радиус надёжной связи между модулями получается около 40-50м и зависит от окружающих модули предметов и ориентации их антенн.

Литература

1. Zentri Products
2. Zentri Update and Recovery
3. Zentri DMS
4. Serial Bus Modes
5. ZentriOS Variable Reference
6. ZentriOS Command Reference
7. Power Management
8. Bluetooth Smart Broadcaster на RSoC фирмы Cypress
9. Реалиазция стандартного GATT-BLE профиля на RSoC фирмы Cypress
10. Getting Started with ZentriOS BLE

Файлы:
Cypress firmware

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

Эти статьи вам тоже могут пригодиться:

О работе с BLE модулем BGM111 фирмы Silicon Labs

Прием и передача данных по bluetooth (HC-05)

Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть III.

Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть I.

Bluetooth по-китайски: теория и практика

Радиоуправление моделью через Bluetooth LE

Универсальный генератор с Bluetooth из готовых модулей

Разработка Bluetooth приложений на модулях фирмы Silicon Labs. Часть 2.

О работе с Bluetooth модулями семейства BL65х фирмы Laird