О работе с WiFi модулем AMW037

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

Модуль этот разработан фирмой Zentri, которая сейчас входит в состав Silicon Labs. Недавно я рассказывал здесь про приложения на базе Bluetooth модулей фирмы [1]. Помимо этих модулей фирмой выпускается линейка WiFi модулей [4], сравнительные характеристики которых приведены в [5]. В статье будет показана работа с одним из самых недорогих WiFi модулей с интегрированной печатной антенной AMW037 [3].

Помимо радиотракта с соответствующей обвязкой модуль содержит на борту флеш-память для ПО объёмом 2М, которая также может быть использована для организации проприетарной файловой системы. Модуль может быть использован только в режиме NCP (Network Co-Processor) и коммуникация с его встроенной ОС производится через UART интерфейс и специальные комманды. Комманды служат для конфигурирования модуля и выполнения различных функций, о некоторых из которых рассказано ниже. Параметры конфигурации могут быть сохранены во внутренней энергонезависимой памяти. Модуль готов к использованию прямо из коробки, но следует проверить и если нужно обновить его ПО. Для ознакомительной работы с модулем через терминальную программу компьютера была собрана следующая схема.

При подключении к компьютеру на дефолтной скорости 115200 модуль рапортует о готовности и выводит приглашение к приёму команд. При подаче команды ver он показывает загруженную в него версию ОС.

В моём случае изначально это была более старая версия, чем указано выше и в документации [6], так что апгрейд был необходим. Это можно сделать разными способами, например путём предварительной установки имени точки доступа (AP) в вашей сети и пароля командами

set wlan.ssid YOUR_AP_NAME
set wlan.passkey YOUR_AP_PASSWORD
save

с последующим соединением с ней командой nup (network up):

Для апгрейда ПО следует сначала получить аккаунт на сайте DMS (Device Management System) фирмы [2] и использовать его для регистрации модуля в системе командой

dms claim YOUR_DMS_USERNAME YOUR_DMS_PASSWORD

Теперь можно произвести апгрейд командой ota. При этом модуль соединится с сервером DMS и загрузит с него последнюю версию необходимого ему ПО.

Однако, в моём случае не обошлось без проблем, так что пришлось обратиться к тех. поддержке. Модуль никак не хотел соединяться с моей домашней WiFi сетью. Оказалось, что он был куплен достаточно давно прежде чем у меня дошли до него руки, так что сейчас необходимо было подать в него команду

set setup.gpio.control_gpio -1

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

Если соединение с AP и апгрейд ПО прошли успешно, подадим в модуль команду

set wl o e true

для автоматического соединения с АР по подаче питания или сбросу. Теперь всё, наконец, готово для работы с модулем. Для этого вышеприведённая схема была дополнена микроконтроллером и дисплеем.

Модуль подключается к шинам RX и TX схемы через выводы 10 и 11, соответственно. Используемый дисплей способен отобразить до 4-х символьных строк по 10 символов в каждой и поддерживает интерфейсы I2C и SPI. В данном случае используется интерфейс I2C на частоте тактирования близкой к 400 кгц. Путём подачи соответствующих команд дисплей может быть переконфигурирован на отображение трёх строк (при этом шрифт одной из них будет в 2 раза выше остальных) или двух строк большими шрифтами. Для контроля интерфейса с модулем в МК задействованы 2 аппаратных USART модуля. Один из них (USART1) служит для связи с модулем, а другой (USART0) – для связи с терминальной программой компьютера. При этом ответы модуля на посылаемые в него команды по USART1 отображаются на терминале. Команды, подаваемые с терминала через USART0, дублируются модулю на USART1.

NTP Client

В этом приложении модуль используется для соединения с NTP сервером и показа текущего времени суток и даты на дисплее. Примечательно, что NTP client уже интегрирован в состав ZentriOS-WL и с дефолтными настройками системы автоматически посылает запрос на NTP сервер времени по получении модулем IP адреса от AP и сохраняет его ответ в системных переменных часов реального времени RTC. Более того, RTC тактируется от внутреннего кристалла модуля и каждый час автоматически синхронизируется с NTP сервером (период синхронизации можно изменить). Помимо этого, модуль конвертирует полученное значение счётчика секунд сервера в читабельный формат даты и времени. Таким образом, текущие время и дата доступны в любой момент из RTC путём подачи следующей команды, где во второй строке показан пример ответа модуля

get ti r utc
2018-07-22T11:13:22-05:00

Дата показывается в формате yyyy-mm-dd, а время - в формате hh:mm:ss. Последнее поле “-05:00“ в данном случае – это раница между локальным временем и UTC. Эту разницу следует предварительно записать в модуль командой

set ti z -5

и тогда она будет автоматически добавляться к ответу NTP сервера. Вот и вся «теория». Остаётся подать все эти команды в модуль внешним МК и отобразить время на дисплее. К сожалению, модуль не предостявляет возможности для определения дня недели. Для этого в программу МК введена функция computeDayOfWeek(), вычисляющая день недели по дате, согласно алгоритму Zeller’s Congruence. Полный исходный код проекта находится в папке NTP в прилагаемом архиве.

Для автоматического отображения времени и даты по подаче питания на схему без участия терминальной программы следует подождать получения IP адреса модулем от WiFi AP прежде чем посылать в него запросы о времени. Для этого после конфигурации ресурсов МК в начале программы в модуль периодически подаётся команда чтения статуса соединения с AP

get wl n s

Возвращаемое ей значение равно 0 до установки соединения с AP, 1 в случае успешного соединения, и 2 после получения IP адреса от DHCP сервера AP. Прилагаемый код ждёт значения статуса, равного 2. Вот как выглядит диалог с модулем на терминале компьютера по подаче питания на схему. Терминал используется исключительно для отображения диалога модуля с МК.

После получения модулем IP адреса в него подаётся команда подавления эха

set sy c e 0

При этом принимаемые команды не дублируются модулем в ответе на них. Это несколько упрощает микроконтроллеру анализ коммуникации с модулем.

HTTP Server

Базовое приложение сервера также интегрировано в состав ZentriOS-WL. Однако, всвязи с ограниченными ресурсами модуля, он не производит синтаксический анализ передаваемых в него запросов. Для этого можно использовать, например, модуль AMW106, который оснащён более мощной ОС, в частности, позволяющей загрузить в него приложение пользователя. Тем не менее, я приведу пару примеров организации HTTP сервера на нашем модуле и обработку простых запросов клиента.

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

set ht s e 1
nre

При этом произойдёт установка переменной http.server.enabled, которую можно сохранить командой save, так что при последующем сбросе питания сервер будет стартовать автоматически.

Далее следует записать в флеш-память модуля требуемые веб-страницы. Это можно сделать несколькими способами, но самый простой, пожалуй - это загрузить их с какого-либо существующего HTTP сервера, предварительно поместив их туда. Для этого можно, например, воспользоваться свободно скачиваемым из Интернета Windows-приложением MiniWeb HTTP Server. Не забудьте при этом настроить свою Firewall, чтобы она не блокировала соединение с сервером. Помещаем файлы, предназначенные для загрузки в модуль в папку htdocs инсталляции приложения. В моем случае папка эта находится по адресу C:SiliconLabsminiwebhtdocs. Заметим, что MiniWeb сервер дефолтно слушает запросы на порт 8000.

Я записал в папку htdocs файлы test.html и css.css. Первый из них содержит H1 заголовок и название страницы (title), а второй – CSS цветовую раскраску для заголовка и фона страницы. Для загрузки их в модуль подаём команду

http_download http://192.168.1.126:8000/test.html test.html

и также для каждого из остальных файлов. При этом второй параметр команды – это имя загруженного файла в файловой системе модуля. В данном случае производится загрузка файлов в корневую директорию файловой системы. Теперь можно подать команду ls для просмотра списка файлов модуля.

Как следует из списка, наши файлы успешно загрузились в модуль и помимо них в нём имеется несколько других файлов, пришедших с установкой ПО. Один из них (webapp/index.html) содержит графическое приложение настроек параметров модуля (см. подробнее в [7]). Заметим, что файловая система содержит файл дефолтной иконки сервера (favicon.ico.gz), показываемой браузерами в титульной строке. Для отображения нашей веб-страницы введём её адрес в окошко браузера. Как видно ниже, наш сервер работает замечательно, предоставив Google Chrome браузеру оба загруженных файла.

Отмечу, что серверу можно придать «человеческое» имя вместо IP адреса, посадить его на статический IP адрес и произвольный порт, определить корневую директорию для веб-приложений, и ещё многое другое. См. подробности в документации [6].

Обратимся теперь к организации формирования сервером на лету ответов на запросы клиентов. Именно, нашей целью будет создание приложения, которое по запросу клиента измеряет температуру и влажность воздуха и возвращает эти данные клиенту как веб-страницу в формате протокола HTTP. Как я упоминал, AMW037 не может сделать это всё сам, так что потребуется помощь внешнего МК. Мы воспользуемся той-же самой схемой сервера, что и ранее, только вместо ЖКИ на I2C шину поставим сенсор HDC1080.

Модуль AMW037 оснащён приложением TCP сервера, на основе которого мы и спроектируем наш HTTP сервер. Прежде всего потребуется активизировать его (установкой переменной tcp.server.auto_start) и сконфигурировать на работу со стандартным HTTP портом 80 вместо дефолтного 3000 (переменная tcp.server.port). Как и в первом приложении, мы получим IP адрес сервера от нашей AP, хотя возможна и работа модуля в режиме AP с организацией своей приватной сети с DHCP сервером. Чтобы узнать о соединении с клиентом установим переменную tcp.server.connected_gpio (это произойдёт после троекратного рукопожатия SYN/SYNACK/ACK), а для распознавания посылки запроса клиентом используем переменную tcp.server.data_gpio. Значения этих переменных соответствуют выводам порта, устанавливаемых модулем в 1 по наступлении соответствующего события. Для этих целей я использую выводы GPIO4 и GPIO5 модуля, соединив их, соответственно с выводами PE13 и PE12 МК на монтажке. После перезагрузки модуля TCP сервер готов к работе.

Теперь открываем браузер и вводим в него адрес сервера и страницы http://192.168.1.134/th.html для чтения температуры и влажности. Файл th.html не существует в файловой системе нашего сервера, однако, этот запрос передастся серверу. При этом на выводах GPIO4 и GPIO5 модуля установится уровень лог. 1, который мы отслеживаем установкой прерывания по фронту сигнала на выводе МК. ОС сервера открывает сокет по принятому запросу, и его номер, а также статус всех остальных открытых сокетов, можно прочитать командой list. В нашем случае, как следует из скриншота ниже, открыт сокет 0, из которого можно читать принятый от клиента запрос и в который можно записать данные для отсылки клиенту. Для чтения запроса клиента посылаем в модуль команду read 0 100, где 0 – номер сокета, а 100 – максимальное число читаемых байтов. В результате получим первые 2 полные строки GET запроса файла th.html (и частично третью).

В качестве эксперимента мы просто посылаем в сокет 0 строку “21 68” длины 5 с данными температуры и влажности, соответственно (в реальном приложении будет отсылать полноценный HTML ответ). Очень важно отметить, что эти данные отобразятся в окне браузера только по закрытии канала, что осуществляется командой close 0. При этом логический уровень на выводах GPIO4 и GPIO5 модуля падает до 0, и он готов для обработки нового запроса.

В прилагаемой программе МК (см. папку HTTPServer в архиве) первая строка запроса клиента анализируется на совпадение со строкой “GET /th.html ”, и если это произойдёт, то производится измерение температуры и влажности, далее формирование HTTP ответа клиенту с кодом “200 OK” и запись его в сокет. При обращении к любой другой “странице” нашего сервера он отвечает кодом “404 Not Found”, что также реализовано программно.

Работу сервера можно проанализировать системой Wireshark.Ниже показан диалог модуля и компьютера при обработке запроса, из которого следует, что сервер работает в полном соответствии с ожидаемым.

HTTP Client

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

tcpc api.thingspeak.com 80

где первый параметер это имя сервера, а второй – номер порта на сервере. Эти параметры можно записать в переменные модуля и впоследствии опустить при вызове команды tcpc. Так мы и поступим:

set tcp.client.remote_host api.thingspeak.com
set tcp.client.remote_port 80
save

Команда tcpc возвращает значение, и если оно равно '0', то соединение с сервером произошло успешно. Отметим, что модуль прозрачно для пользователя посылает DNS запрос для определения IP адреса сервера. Далее следует подать уже знакомую нам команду list, чтобы узнать номер открытого сокета для связи с сервером. Следующим шагом читаем данные из сенсора, формируем HTTP GET запрос и посылаем его в сокет. При этом предполагается, что аккаунт на сервере ThingSpeak создан заранее и тамошняя система предоставила api_key канала. Подробнее об этом можно прочитать в моей статье здесь [7] или в [8].

Из приведённого выше скриншота вытекает, что передача данных на облако произошло успешно. Напомню, что очень важно после передачи закрыть сокет командой close, т.к. автоматически модуль этого не делает. Полный код проекта представлен в папке HTTPClient прилагаемого архива. Там-же находится файл AMW037.html, показывающий как соединиться с облаком через браузер и отобразить накопленные там данные. Датчик установлен в жилой комнате и за короткий промежуток времени данные среды в ней не изменились. При касании курсором мышки точки на графике производится открытие окошка с деталями измерения в этой точке, как это показано на графике влажности.

До сих пор наше приложение HTTP клиента производило лишь одностороннюю связь с сервером, посылая в него свои данные. В следующем примере показано как осуществить двустороннюю связь. Именно, мы задействуем 2 модуля. В один из них загрузим приложение HTTP сервера, который по запросу клиента, произведёт измерение температуры и влажности и отошлёт их обратно клиенту, выполненного на другом модуле. Клиент принимает эти данные и отображает их на дисплее, как показано ниже. При этом клиент выполнен по такой-же схеме (и на той-же монтажке) как и в случае NTP клиента.

Как и в описанном выше случае случае, мы создадим HTTP клиент на основе встроенного приложения TCP клиента. Для отсылки запроса на сервер и приёма от него данных мы используем всё ту-же команду tcpc с дополнительной опцией -g

tcpc –g 4 192.168.1.142 80

которая настраивает установку высокого уровня на выводе GPIO4 как только будет получем ответ сервера. Далее, как и выше, узнаём номер сокета командой list и читаем данные командой read, выделяем их них значения температуры и влажности и посылаем их на дисплей.

В статье рассмотрены далеко не все возможности модуля. Некоторые другие примеры можно найти в [6]. В частности, там-же в [10] показано как задействовать встроенное в модуль приложение беспроводного последовательного порта, позволяющее довольно просто организовать соединение двух МК (или МК и компьютера) через UART интерфейс.

Литература

1. О работе с Bluetooth модулями AMS001/002 фирмы Zentri
2. Zentri DMS
3. AMW037 WiFi Module
4. ZentriOS Supported Modules
5. ZentriOS Module Comparison
6. ZentriOS-WL General Overview
7. ZentriOS Web App
8. Об использовании облачного сервиса ThingSpeak для логгирования и визуализации данных
9. А. Пахомов: Хранение в ThingSpeak информации о температуре и влажности, Радио 7 (2018), стр. 19-21.
10. Wireless Serial Port

Файлы:
Firmware
Изображение

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