• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Делюсь опытом AdHoc пошаговое руководство

pvvx

Активный участник сообщества
Посмотрел несколько SDK к чипам BLE. Только в одном применяется RTOS и там из-за этого проблемы… В других никакой операционки (псевдо-мультизадачности) не используется – всё работает по событиям, как и в ESP8266. В главном цикле описывается основная управляющая программа. Обычно имеет до пары ветвей с проверками флагов. На такой распределитель на данных CPU уходит всего до пары тактов на проверку ветвления. С RTOS не сравнить – там тысячи тактов и много стеков в динамической памяти (куче), а у данных SoC RAM мало и они жрут питания меньше…

Это вам о ваших "калбаках" при отправке в USB… Ну типа первый урок вам “как-же это сделать в малом MCU, если тики переключения RTOS и между задачами дольше необходимых реакций обработки основного потока?”.
 

pvvx

Активный участник сообщества
@cheblin -
Далее второй урок, про USB.

USB Host управляет транзакциями по шине. Без его запроса выводить что-то на шину незя.

Контролер USB имеет Endpoint с Descriptor-ами, к которым обращается host.
Endpoint – это типа блока в памяти или аппаратным FIFO с определенным номером. Descriptor-ы описания USB устройства описывают как с ними работать. При запросе Host-а данные из этого блока передаются на шину или с шины в такой блок. Влезть в прерывание USB и остановить всё?
В программе, в которой вы не разобрались, после приема блока по прерыванию выставляется флаг, что в приемной Endpoint есть данные. Но обработка их производится только тогда, когда блок Endpoint передачи пуст, т.к. он один, на его занятость так-же указывает специальный флаг. Какой тут нужен калбасник?
Пока данные из приемного Endpoint не выедены, host не может запихать в него новые. На пришедшую команду в приемной Endpoint необходимо ответить. Для этого принятый фрейм, когда передающий Endpoint свободен, декодируется и формируется ответ в него – в Endpoint передачи. Процедура передачи всего-навсего заполняет FIFO или участок RAM Endpoint передачи и ставит флаг занято. Когда host обратиться к нему – тогда он и будет передан аппаратно. Какой тут нужен калбасник? Влезть в прерывание USB и остановить всё?

У самого устройства основная задача – это стабильно, с минимальным джиттером, по прерыванию таймера опрашивать датчик и складывать данные в буфер.
Когда рабочий буфер заполнен, он перекладывается в буфер передачи фрейма значений и ставится флаг готовности этих данных или счетчик пропуска, если USB не успевает, при достижении определенного кол-ва пропусков отключает это прерывание и основной цикл системы передает ошибку. Это всё в прерывании таймера. Другая метода = непозволительная роскошь.
В итоге основной цикл опрашивает 3 флага и отрабатывает все необходимые задачи – передача в один буфер Endpoint ответов на запросы или блока потока данных. Остальное, включая всю обработку USB, крутиться по прерываниям.

Может накрутить цельный RTOS с семафорами и кучей очередей(QUEUE)?
Приезжайте и вставьте сотню кило и разгоните CPU в имеющихся у меня STM32F103C8T6. Можно проще – дайте бабла на более мощные MCU всем желающим, тогда они встроят в них ваши калбаски. :p
@cheblin - Где получать от вас бабло или куда писать на поставку надом бесплатных мощных MCU всем желающим встроить в них калбаски? :) :)
 

pvvx

Активный участник сообщества
К примеру, простой дешевый чип BLE TLSR826x имеет десяток аппаратных Endpoint с fifo. Для некоторых типов USB устройств при таком раскладе вообще не требуется никаких прерываний и прочей мишуры (но для USB-COM требуется - там разные запросы в одни Endpoint) . Тупо заполняете эти FIFO и ставите флаг повтора. В FIFO Endpoint-ов для данных к передаче или приему просто пишите/читаете, хоть побайтно, отслеживая переполнение - всё остальное сделает сам чип под руководством host-а. Сколько байтиков накопилось в FIFO, столько host и заберет. Какие при этом нужны "калбаски"?
Modbus чуете? Запрос-ответ... Host один... Endpoint с номерком...
 

pvvx

Активный участник сообщества
Если в MCU мы начнем петь хором про Rust и мочиться калбаками с try catch, то ...
 

pvvx

Активный участник сообщества
обмазался...
а теперь решил ещё и в перьях изваляться? но зачем? разве было недостаточно комично?
Та неа
Просто вы упорно игнорируете опыт и мастерство уже полувековой совокупности.
Всё пытаетесь на свой лад, Ардуиновские привычки переделать...
Тама в видо из "про шарикова" это есть другими словами... :)
 

pvvx

Активный участник сообщества
Где-же готовый AdHoc? Мне вот надо уже перекинуть код из PowerProfiler на BLE контроллеры...
Правда текущий протокол для микроконтроллера сляпан не под эту задачу - у него есть и другие предназначения в зависимости от верхнего ПО - для работы с почти любым чипом через i2c с задаваемой (энергонезависимой сохраняемой) конфигурацией и периодом опроса регистров в поток...
Простой копипаст процедур самого разбора запросов/ответов и формирования выходных фреймов прошел удовлетворительно. Пришлось изменить названия процедур работы с i2c и вместо отправки в USB на процедуру отправки пакета в стек BLE:
[inline]ble_sts_t bls_att_pushIndicateData (u16 attHandle, u8 *p, int len); [/inline]
Работает. Но есть но - не тянет поток выше 5 килобайт в сек при TX 1 mbps PHY BLE. Т.е. выходит что стабильный поток возможен со скоростью 1000 sps замеров тока и напряжения с INA2xx или до 2-х ksps для тока или напряжения.
Когда-же AdHoc это исправит?

Переключать на TX 2 mbps PHY BLE не вижу смысла - меньше дистанция и не все приемники ещё это умеют...
 

pvvx

Активный участник сообщества
Для закрепления материала о архи-сложностях работы с USB привожу пример процедуры putc(), используемой для вывода отладочных сообщений (printf()) в USB в самом дешевом на али чипе BLE:
Код:
int usb_putc(int c) {
                if(!(reg_usb_ep8_fifo_mode & FLD_USB_ENP8_FULL_FLAG)){
                               reg_usb_ep_dat(USB_EP_IN) = (u8)c;
                               return c;
                }
                return -1;
}
/* где:
reg_usb_ep8_fifo_mode – регистр управления FIFO и FLD_USB_ENP8_FULL_FLAG - флаг переполнения этого FIFO.
reg_usb_ep_dat(USB_EP_IN) – (Endpoint) регистр данных этого FIFO */
Это всё, что нужно для передачи в USB в простейших китайских чипах (исключая аутсайдеров по разработке типа Espressif).
У европейских и прочих брендов там без прерываний, калбаков, HAL, …, пачки потерянных вечеров на выискивание необходимых либ и покупки лицензий не обойтись.
 

pvvx

Активный участник сообщества
покопаюсь в esp8266/32. Тулчейнов - глаза разбегаются.. это точно всё ещё актуально?
ну и обсуждаемые BLE.
Вот актуальные рекомендации, как ускоряется BLE при правильном формировании пакетов:
Скорость Bluetooth 5: как достичь максимальной пропускной способности для вашего приложения BLE
Но эти скорости достигаются в описанных условиях без "подтверждения", т.е. типа UDP.
Я пока использую только с подтверждением, BLE 4.2 1Mbsp для совместимости со старьем, соответственно теряется скорость. Для передач без подтверждения, требуется ещё какой-то над-протокол...
 

cheblin

Member
esp8266/32. Тулчейнов - глаза разбегаются.. это точно всё ещё актуально?
очевидно, если читать инфу по ссылке, то да.
необязательно именно прям ESP ... но для достижения большой пропускной способности, большой MTU must have.

ну и обсуждаемые BLE.
сфера применения BLE для очевидна.. маложрущие устройства с небольшим информационным потоком.

выводы: для проектов типа PowerProfiler, BLE мало пригоден. Ни один из ключевых факторов BLE не задействован, к тому же ещё и скорость... так себе.

так что изделия Espressif ... возможно, да, не идеальны... но пока рано списывать
 

pvvx

Активный участник сообщества
сфера применения BLE для очевидна.. маложрущие устройства с небольшим информационным потоком.

выводы: для проектов типа PowerProfiler, BLE мало пригоден. Ни один из ключевых факторов BLE не задействован, к тому же ещё и скорость... так себе.
Задействован - посмотрите потребление INA226 в режиме работы :)
Сам чип BLE на полном трансфере с опросом не более 10 мА, а при понижении до максимальных скоростей INA226 - общий уровень до пары мА.

Скорость у BLE в норме - 1366.4 Kbits/s на BT5.0 в одну сторону, а их две - rx/tx :p
120 кило - это 30 кsps 16-ти битных замеров тока и 30 кsps напряжения одновременно, или 60 ksps на что одно.
Такой INA2xx нет. По тому я пока пошел на совместимость со старьем - больше то INA2xx не дает...
Если до BT4.2 и более старые, тогда да - маловато.
TLSR8266 не имеет расширенного буфера PHY. TLSR8269 - имеет всё BT5.0.

так что изделия Espressif ... возможно, да, не идеальны... но пока рано списывать
what's the maximum BLE transfer speed beteen ESP32 and Nordic alike ble SOC - ESP32 Forum
И при этом куда из неё это выводить? :confused: Даже Flash такую скорость записи с работой BLE у ESP32 не потянет!

ESP32 cписано в утиль за потребление более 500 мА, старого одно-антенного WiFi на 2.4 ГГц и при этом ещё не тянущая TCP по стандарту... Даже это меньше жрет https://esp8266.ru/forum/threads/mifi-3g-4g-router.2087/#post-30943
Да и Arduino приложения на энтой ESP32 не дают в Web или websocket среднего потока выше BLE 5.0 :(
Правда детям и этого не надо - у них вкл/выкл светодиод раз в вечер...
 

pvvx

Активный участник сообщества
Отличие старого BLE и 5.0:
Полностью поддерживается DLE с максимальным размером полезной нагрузки канала данных 251 байт:

DLE не поддерживается, поэтому максимальный размер полезной нагрузки канала данных по умолчанию составляет 27 байтов:

TLSR8266 c INA226 (работа передатчика на детектор, DLE не поддерживается, включено подтверждение передачи, тайминг соединения 10 мс):
upload_2020-1-18_9-27-13.png
 

pvvx

Активный участник сообщества
По потреблению для наглядности, даже во время такого "совместимого" соединения c расширенным MTU:
upload_2020-1-18_9-36-6.png
Поднес приемник ведущего - ниже по уровню это его передача модулю TLSR8266. TLSR8266 на них в режиме приема.
Высокие - передачи TLSR8266. В остальные моменты только опрос INA226 и сон CPU.
ESP32 тут .... :D
 

pvvx

Активный участник сообщества
https://esp8266.ru/forum/threads/ble-modul-jdy-10-na-chipe-tlsr8266.4654/page-11#post-69477
Без каких-либо оптимизаций по питанию, просто вставил пару процедур в SDK чтения INA226 и:
При соединении:
upload_2020-1-18_10-1-51.png
При ожидании соединения:
upload_2020-1-18_10-2-16.png
Прямо с USB 5V вместе со всем барахлом...
Где-же, где-же утюг ESP32? ;)
Может хваленый STM32 покажет меньше? :rolleyes:
 

cheblin

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

upload_2020-1-18_15-26-22.png
 

pvvx

Активный участник сообщества
потребление - это одни из... факторов. для счётчика воды очевидно определяющий
но для чего смотреть на потребление чипа, который используется в проекте типа PowerProfiler? или к примеру осцилограф?
Для дешевого пробника в виде авторучки. Или повесить на АКБ для накопления и просмотра замеров за год в целях уточнения его характеристик. Для последующего выбора более качественного товара.
тут важна скорость передачи данных прежде всего... BLE отдыхает
Покажите хоть одну реализацию. У меня они были.
Качество связи поганое WiFi и тем более с ESP - постоянные выпадения, а буфера у ESP не хватает даже на INA226, чтобы выдержать дырку в связи с AP (достаточно коллизии одного beacon-а).
В общем практическую эксплуатацию в простом сценарии - передача замеров от INA2xx ни одни ESP не потянул. BLE - влегкую. День и ночь.
 

pvvx

Активный участник сообщества
В PowerProfiler и пришлось переходить на USB, т.к. качество связи по WiFi 2.4ГГц в городе, в доме, не годится.
PowerProfiler - это не БП - не путайте :p
 

pvvx

Активный участник сообщества
@cheblin - основные бяки если PowerProfiler на ESP:
1) Чипы ESP дают ужасные помехи на любые ADC рядом с ними.
2) USB нема.
3) Нет возможности включить в испытательный макет между его БП и измерительной частью из-за перегрузки БП макета.
4) Нет возможности включить в испытательный макет между его источником питания и БП макета из-за перегрузки источника (к примеру USB). Т.е. требуется дополнительный источник питания к ESP.
5) При отладке WiFi и BLE устройств, для чего и разрабатывался PowerProfiler, ESP оказывает дикое влияние на соединение самого подопытного. Вы не сможете измерить массу режимов, т.к. под ухом у вас источник коллизий и загрузки радио-канала.

В разных вариантах приоритет не по списку - меняется, но список остается :p
И это столько г.. от ESP всего в простой фигне. В других устройствах его ещё больше...
 

pvvx

Активный участник сообщества
Использовать ADC в ESP при работе WiFi невозможно. Там до 3-х бит, остальное шум. Изначальная линейность при стерильных условиях - не более 4-х бит (ESP32).
RTL-ы - все 16 бит при работе WiFi!
ESP (были) хороши для начинающих на первый урок с WiFi. Далее всё.
 
Сверху Снизу