Стеки для организации беспроводной передачи данных на основе устройств STM32W108. Часть 1

Рассматриваются определяемые стандартом IEEE 802.15.4 физический уровень и уровень управления доступом к среде для беспроводных персональных сетей. Поясняется назначение библиотеки SimpleMAC для систем-на-кристалле STM32W108, приводятся функции инициализации, изменения каналов и передачи пакетов.

Для реализации распределенных систем управления и мониторинга автономных устройств в промышленности и сфере домашней автоматики наилучшим образом подходит оборудование беспроводной передачи данных, поддерживающее стандарт IEEE 802.15.4 [1]. Простота технологии, низкая стоимость радиомодулей и их малое энергопотребление позволяют организовывать надежные и недорогие сети с небольшой, но достаточной для передачи рабочей информации скоростью.

Зачастую в таких сетях, представляющих собой связанную по беспроводному каналу совокупность датчиков или исполнительных устройств, конечная точка должна представлять собой систему, включающую в себя приемопередатчик и микроконтроллер с периферией для работы с подключаемым устройством. Поскольку использование отдельных радиомодулей и контроллеров на одной плате увеличивает сложность оборудования, его стоимость и габариты, производители электронных компонентов выпускают системы-на-кристалле (СнК), экономящие время и стоимость разработки. Одну из удачных линеек таких СнК предлагает компания STmicroelectronics. В ее устройствах STM32W108 [2] сочетаются 32-разрядный микроконтроллер с ядром Cortex-M3 и приемопередатчик, поддерживающий стандарт IEEE 802.15.4. При этом стоимость одной такой СнК в среднем составляет 150 рублей. Кроме того, компания предоставляет программные стеки SimpleMAC и ZigBee RF4CE, которые существенно упрощают организацию сетей на основе этих СнК. О таких стеках пойдет речь в данном материале.

Вначале следует рассмотреть библиотеку SimpleMAC [3], позволяющую на основе уровня управления доступом к среде (MAC) стандарта IEEE 802.15.4 осуществлять обмен данными в сети беспроводной связи. До этого стоит уделить немного внимания физическому уровню (PHY) и MAC-уровню, чтобы лучше понимать принцип работы функций библиотеки.

Физический уровень

На физическом уровне ведется работа непосредственно с самим приемопередатчиком: производится его включение и отключение, определяется качество беспроводного соединения, выбирается частота каналов и осуществляются прием и передача пакетов данных. Стандарт IEEE 802.15.4 определяет два уровня PHY, работающих на разных частотах: 868/915 МГц и 2.4 ГГц. Первый применяется в Европе (частотный диапазон 868 – 868.6 МГц) и Северной Америке (902–928 МГц), а второй (2400–2483.5 МГц) применяется во всем мире. Помимо различия в частотах, они также отличаются количеством каналов и скоростью передачи данных. Подуровень 868 МГц предполагает только один канал со скоростью передачи 20 Кб/с, подуровень 915 МГц – 10 каналов со скоростью 40 Кб/с, а уровень 2.4 ГГц – 16 каналов со скоростью 250 Кб/с.

Кроме того, к задачам физического уровня относится оценка незанятости канала (CCA или Clear Сhannel Assessment) для функционирования алгоритма доступа к каналу с исключением столкновений (CSMA-CA или Carrier Sense Multiple Access with Collision Avoidance).

Информация в сети передается кадрами. Общая структура такого кадра представлена на Рисунке 1. Префиксный заголовок (SHR) состоит из преамбулы, которая выражается 32 нулями, и стартового разграничителя кадра (SFD), обозначающего конец преамбулы синхронизации и начало пакета данных. SFD должен иметь значение 10100111 в двоичном коде. После этого идет заголовок физического уровня, содержащий 7 бит длины кадра. Затем передается блок сервисных данных (PSDU), который представляет собой MAC-уровень.

Рисунок 1. Структура кадра физического уровня.

Уровень управления доступом к среде

MAC-уровень обеспечивает адресацию и механизмы управления доступом к каналам, благодаря чему устройства могут общаться между собой в многоточечной сети. Стандарт IEEE 802.15.4 позволяет узлам сети взаимодействовать как напрямую друг с другом (топология peer-to-peer), так и образовывать структуры типа «звезда». Причем, с помощью этих двух структур можно организовывать сети с комбинированной кластерной топологией. Для маршрутизации информационных потоков в рамках топологических схем служит координатор персональной сети (PAN или Personal Area Network). В структуре типа «звезда» координатором PAN становится устройство с полной функциональностью, с которым связаны устройства с ограниченной функциональностью. При организации коммуникации peer-to-peer одно из устройств также должно стать координатором PAN. Как правило, оно является первым подключившимся к каналу. Далее сеть может строиться по принципу «точка-точка» или «дерево».

Каждый узел должен иметь уникальный 64-разрядный адрес, который может использоваться для прямых коммуникаций в пределах персональной сети. Также координатор PAN может использовать сокращенные 16-разрядные адреса для групповой адресации сетевых устройств.

Стандарт IEEE 802.15.4 на MAC-уровне предполагает два типа передачи данных: с использованием кадров-маяков и без них. В первом случае, если узел хочет передать данные координатору (Рисунок 2а), вначале он должен выполнить поиск маяка для того, чтобы синхронизироваться со структурой суперкадра. После этого устройство в соответствующий момент времени может передать пакет данных. При необходимости координатор может отправить этому устройству кадр подтверждения пакета данных. Если же нужно осуществить передачу данных от координатора к узлу сети (Рисунок 2б), то этот узел будет «прослушивать» маяки, и при обнаружении информации об ожидающем отправки сообщении он передаст команду запроса данных. Затем координатор перешлет узлу подтверждение получения запроса данных, после чего отправит и сами данные, при получении которых устройство должно будет послать координатору подтверждение их получения. В случае коммуникации без использования маяков при передаче данных узлом координатору (Рисунок 2в) посылается пакет данных в соответствии с бездоменной схемой CSMA-CA. Координатор может подтвердить получение этого пакета. Если данные должен передать координатор (Рисунок 2г), то узел прежде отправляет MAC-команду запроса данных, также в соответствии с бездоменным механизмом CSMA-CA, после чего координатор передаст подтверждение получения запроса, а затем и кадр данных, после получения которого устройство отправит подтверждение приема информации.

Рисунок 2. Модели передачи данных.

Общий формат кадра MAC-уровня изображен на Рисунке 3. Он состоит из заголовка (MHR), поля данных и завершающего поля (MFR) с контрольной суммой кадра (FCS). В свою очередь, заголовок содержит поле управления (FCF), порядковый номер и адресные поля, к которым относятся PAN-идентификатор точки назначения, адрес точки назначения, PAN-идентификатор отправителя и адрес отправителя.

Рисунок 3. Общий формат кадра MAC-уровня.

Поле управления состоит из 15 бит, его структура показана на Рисунке 4. Тип кадра, описываемый тремя битами, может принимать следующие значения: маяк (000), данные (001), подтверждение (010), МАС-команда (011). Коды 100-111 зарезервированы. При установленном бите безопасности предполагается, что кадр защищен на MAC-уровне. Бит задержки кадра принимает значение 1, если узел, посылающий кадр, имеет дополнительные данные для получателя. Бит запроса подтверждения определяет необходимость подтверждения в случае приема получателем данных или MAC-команды. При установленном бите оно будет отправлено. В случае установленного бита Intra-PAN пакет будет передан внутри сети, иначе он будет передан в другую сеть. Режим адресации точки назначения может быть представлен следующими значениями: идентификатор PAN и адресные поля отсутствуют (00), зарезервировано (01), адресное поле содержит 16-битный короткий адрес (10), адресное поле содержит 64-битный расширенный адрес (11). Те же значения может принимать режим адресации отправителя.

Рисунок 4. Формат поля управления.

Библиотека SimpleMAC

Библиотека SimpleMAC охватывает функции уровней PHY и MAC. К первым можно отнести, например, выбор радиоканала, управление мощностью передачи, выбор альтернативного пути передачи, управление режимом сна и пробуждением передатчика, индикацию качества канала. Ко вторым – автоматический прием и верификацию подтверждений, передачу с поддержкой CSMA-CA, организацию периодов отсрочки, прием пакетов с проверкой контрольной суммы, установку адреса узла и идентификатора сети, а также прочие функции, характерные для MAC-уровня.

Библиотеку условно можно разделить на несколько классов функций интерфейса программирования приложения (API):

  • функции инициализации и пробуждения;
  • функции для работы с каналами;
  • функции передачи пакетов;
  • функции приема пакетов;
  • криптографические функции, которые обеспечивают интерфейс с аппаратным AES-сопроцессором;
  • функции для работы с MAC-таймером;
  • прочие функции для диагностики и конфигурации.

В рамках библиотеки SimpleMAC приняты определенные правила в наименовании функций API. Все функции библиотеки SimpleMAC начинаются с префикса «ST_», за которым следует основное наименование семейства API (например, Radio или AES). Функции, которые применяются в приложении и вызываются из библиотеки SimpleMAC, заканчиваются словом «Callback». В свою очередь, функции, применяемые в приложении и вызываемые из библиотеки SimpleMAC во время прерывания, имеют окончание «IsrCallback».

Далее рассмотрим основные функции, необходимые для надежной работы беспроводной сети.

Функции инициализации и пробуждения

Для инициализации радиомодуля и его единовременной калибровки используется функция ST_RadioInit(RadioPowerMode initialRadioPowerMode). Она должна быть вызвана после перезагрузки микроконтроллера или его выхода из режима глубокого сна. Функция включит радиомодуль и настроит канал связи. После настройки приемопередатчик останется в состоянии, указанном в параметре initialRadioPowerMode. Этот параметр может принимать два значения: ST_RADIO_POWER_MODE_OFF (радиомодуль будет отключен) и ST_RADIO_POWER_MODE_RX_ON (радиомодуль будет включен). Необходимо помнить, что все остальные функции библиотеки SimpleMAC не следует вызывать, пока не будет произведена инициализация с помощью ST_RadioInit.

Для ввода приемопередатчика в режим сна и вывода из него служат функции ST_RadioSleep() и ST_RadioWake(). Первая функция, по сути, выключает радиомодуль, при этом все выполняемые операции по приему или передаче пакетов прекращаются. ST_RadioWake вновь вводит приемопередатчик в работу, и в данном случае используются все настройки, которые были установлены ранее. ST_RadioWake должна быть вызвана не раньше, чем за 250 мкс после вызова ST_RadioSleep.

Функции для работы с каналами

Для установки канала, на котором будет работать модуль, служит функция ST_RadioSetChannel(int8u channel). Параметр channel указывает канал в рамках стандарта 802.15.4. Если ST_RadioSetChannel вызывается до ST_RadioInit, то указанный номер канала будет установлен, но настройка произведена не будет. Если приемопередатчик находится в режиме сна, то эта функция разбудит его, чтобы выполнить калибровку канала, а затем снова переведет в сон. Весь процесс настройки одного канала может занять до 200 мс. Результаты таких настроек могут сохраняться во флеш-памяти для использования в следующий раз, когда будет выбран тот же канал. Поэтому при повторном вызове ST_RadioSetChannel с тем же номером канала калибровка может занять меньший промежуток времени.

Для того, чтобы узнать номер канала, который использует радиомодуль, следует воспользоваться функцией ST_RadioGetChannel(), возвращаемое значение которой будет являться искомой величиной длиной один байт.

Иногда в процессе работы настройки радиомодуля могут нарушиться вследствие изменения условий окружающей среды, например, температуры. Благодаря функции ST_RadioCheckRadio() можно определить необходимость дополнительной калибровки. Она возвращает два значения: TRUE (если для компенсации нужна калибровка) и FALSE (если калибровка не нужна). Следует учитывать, что эта функция не должна вызываться в процессе передачи пакетов. Если ST_RadioCheckRadio вернула TRUE, то необходимо вызвать функцию ST_RadioCalibrateCurrentChannel(). Она позволит выполнить необходимую перекалибровку для текущего канала.

Похожее:  Direct tv satellite wifi

Функции передачи пакетов

Для того, чтобы передать пакет в эфир, нужно воспользоваться функцией ST_RadioTransmit(int8u *packet). Здесь *packet представляет собой указатель на этот пакет. Передача происходит в соответствии со структурой radioTransmitConfig, которую заранее должен задать программист. Для этого он должен объявить глобальную переменную radioTransmitConfig типа RadioTransmitConfig. Данный тип соответствует структуре, содержащей параметры, определяющие характер передачи. Эти параметры представлены в Таблице 1.

Первый байт пакета должен содержать число байт передаваемой полезной информации. Если параметр radioTransmitConfig.appendCrc имеет значение TRUE, то количество байт в пакете увеличивается на 2, поскольку добавляются еще два байта CRC. Например, пакет с двумя байтами полезной информации будет представлен в памяти в виде <0x04, 0x00, 0x01, 0xc0, 0xc1>, где 0xc0 и 0xc1 – байты CRC. Если параметр radioTransmitConfig.checkCca установлен в TRUE, то функция перед отправкой данных проверит незанятость канала и выставит задержку, в противном случае передача осуществится немедленно.

Если процесс передачи данных был успешно начат, то автоматически после ST_RadioTransmit вызывается функция ST_RadioTransmitCompleteIsrCallback(StStatus status, int32u sfdSentTime, boolean framePending), которая предназначена для индикации завершенности этой передачи. Перед отправкой нового пакета следует проверить параметр status, чтобы решить, какое действие нужно предпринять дальше. Этот параметр может принимать следующие значения:

  • ST_SUCCESS (последний байт пакета, не требующего подтверждения, был передан),
  • ST_PHY_ACK_RECEIVED (запрашиваемое подтверждение получено),
  • ST_MAC_NO_ACK_RECEIVED (запрашиваемое подтверждение не было получено вовремя),
  • ST_PHY_TX_CCA_FAIL (передача невозможна из-за отсутствия свободных каналов),
  • ST_PHY_TX_UNDERFLOW (произошло отрицательное переполнение буфера передачи),
  • ST_PHY_TX_INCOMPLETE (не удалось зафиксировать синтезатор частот с фазовой синхронизацией во время передачи).

Параметр sfdSentTime представляет собой значение MAC-таймера в момент времени, когда был послан стартовый разграничитель кадра. Параметр framePending принимает значение TRUE, если полученное подтверждение сообщает о том, что кадр находится в ожидании. Это очень важная информация, позволяющая уведомить отправителя, что узел назначения ожидает от него данные.

Мощность передачи радиомодуля можно устанавливать программно. Для этого служит функция ST_RadioSetPower(int8s power). Параметр power определяет желаемый уровень мощности в дБм. Можно также узнать текущую мощность передачи с помощью функции ST_RadioGetPower(), которая возвращает значение типа int8s, выраженное в дБм.

Кроме того, библиотека SimpleMAC позволяет определять момент последней синхронизации на основании стартового разграничителя кадра. Данная функция по умолчанию отключена, чтобы активировать её, необходимо вызвать функцию ST_RadioEnableSfdSentNotification(boolean enable), в которой параметр enable приравнять значению TRUE. После этого библиотекой будет вызываться функция прерывания ST_RadioSfdSentIsrCallback(int32u sfdSentTime), где параметр sfdSentTime имеет значение MAC-таймера, определяющее момент последней синхронизации.

В следующей части будет завершено рассмотрение библиотеки SimpleMAC и начат обзор протокола ZigBee RF4CE.

Источник

STM32 — прошивка "по воздуху" через ESP

Подопытная плата Wemos (ESP8266), программироваться будет в IDE Arduino .

Задача такова, нужно соединить STM с ESP, передать на ESP (через интернет) прошивку, далее ESP должна подтянуть BOOT_0 к «плюсу», нажать ресет, и загрузить прошивку в STM через USART_1. Однако прежде надо научится общаться с системным загрузчиком — там не всё так просто как мне думалось по началу, но и сложного ничего нет. Вот мануал на русском языке (обязательно прочтите), описывающий протокол обмена данными между бутлоадером и внешним устройством.

В мануале говориться что максимальная скорость USART’а не должна превышать 115200 (при увеличении растет погрешность). В примере я указал 57600 так как такая скорость используется по умолчанию утилитой stm32flash. Тем не менее плата успешно прошивалась даже на скорости 921600.

Чтобы «договориться» с загрузчиком, нужно послать ему один байт (0x7F), загрузчик принимает этот байт и по нему распознаёт скорость USART’а. Если байт успешно принят (скорость определена), то загрузчик в ответ посылает байт подтверждения 0x79 — ACK-байт . После этого можно посылать загрузчику различные команды. Большая часть команд состоит из двух байт. На все команды, если они успешно выполнены, загрузчик отвечает байтом подтверждения.

Прежде чем браться за ESP, я написал программу для Arduino Mega (и для stm тоже), чтоб потренироваться «разговаривать» с загрузчиком…

Загружаемая прошивка хранится на SD карте.

Serial1 — соединён с USART’ом stm32. Настраивается на работу с битом чётности (SERIAL_8E1).

Serial — смотрим отладочную инфу, и «рулим» ардуиной.

WRITE_ADDR — начальный адрес для загрузки новой прошивки.

SIZE_WRITE — прошивка загружается в stm блоками, максимальный размер блока 256 байт.

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

Файл размером 64Кб, на скорости 57600, прошивается за

Я где-то встречал неподтверждённую инфу, что у некоторых МК максимальный размер блока 128 байт.

FIRMWARE — название файла (прошивки). Программа работает только с bin-файлами .

D5 — реле для управления BOOT_0.


2 — на пин BOOT_0. У платы BluePill это центральный штырёк, на который надет джампер.
3 — на «минус».
1 — на «плюс».

В отключённом состоянии будет тянуть BOOT_0 на «минус», а при включении на «плюс».

D6 — управляет ресетом. Коротит ресет на «минус» через NPN транзистор.


RX и TX нужно подтянуть к «плюсу» резисторами

Подключайте все железки, прошивайте ардуину, открывайте и отправляйте ей команды…

B — активирует загрузчик (подтягивает BOOT_0 к «плюсу»), нажимает ресет, отправляет байт для определения скорости (0x7F) и ожидает ACK-байт. Если ACK-байт пришёл, значит МК готов к приёму команд.

R — деактивирует загрузчик и нажимает ресет.

E — посылает команду очистки всей памяти.

W — загружает прошивку в stm32. Сначала вызывается функция очистки памяти — erase_memory() , и если ACK-байт вернулся, то происходит открытие файла, которое тоже проверяется. Далее в бесконечном цикле отправляется команда на запись, потом начальный адрес для записи первого блока (вместе с контрольной суммой адреса), а потом из файла читается блок, создаётся контрольная сумма блока, и это отправляется в stm. Если файл не закончился, то цикл повторяется. При каждом следующем цикле адрес для записи смещается на длину блока. Так повторяется до тех пор пока файл не закончится. Все действия постоянно проверяются на возврат ACK-байта. Если всё прошло успешно, то загрузчик отключается и нажимается ресет, то есть МК переводится в рабочее состояние.

Чтоб загрузить прошивку, нужно положить её на SD-карту, указать имя в дефайне (имя не должно быть длиннее 8 символов), отправить B, дождаться ответа Bootloader — OK, и отправить W


Обязательно укажите — «Нет конца строки».

Если SD-карты нет, то просто поклацайте релюшкой и ресетом с помощью последних трёх команд, или добавьте в код команды для запуска существующей в МК прогрограммы и вывода ID…

Войдите в режим бутлоадера и пошлите символ g или i.

Если же и ардуины нет, то вот то же самое для stm32. В архиве два примера, один с SD-картой, другой без — просто отправка команд. Общение с целевой платой сделано через USART_1, логи и управление через USB. Карта подключается к SPI2. Весь механизм прописан в файле to_stm.c

ESP подключается так же как и ардуина…

С протами вывода здесь всё наоборот, Serial работает с stm, а Serial1 (в ESP у Serial1 есть только TX) печатает логи (они закомментированы).

Всё что касается работы с сетью, взято из стандартного примера FSBrowser , и немного переработано. Код из ардуины полностью перенесён в ESP с той лишь разницей, что управление и загрузка прошивки осуществляется через веб-интерфейс, а вместо SD-карты используется SPIFFS . Про работу с SPIFFS в частности, и про ESP в целом, я подробно писал здесь.

Скачиваем архив и загружаем папку data в ESP как это описано по ссылке выше. В программе вписываем название прошивки, имя своей точки доступа и пароль. Прошиваем ESP и заходим в браузер по аресу esptostm32.local/ …

Загружаем файл прошивки — Обзор ⇨ Upload, ждём когда он появится в левой колонке, жмём Enter boot и при положительном ответе жмём Write. МК прошьётся и перейдёт в обычный режим работы. При последующем обновлении нужно удалить прежний файл правой кнопкой мышки и загрузить новый.

Если в прошивке добавить, перед бесконечным циклом, вывод какой-либо инфы в USART, например так…

… тогда после прошивки это будет выводится в веб-интерфейс, сообщая об успешном обновлении. При дальнейших обновлениях будете изменять версию.

Как вы помните, USART системного загрузчика работает с битом чётности, однако в прошивке учитывать это не нужно, настраивайте как обычно…

… а в функции write_memory() специально для этого сделана переинициализация Serial’а .

С помощью кнопок Reset , On boot и Off boot можно обресетить МК или включить/отключить бутлоадер, но по большому счёту они и не нужны, так, на всякий случай. Кнопка Event вообще ничего не делает (только возвращает «ОК»), мало ли кто-то захочет какую-то функцию прикрутить.

На этом всё.

Всем спасибо

Источник

Делюсь опытом stm32 esp8266 ат команды самодельная wifi камера

На ESP8266 уходит много ресурсов (тактов CPU) на задачу помещения данных в RAM с внешних интерфейсов без использования DMA (есть жалкое подобие) и нет места для необходимой буферизации видео-потока к средним рабочим условиям WiFi. У ESP32 аналогично — желательного объема буфера для видео низкого разрешения нет.

ESP позволяют передавать необходимый поток исключительно из своей QSPI-Flash. При этом среднестатистическая скорость TCP находиться в пределах 1МБ в сек, а при UDP – 1.2..1.5 МБ при условии работы ESP8266 на 160 МГц, близкой зоне AP, одного участника — данной ESP и роутера + довольно чистого эфира рабочего канала WiFi. Чего в городе – “днем с огнем не сыщешь”.

Активный участник сообщества

BORISBRITWA

Member

Непрерывный поток данные с COM порта в TCP выше 3-х мегабит ESP8266 не протягивает. UART сидит на общей низко-скоростной шине и масса тактов CPU уходит на выемку блоков из его FIFO. В идеальных условиях (ESP8266 и роутер в железном ящике) получите к пределу 5 Мбит UART.

А когда его обрабатывать — прилеплять заголовки, и передавать по WiFi?

На 3Мегабит на вышло. действительно возникли проблемы.Добился 5 кадров в секунду на 2мегабитах (800×600),(двойной фрейм буфер пока первая часть передается ,вторая наполняется ,). Приблизительный размер картинки указывал.
Я тестировал ESP32CAM там 2-7 FPS. Я считаю, что у меня очень не плохой результат.

Есть альтернативные прошивки , чтобы еще чуточку выжать?Или 3Мегабита, это придел из-за низко скоростной шины.

Может есть вариант прошивки,моста SPI-WIFI? И что из этого соединения можно получить ?

Картинки идут в JPEG можно даже в браузере их "проигрывать" нужно просто необходимые заголовки дабовалять.
Но в режиме моста не выйдет.А так картинки на лету обрабатываются openCV, у каждой картинки есть признак начало и конец JPEG .Программа ищет начало и конец показывает и удаляет обработанные из принятых TCP пакетов.

Алексей.

Active member
Активный участник сообщества
Активный участник сообщества

Алексей.

Active member
Активный участник сообщества

Алексей.

Active member
Активный участник сообщества

BORISBRITWA

Member
Активный участник сообщества

При “transparent transmission mode” от Espressif с буфером в 2 килобайта (2048 байт) влезает в 2 TCP пакета. Один полный (1460 байт) и один заполнен на треть (588 байт).
В итоге дикие потери на формирование, разбивку на пакеты, ожидания ACK. Ну это Espressif – у них всё так

ESP8266 AT Instruction Set: Enter transparent transmission, with a 20-ms interval between each packet, and a maximum of 2048 bytes per packet.

Если считать, что передача занимает нуль мс, то Espressif заявляет, что в секунду в их AT “transparent transmission mode” передается всего 5 пакетов по 2048 байт.
2048*5 = 10240 байт в сек всего.

Возьмите хотя-бы устаревшую Прошивка TCP2UART переходника с настройкой по Web и там без проблем сможете заливать в UART 3 мегабита сплошным потоком или 10 мегабит но уже блоками. но лучше найдите более современный вариант TCP-UART.

BORISBRITWA

Member

BORISBRITWA

Member

BORISBRITWA

Member

@pvvx скачал fullflash_and_webfs_054a залил оба файла.
настройки не менял, кроме как Baud 2000000.Подключаюсь с компа к TCP серверу порт 12345 стандартные настройки .Пока все печально возможно, что из за того, что я использовал модуль см фото.(там UART_TTL переходник на плате его не отключить) либо еще чего надо в настройках?wifi.jpg uart.jpg FUHCR7XIVO7W21V.LARGE.jpg

BORISBRITWA

Member

@pvvx дошел до 15 страницы, а там "Для ускорения работы Web до 1 Мегабайта в сек требуется отключать отладочные сообщения. Иначе скорость TCP падает ниж 500 кило в сек, даже если DEBUG UART выставлена на 3 000 000 Baud."

BORISBRITWA

Member

Все печально.Перенастроил на 3076923

Отключил все делаю простой тест с мк вывожу фото которое загрузил в память мк на скорости 3076923.

Debug выключил в логах wireshark вроде все норм.не использую CTS/RTS так в ESP01 их не будет.На изображении дефекты. и обновляется как оч медленно.А должно около 5 FPS.

За секунду успевает приходить 10 пакетов 1514, 1460*10=14600 в секунду, а я вроде как передаю в 5 раз больше?
Где я накосячил) похоже не настроен мой уарт на 3Мбита,
да нет по логам все ок

start tx 1913 ms
stop tx 1980 ms
start tx 2080 ms
stop tx 2147 ms
start tx 2247 ms
stop tx 2314 ms
start tx 2414 ms
stop tx 2481 ms
start tx 2581 ms
stop tx 2648 ms
start tx 2748 ms
stop tx 2815 ms
start tx 2915 ms
stop tx 2982 ms
start tx 3082 ms
stop tx 3149 ms
start tx 3249 ms
stop tx 3316 ms
start tx 3416 ms
stop tx 3483 ms
start tx 3583 ms
stop tx 3650 ms
start tx 3750 ms
stop tx 3817 ms
start tx 3917 ms
stop tx 3984 ms
start tx 4084 ms
stop tx 4151 ms
start tx 4251 ms
stop tx 4318 ms
start tx 4418 ms
stop tx 4485 ms
start tx 4585 ms
stop tx 4652 ms
start tx 4752 ms
stop tx 4819 ms
start tx 4919 ms

Источник

Модуль WiFi HLK-RM04 + STM32F4-Discovery [Решение]

Решил свою STM32F4 подключить к WiFi модулю, выбор пал на не дорогой HLK-RM04 совместимый с OpenWirt, а для облегчения освоения, приобрёл его вместе с KIT модулем который можно подключить через COM. (впрочем настроить модуль можно и без KIT)

Обмен данными в самом модуле был проверен через СОМ порт и програмку Serial&TCP/UPD Tool скаченную с сайта производителя WiFi модуля.

А вот дальше решил подключить его по UART к STM32F4.
В STM-ке выбрал USORT3, подключил WiFi_Tx -> STM32F4_Rx и соотвественно WiFi_Rx -> STM32F4_Tx

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

В stm32f4xx_config.c был выставлен HSE 8 Мгц

Так вот, после всех этих действий, похоже не приходят данные в регистр STM32F4, соотвественно проверочный диод не зажигается, вполне вероятно я что-то напортачил, есть кто работал либо с UART либо с этим модулем, либоо просто какие нибудь мысли которые помоглибы наладить обмен данными между этими двумя устройствами?

P.S.
OpenWirt пока не трогаю, чтобы не усложнять ещё и с этим, а вообще идея заключается в управлении всем этим хозяйством через Android ))
можно было бы конечно выбрать и блютуз модуль, но мне хотелось иметь жирный канал для последующих экспериментов передачи зука, видео и .тп.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

FreeRTOS+STM32F4 Discovery
Пытаюсь портировать FriiRTOS 7.4.1 под микроконтроллер STM32F407VGT6 в Keil 4.7.0.0. Я получаю.

Микрофон STM32F4 Discovery
Здравствуйте, приобрел себе плату STM32F407VGT6. На ней стоит микрофон. Вопрос: Как с него.

USART1 на STM32F4-Discovery
Пытаюсь настроить USORT1 на STM32F4-Dyscovery. Плата подключена к компьютеру через USB-UART.

STM32F4 discovery не отлаживается
купил подключил к coosox. не отлаживается. пишет — No source available for &quot;&quot; fffffffc: .

Записывайтесь на профессиональные IT-курсы здесь

Нашёл ошибку, оказывается надо было при настройке USORT добавить ещё строчку :
USORT_Cmd(USORT3,ENABLE);

Теперь при отправке любых данных, срабатывает флаг принятых данных и загорается диод, т.е. тперь хоть понятно стало, что данные попадают в регистр )))

С простой отправкой вроде бы заработало ))
При отправке на МК по WiFi 0х01 зажигается тестовый синий диод.

А вот прерывания что-то пока не хотят работать.

Возник вот такой вопрос, возможно ли одновременно передавать аудио и управляющие команды?

Например чтобы было голосовое сообщение с ПК или планшета и одновременная отправка управляющих команд посылаемых на МК

P.S.
Повнимательней присмотревшись к модулю HLK-RM04, у него имеется два UART, которые настраиваются не завсимо друг от друга. Т.е. один UART можно настроить на один IP адрес со своим портом, другой на другой или же на тот же но на другой порт. Причём один может быть настроен как сервер, другой как клиент или оба как серевера или клиенты.
Т.е. похоже запросто можно настроить один UART для передачи управляющих команд, другой скажем для воспроизведения звука.

Сообщение от Quodro-pro
Сообщение от x893
Сообщение от Quodro-pro

Думаю облом будет со звуком

Думаете скорости UART не хватит?

По идее, можно USORT STM-ки завязать на DMA, скорость соединения самого HLK-RM04 у меня выдаёт 150 Мбит

Кстати сам UART подключил немного на другой скорости, в место 9600 поменял на 115200 (то что было по умолчанию на WiFi модуле, кстати можно и ещё быстрей, главное чтобы погрешность потерь данных была не критичная)
На вскидку сейчас не скажу, но по моему и сам модуль, тоже можно подключить не как UART а как USORT. там кажется есть пин для третьего провода для синхронизации частот тактирования.

На мой взгляд модуль вполне способен потянуть

Сообщение от Quodro-pro
Сообщение от x893
Сообщение от Quodro-pro

Думаете скорости UART не хватит?

По идее, можно USORT STM-ки завязать на DMA, скорость соединения самого HLK-RM04 у меня выдаёт 150 Мбит

Кстати сам UART подключил немного на другой скорости, в место 9600 поменял на 115200 (то что было по умолчанию на WiFi модуле, кстати можно и ещё быстрей, главное чтобы погрешность потерь данных была не критичная)
На вскидку сейчас не скажу, но по моему и сам модуль, тоже можно подключить не как UART а как USORT. там кажется есть пин для третьего провода для синхронизации частот тактирования.

На мой взгляд модуль вполне способен потянуть
Максимальная скорость передачи этим модулем 230400 bps.

Сообщение от imirkykot

Да, я это знаю. но пока не стал его подключать на такую скорость, оставил на 115200

(скорость соединения не воспринимаю как скорость обмена данными, но как бы так она показывает что это не самое узкое место. если конечно верно понимаю)

Решил на практике удостовериться по поводу второго UART и вот тут возникли вопросы.
В даташите обычные пины указываются как UART_Tx(Rx) тут проблем нет, это обычный UART.
А вот другой UART 2 найти не могу, есть только пины RXD(TXD) с пояснением Ott function serial RX(ТХ)
(может именно эти пины вообще не имют ниакого отношения к UART 2)

Однако, открывая настройку HLK_RM04 в браузере, есть такая вкладка которая отвечает за настройку UART 2:

Всё оказалось верно, действительно у этого модуля два UART
Причём по каким-то причинам на оф сайте англоязычные даташиты несколько устаревшие.
В инете нашёл чуть посвежей, для 1.46 прошивки (у меня стоит 1.78) там уже пишут, что у модуля два UART и что пины второго могут работать в двух режимах, как UART 2 или GPIO

По началу я WiFi модуль подключал как точку доступа, т.к. в проге Serial & TCP_UDP Tool почему-то нельзя выставить трёхзначные числа IP адреса, поэтому делал точку доступа вида 11.11.11.11

Если же модуль подключать как клиент (через домашний роутер как обычный ноутбук) то нужно в настройках прилагаемой проги конфигурации выставить параметры вашей сети

Или это выставить через браузер, если настраивается через Web:

В принципе тут те же настройки как в любом роутере.

При такой настройке UART 1 будет доступен по адресу который присвоил домашний роутер или который выставили вы по порту 8080
Первое поле это скорость, оно должно быть такое же как у USORT на контроллере для первого UART.
Второе поле, это режим работы (везде в даташитах они устанавливали как Server)
Ну и сам номер порта, по которому доступен наш UART1

А вот для настройки второго UART 2, необходимо указать отдельно все настройки в соответствующей вкладке там так же, выставить скорость, выставить server, но порт уже будет 8081 (или любой другой какой нужен, но не совпадающий с портом первого uart)

Я по началу не обратил внимание на скорость в UART 2 и оно отличалось, когда я подключил STM-ку к пинам второго UART, у меня естественно ничего не заработало. Потом подсмотрев этот параметр в первом UART, подставил эту строчку и сразу всё завелось, как приём так и передача.

Пины UART 2 будут 22 и 26,по даташиту модуля.

Есть ещё одна особенность меню настроек о которой узнал случайно, если нажать в браузере на надпись WERLESS-N ROUTER IEEE 802.11N то будут доступны дополнительные настройки роутера, типа файерволы управление сетью, доступы и т.д. и т.п. что пресуще любому роутеру.

Ну общее представление для начала работы с этой штукой имеется, более глубоко либо по ходу, либо от задач ))
Эксперименты продолжаются )))

В общем, не знаю понадобиться ли кому, хитрого тут ничего нет, но решил написать как этот модуль WiFi сразу настроить и подсоединить к STM32F4-Dyscovery, достав из коробки с китайскими надписями ))

Что примечательно, так это-то, что к этому маленькому модулю ничего дополнительного не нужно, ну кроме как 4-х или 6-ти проводов.
У него 5 вольтовое питание, что позволяет его подключить к пятиволтовыму пину на STM32F4-Dyscovery, а саму STM запитать от USB компа, за одно и прошивать всё равно понадобиться.

Как только питание подключили через STM32 и модуль "ожил", он становиться виден в WiFi сетях, точнее как новая сеть HI-LINK_, вот к ней то и подключаемся (я использовал ноут, но можно подключиться и чрез смартфон или планшет). Он запросит пароль для соединения, набиваем 12345678.
После подключения к этой сетке, функции админки модуля доступны по адресу который забиваем в браузере 192,168,11,254.
Для входа попросит логин и пароль, вбиваем логин admin, пароль тоже admin (как обычно в роутерах)

Теперь чуток отступлю и напишу про соединения пинов.
На STM32 я подключался к двум USORT, USORT2 пины PA2,PA3 и USORT3 пины PD8,PD9
Так вышло, что сначала я подключил USORT3 к основному UARTу на модуле, а потом USORT2 к дополнительному UART 2 на модуле, поэтому порядок получсился такой:

USORT3 STM32F4 -> UART 1 HLK_RM04
PD8(Tx) -> Pin 20 (UART_Rx)
PD9(Rx) -> Pin 21 (UART_Tx)

USORT2 STM32F4 -> UART 2 HLK_RM04
PA2 (Tx) -> Pin 22 (UART2_Rx/GPIO3)
PA3(Rx) -> Pin 26 (UART2_Tx/GPIO5)

Пины модуля HLK-RM04

На скриншоте в рамке выделил значение, которое определяет параметры работы UART:

115200 — это скорость порта
8 — это длинна пакета
n — это значение Parity, т.е. n — NONE, o — ODD, e — EVEN
1 — стоповый бит, значение 0 — без стопового бита

Т.е. всем этим хозяйством запросто можно управлять в WEB режиме для согласования с параметрами контроллера.

Ещё я отметил IP, как я писал выше, программка для теста почему-то не понимает IP вида 192.168.11.254, поэтому рекомендую для временной отладки поставить 11.11.11.11
либо написать свой софт (библиотеки на С++ есть на сайте производителя, там же есть и библиотека для Android)

Теперь раз уж мы подключили два UART, настроим второй.
В браузере есть вкладка, там нужно выставить параметры UART, я не парился и настроил скоросити UART одинаковые и в STM32F4 тоже их выставил одинаковые.
По умолчанию в UART 2 стоит 57600,8,n,1 ставим как и в первом 115200,8,n,1
затем выбираем режим Server и у нас стало доступно изменение порта, я ничего не менял, оставл 8081

Всё, с настройкой модуля закончили, осталось залить прошивку в STM32F4-Dyscovery для проверки правильности соединения портов и вообще на работоспособность.

(Ещё пост добавлю, с картинкой, ссылкой на прогу для управления этим хозяйством и тестовым проектом в CooCox для STM32F4)

Источник



Wi-Fi. SPWF01SA11. Команды

Сегодня мы начинаем интересную тему. Это беспроводные технологии для передачи данных, в частности Wi-Fi. Для чего нужна данная технология, я думаю, знают все, так как она очень популярна у всех пользователей компьютеров и интернета. Поэтому и нам, программистам МК, данную тему обойти стороной никак не получится.

А рассмотрим мы это на примере модуля от компании ST Microelectronics – SPWF01SA, который распаян в плате расширения X-NUCLEO-IDW01M1. Данную плату мы, как обычно, подключим к отладочной плате STM32 NUCLEO F401RE.

Модуль SPWF01SA представляет собой готовое решение с несколькими элементами, призванное обеспечивать стандарт передачи данных 802.11 b/g/n Основное назначение данной серии – создание приложений «Интернета вещей» (Internet of Things) – управление какими-либо устройствами или схемами удалённо. Для потоковой передачи данных, а также для передачи больших объёмов информации данные модули не предназначены, так как нет скоростного интерфейса обмена информацией между модулем и контроллером. Обмен информацией, а также передача команд и приём сообщений от модуля осуществяется посредством интерфейса USART. Есть информация, что в будущих прошивках будет поддерживаться обмен по SPI. Но я считаю, что для изучения технологии модуль подходит как нельзя лучше. У него функционал гораздо шире, чем у предшественников (полную информацию можно увидеть в технической документации, которая будет приложена к статье, а также находится в открытом доступе на сайте производителя). Также на борту модуля находится микроконтроллер, посредством которого и осуществляется вся низкоуровневая работа с модулем, находящаяся в прошивке.

Структурная схема модуля

image001

Приведу некоторые характеристики модуля:

Стандарт: 2.4 GHz IEEE 802.11 b/g/n transceiver

Контроллер: STM32 ARM Cortex-M3, with 64 KB RAM and 512 KB Flash memory – 1 MB extended Flash available on SPWF01Sx.1y

Стандарты и уровни передачи данных:

TCP/IP stack (IPv4); TCP/UDP – 8 simultaneous TCP or UDP clients and 1
socket server; DHCP; DNS; Web Server/HTTP-client

Безопасность: WEP/WPA/WPA2 personal security

Уровень сигнала передатчика
– 18.3 dBm @ 1 Mbps DSSS
– 13.7 dBm @ 54 Mbps OFDM
Чувствительность приемника
– -96.0 dBm @ 1 Mbps DSSS
– -74.5 dBm @ 54 Mbps OFDM

16 конфигурируеммых портов GPIO.

Управление данным модулем осуществляется посредством AT-команд, часть которых мы попробуем в деле в данном уроке.

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

Я думаю, мы без сомнения, просто обязаны выбрать вариант второй, так как урок у нас по программированию, и мы обязаны программировать.

Остальные тонкости работы с модулем будут рассмотрены в процессе работы с ним.

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

Файлы hts221.h и hts221.c переименуем в SPWF01SA11.h и SPWF01SA11.c.

Откроем проект в Cube MX, включим ещё один USART – USART1, так как по 2 USART мы будем общаться с компьютером, а по USART1 наш контроллер STM32F401 будет общаться с контроллером модуля.

image002

I2C можно, в принципе отключить

image003

Перейдём в Configuration. Для USART1 настроим скорость 115200 и включим глобальные прерывания

image004

image005

В USART2 скорость установим 230400, так как в результате моих исследований было установлено, что на скорости 115200 данная шина не успевает передавать сообщения, пришедшие по USART1 в компьютер, если данные сообщения превышают 24 байт, даже при включенном DMA. Также убедимся, что у нас в USART2 включены глобальные прерывания и DMA

image006

image007

image008

Таймер оставляем, может когда-то пригодится.

Также включим ножки PС8 и PC12 на выход

image033

Также прибавим им скорость в Configuration

image034

Соберем проект для Keil и отроем его. Настроим программатор на авторезет, подключим файл SPWF01SA11.c в дерево проекта и побробуем собрать проект. Соответственно, как всегда, будут ошибки из-за переименования файлов, поэтому подключим также файл SPWF01SA11.h в main.h и в SPWF01SA11.c

Также удалим объявление шины I2c в файле SPWF01SA11.c.

Удалим функции I2Cx_ReadData и I2Cx_WriteData, Humidity_IO_Read и Humidity_IO_Write, функии Press_Get_Temp, Humidity_ReadID и Humidity_ReadID, Press_Get_Press, Humidity_Read и HumidityInit.

Удалим весь код из функции Humidity_Ini и переименуем её в SPWF01SA11_Ini

Также переименуем в заголовочном файле и заодно удалим из него объявления всех макросов, ну конечно, за исключением светодиодных и удалим из файла прототип функции Humidity_Read, так как собственно сама функия удалена выше. Ещё немного исправим в заголовочном файле директивы и файл теперь станет вот таким

#ifndef SPWF01SA11_H_
#define SPWF01SA11_H_

Переходим в файл main.c.

Исправим в нём вызов функции инициализации модуля

HAL_TIM_Base_Start_IT(&htim1);
SPWF01SA11_Ini();
/* USER CODE END 2 */

Из бесконечного цикла удалим всё полностью, ну кроме конечно комментариев с ключевыми словами BEGIN и END.

Из функции обработки прерываний от таймера удалим весь код за исключением условия, в дальнейшем оно пригодится. Останется вот что

/* USER CODE BEGIN 4 */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
<
if(htim->Instance==TIM1)
<
>
>
/* USER CODE END 4 */

Теперь проект должен собраться без ошибок.

Для этого перейдём в файл SPWF01SA11.h и добавим туда некоторую структуру

<
WIFI_FALSE = 0,
WIFI_TRUE = 1,
Undefine = 0xFF
> wifi_bool;

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

Отладочную плату можно приобрести здесь Nucleo STM32F401RE

Источник