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

[cheblin]

...на самом деле нет.

встречайте I2C-SensorsDataCollector

от оригинального Power Profiler осталось только старое окружение, которое тоже в принципе большой ценности не представляет.

Проект в итоге превратился в универсальный сборщик данных с устройств на I2C шине.

Изюминка: псевдо-ассемблерный набор инструкций, которые "проигрываются" микроконтроллером. Может быть легко переконфигурирован, способен работать с любыми типами устройств на шине I2C.

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

Основная идея публикации этого, "сырого" проекта - помощь в понимании базовых принципов как всё работает в связке с AdHoc протоколом

 

[pvvx]

Нельзя в IRQ такой громоздкий цикл cheblin/I2C-SensorsDataCollector Когда будет работать USB?
В оригинале там был один опрос одного значения c I2C с временем занятости и запретом IRQ для USB на 50..70 us. Поставлен на IRQ для минимизации джиттера опроса и дабы исключить дополнительное чтение регистра состояния готовности датчика I2C (на это нужна ещё одна транзакция по I2C и подбор времени опроса с синхронизацией таймера периода опроса с точностью менее 1 us, на что данный проект не рассчитан и не хватает частоты CLK на шину I2C у STM32).

 

[pvvx]

И да нужна отладка, которой не было.

Для отладки нужна приемная часть с USB и отображением что там читается на чем угодно.

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

Параметры у INA219 - шаг опроса по I2C 84 мкс. Максимальная частота I2C у STM около 800 кГц. Кол-во тактов на транзакцию чтения регистра в тактах I2C от 51. Время исполнения транзакции 51/800000 = 0.000064 сек. т.е. примерно за 70 мкс без использования HAL. C HAL не влезает вообще.
На все остальные процессы у вас есть до 14 мкс (оптимистично). Это значит до 0.000014(сек)*72000000(Hz макс CLK CPU STM32F103) = 1008 тактов со всеми вычетами прерываний, ожидания шин, вставки тактов ожидания CPU при работе программы с Flash (Flash память медленная и выборки с частотой 24 МГц для нее потолок.) (с SRAM успевает и не вставляет такты ожидания), обработки ужасного HAL USB.

 

[pvvx]

Более точные временные диаграммы по состоянию CLK на I2C с рабочего примера PowerProfiler и INA219:

Цикл опроса 84 us. Выходной поток в USB 11.9 ksps (> 23.24 kbytes/sec - такой поток нормально буферизировать в STM32F103 негде).
Джиттер опроса менее 1 us.
Предельно разогнанная и стабильно работающая частота CLK I2C порядка 833 kHz.
Время между опросами I2C у CPU на другие процессы менее 11 us. (до пары переключений контекста в RTOS )
В них желательно уложить сборку пакета и отправку в USB...

 

[A_D]

встречайте I2C-SensorsDataCollector

 

[A_D]

Посмотрел то там, то сям, зашёл в demo_.c, а там вижу:


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

 

[pvvx]

В итоге - надо ещё изучать, как это работает, а не просто написать, как требуется для конкретной задачи.

Я изучил, что там понакалякал @cheblin.
Глупостей много, с жизнью несовместимо, но это только начало. Так сказать вхождение @cheblin в жизнь MCU и малых SoC...
Он же написал - доделает, а пока прототип стыковки к AdHoc. Дальше будет хуже и именно с авто-кодом от генератора AdHoc. Потом забросит, поняв что не вписывается AdHoc в тему MCU и малых SoC, исключая случай Arduino (там производительность чипов в лучшем случае используют до 5%). Это не шутки...

 

[cheblin]

Нельзя в IRQ такой громоздкий цикл

в оригинале говнокод, о чём я ранее и писал. таймер не просто не нужен. он даже вреден, подозреваю является одной из причин низкой производительности устройства в целом.

код опроса и записи в I2C шину должны делаться по прерыванию.

 

[pvvx]

в оригинале говнокод, о чём я ранее и писал. таймер не просто не нужен. он даже вреден, подозреваю является одной из причин низкой производительности устройства в целом.

код опроса и записи в I2C шину должны делаться по прерыванию.

Пару лет назад был такой код - прерывание таймера ставило флаг...
Такие решения были выброшены по причине ужасного джиттера опроса с выбросами и дублями на снятых показаниях с автоматически обновляемых регистров измерения у INA2xx со своим плавающим дискретным шагом от встроенного RC генератора, а так-же по причине не прокачки потока в USB самой ОС/RTOS.
Сейчас разнобой обновления бьет в несколько секунд давая одинаковый код. А тогда, при том-то джиттере RTOS - примерно каждый третий - на осле смотреть страшно - более похоже на шум

 

[pvvx]

в оригинале говнокод, о чём я ранее и писал.

Вы сами влипли выбрав этот пример - там усё по максимуму и любой лишний код и ... Как раз для теста ваших глупостей с AdHoc.
Полное исключение HAL и любых калбаков и XTOS сможет спасти ситуацию.

 

[cheblin]

Да, сразу понятно, номер канала (?)... куча функций-прототипов пустых... и всё в таком духе.

нет.
в каждом канале , если у него по дизайну есть возможность отправки пакетов, есть transmitter

у которого есть ссылка на функцию вытягивания пакетов предназначенных для отправки.

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

до более сложного, когда очередь отправляемых пакетов встраивается в структуру канала


и это привидено как пример в Demo.c

"проблемма" в том, что функция вытягитвания пакетов получает ссылку на transmitter, канала, а не на сам канал. вот тот подчёркнутый, вами приведёный код - это получение ссылки на канал, по ссылке на transmitter канала

 

[cheblin]

Вы сами влипли выбрав этот

я уже исправился, когда перестал пытаться причесать проект, выкинув всё в помойку.

пока не до конца...да.

 

[cheblin]

куча функций-прототипов пустых..

это функции обработки прилетающих пакетов... а что там должно быть в демокоде?

смотрите в Test.c там ничего пустого нет ибо тестирование отправки приёма пакетов.

обратите внимание это полностью, машино генерённый код.

 

[pvvx]

обратите внимание это полностью, машино генерённый код.

А разве это какое-то достижение, спустя 35 лет после выхода всяких пакетов собирающих оптимизированную архитектуру ALU с готовым кодом транслятора СИ с учетом всех зависимостей под конкретную задачу?
STM32CubeMX тоже что-то генерит, у Microchip так-же аналогичная приблуда есть...

 

[pvvx]

Для начала вам советую сгенерировать в STM32CubeMX проект USB-COM на STM32F103C8T6 с Echo (там это штатный пример) и проверить throughput своего AdHoc.

 

[pvvx]

А я вам пока историческую справку приведу:

USB <-> JTAG SWD: J-Link и ST-Link сделанные на STM32F103C8T6.

У обоих один тип USB булки. Но у производителя STM итоговая скорость дрыгания ножками SWD в два раза меньше, чем говонокод от SEGGER. И throughput отладки и прошивки имеет такие-же различия. У “сообщества миллионов мух” на нем-же есть OpenOCD. Он самый медленный.

 

[A_D]

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

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

до более сложного, когда очередь отправляемых пакетов встраивается в структуру канала
Посмотреть вложение 8738

и это привидено как пример в Demo.c

"проблемма" в том, что функция вытягитвания пакетов получает ссылку на transmitter, канала, а не на сам канал. вот тот подчёркнутый, вами приведёный код - это получение ссылки на канал, по ссылке на transmitter канала

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

 

[cheblin]

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

 

[A_D]

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

Вот второе я и сделал, итоги написал выше, скачивать и изучать подробно желания вообще не возникло, исходя из увиденного...

 

[pvvx]

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

Я не скачивал. прямо в github всё посмотрел открыв сразу десяток страниц и CTRL-F. Контекстных ссылок он же не дает Как и Keil.
cheblin - Купите нормальные мониторы от 4K, они ныне дешевы