Делюсь опытом Power Profiler на рельсах AdHoc protocol

[cheblin]

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

CubeMX точно также требует такую же Java .. чёта не слышал возмущений...
ставят и нахваливают
ставят и нахваливают
ставят и нахваливают

это ж не какого то там питона... навязывают

 

[pvvx]

косаемо USB на HAL
гуглить:
на приём CDC_Receive_FS это колбэк и там всё просто
а на передачу не блокирующий CDC_Transmit_FS но отловить конец передачи будет чуточку сложнее

по I2C на HAL
гуглить:
на приём HAL_I2S_Receive_IT и HAL_I2S_RxCpltCallback
на передачу не блокирующий HAL_I2S_Transmit_IT + HAL_I2S_TxCpltCallback

I2S - это другая шина. Для звука...
CDC_Receive_FS это прием, но никакой гарантии, что в данном калбаке отработает CDC_Transmit_FS. Он может быть занят.
По тому и повторите то, что накалякано в PowerProfiler - все ваши калбаки будут ставить флаги, а по ним уже и определитесь что и когда и куда, чтобы вписаться в макс трансфер.

 

[cheblin]

I2S - это другая шина. Для звука..

верно. исправляюсь:
на приём HAL_I2C_Master_Receive_IT и HAL_I2C_MasterRxCpltCallback
на передачу не блокирующий HAL_I2C_Master_Transmit_IT+ HAL_I2C_MasterTxCpltCallback

все ваши калбаки будут ставить флаги

нет.
простешие операции типа заполнения пакета с инфой версии устройства и постановки на отправку , будут выполняться прям в колбэке!
операции "длительной" обработки думаю перекинуть в колбэки one pulse timer с детерменированной задержкой.

например, опрос устройств на I2C, по колбэку HAL_I2C_MasterRxCpltCallback стартуем пульс таймера с нужной задержкой периода опроса, по его колбэку стартует следуший запрос по шине I2C и так далее... если в колбэке обнаружится что пакет заполнился и на отправку готов, обмениваем указатели заполненного пакета и пустого , стартуем отправку USB...

это другая философия, да

 

[pvvx]

простешие операции типа заполнения пакета с инфой версии устройства и постановки на отправку , будут выполняться прям в колбэке!

Он будет вызываться в пределе 1 раз в 1 ms по получению данных от хоста в USB в данной RX EndPoint.
А I2C регистр INA219 надо опрашивать через 84 us. И эта задача важнее - джиттер не допустим, т.е. чем меньше - тем лучше.
Передача блока в USB так-же возможна только тогда, когда хост произведет опрос с шагом 1 ms TX EndPoint передачи.
Если у вас потоки RX/TX имеют дисбаланс по трафику, то всё будет криво.
В данном примере PowerProfiler RX поток мал - иногда, в раз в сотни секунд приходит команда, а вот поток TX предельный для дров USB у STM32F103 при загрузке основной задачей - работой c I2С.
Трафик всей шины USB будет распределен на передачу. А в дровах от ST это в теоретическом пределе 64 байта раз в 1 ms (по опросу RX TX EndPoint хостом).

 

[pvvx]

Если превалирует RX, то балансировка потоков RX и TX производится путем не считывания RX EndPoint. При занятой RX EndPoint хост не сможет записать туда ничего и будет вынужден ожидать (через 1 ms) следующего опроса освобождения RX EndPoint и т.д. Тем самым и балансируется. Но в дровах ST этого недано

 

[pvvx]

Буфер TX EndPoint вы можете заполнить в любой момент когда он свободен, т.е. прошлый считан хостом и снят флаг занятости. А буфер RX EndPoint можно не считывать пока не будет времени на его обработку, т.е. не будет свободен TX EndPoint для передачи. По этому ваш калбак в RX никому не нужен.
Возможно использование только калбака по освобождению TX EndPoint. Но есть ли такой в дровах USB от ST?

 

[pvvx]

например, опрос устройств на I2C, по колбэку HAL_I2C_MasterRxCpltCallback стартуем

Время выполнения этого калбаск в тактиках STM32F103 более чем вся транзакция по шине I2C на 800 кГц CLK. Как и любое переключение контекста...

пульс таймера с нужной задержкой периода опроса, по его колбэку стартует следуший запрос по шине I2C и так далее...

и не так далее, а получаете скорость опроса I2C регистров не более пары тысяч в сек, а надо 11904 раза в сек для INA219 на максимальной частоте готовности её ADC.

это другая философия, да

да, да

 

[pvvx]

Перед вами элементарная задача - решить сколько времени занимает переключение контекста у STM32F103 в вашей так называемой ОС от ST. И рассчитать сколько их возможно в секунду. Только на таймер опроса регистров потребуется 11904 раза в сек... На USB уже останется то, что останется А останется очень мало и дрова будут тормозить, т.е. пропускать часть событий инициированных хостом - не успевать подготавливать всё в RX и TX EndPoint до следующего опроса хоста с шагом 1 ms. Та и пусть - но упадет трафик шины USB1.1.
Изначальный (теоретический) трафик в USB дровах ST - 64 байта* 1 ms, т.е. 64 000 байта в сек на оба направления RX и TX.
Для передачи 11904.761905 значений из 16- битного регистра INA219 надо всего 23809.52381 байта в сек.

 

[pvvx]

"Сначала маленький экскурс в историю,
А к практике мы перейдем потом (опосля, значит).
Так вот, все это началось в те самые времена,
Когда Исус Христос сказал впервые “Ом”."
В i386 в DOS (! скорость обработки прерываний) была беда - не могла опрашивать UART RX со скоростью 115200 baud (11520 байт/прерываний в сек). И так пока в UART не сделали FIFO на 8 байт.
Через десяток лет, на ГГц процах с много ядер на шевеление ногой в порту (путь LPT) происходит - переход на самый низкий уровень ОС с опустошением всея кеши всех ядер и ожиданием выполнения транзакции по pci express на которой сидит аппаратный эмуль шины i8080, тактируемый 8 МГц. Опустошение кешей свзяно с тем, что а вдурх это переключение банков памяти, как ранее использовалось в DOS в качестве дополнительной, в окне...
Ещё через десяток лет. pci express обучили выполнять отложенные транзакции - т.е. между запросом и ответом можно работать с другими транзакциями. И наконец забыли и забили о совместимости с i8080 - первой PC. Но скорости дрыгания ногой в порту это не прибавило...

 

[pvvx]

"А к практике мы перейдем потом (опосля, значит)."
Время переключения контекста для процессов в Linux для малых SoC:
https://esp8266.ru/forum/threads/mt7688an-hlk-7688a.2934/page-2#post-61018

760 микросекунд на создание процесса на не самом производительном CPU - кошмар ?
Вы посмотрите сколько времени уходит на 1 системный вызов или на переключение контекста во взрослом CPU.
Если вы создает процессы за микросекунды - вы явно что -то делаете не так.

 

[cheblin]

.. в доме также должны быть и мясные закуски!

 

[pvvx]

.. в доме также должны быть и мясные закуски!

Значит AdHoc сдулся перед MCU и малыми SoC?
Подавай жирненькое ?
Дык жирненькое тоже не тянет. Те циферки и на него действуют, даже при передаче между процессами, не говоря уже о их создании.
Убирайте из авто генерируемого кода любые вызовы call. Это плохо отражается на производительности MCU и малых SoC - беды с кеш и предсказанием.
Only inline. И то следите за размером вписывания в скорость заполнения кеша проца...

 

[pvvx]

Так-же не забываем, что для SMT32 любое обращение проца к периферии - это остановка на дцать тактов WAIT ожидания отработки медленной шины к устройству и его низкочастотному тактированию.
В HAL на это наплевали. А тем более вызовы калбаков апосля прерываний в RTOS - это вообще тысячи никчемо загубленных тактов CPU.

 

[cheblin]

RTOS

??? генератор безсмысленных наукообразных слов врубил?

 

[pvvx]

И т.к. вы приползли на форум чипов с WiFi и BLE, то RTOS с тиком 1 ms на основных типах CPU (Cortex или ESP) при CLK CPU на 8..10 MHz полностью занят только задачей WiFi или BLE и на пользовательскую задачу у проца времени уже нет. При этом и трафик примера типа Echo уже дает заниженные показания до 2-х раз от предельного на максимальной частоте CPU. Т.е. на 8..10 MГц всего осуществляется минимальная поддержка работы WiFi или BLE.
Для STM32F103 с USB, HAL и ST дровами всё значительно хуже. Там для задачи пользователя времени вообще нет и при этом полный трафик USB1.1 не обеспечивается.

 

[pvvx]

??? генератор безсмысленных наукообразных слов врубил?

RTOS - Операционная система реального времени — Википедия
Real-Time Operating System
Я знаю, что вы как программист с этим не знакомы. У вас есть понятия только Виртуальная мнимая система. Для них вы и создаете AdHoc.

 

[cheblin]

А тем более вызовы калбаков апосля прерываний в RTOS

Ы? какое отношение RTOS имеет к обсуждаемым прерываниям и колбэкам?

 

[pvvx]

Ы? какое отношение RTOS имеет к обсуждаемым прерываниям и колбэкам?

Простое. Она в базисе примера и управляет этими прерываниями и "колбэкам".

 

[cheblin]

Она в базисе примера и управляет этими прерываниями и "колбэкам".

какого примера?
что за дичь, ты что несёшь???
нука быстро читать Nested vectored interrupt controller (NVIC)

 

[pvvx]

Урезание функциональности от FreeRTOS ни о чем не говорит.
Вы опять застряли в лейбочках, не понимая сути их работы.
Это норма для программеров Они заучивают названия процедур из библиотек и а как это работает им всё равно.