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

cheblin

Member
...на самом деле нет.:)

встречайте 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:
upload_2020-1-27_21-57-27.png
Цикл опроса 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

Active member
Посмотрел то там, то сям, зашёл в demo_.c, а там вижу:
upload_2020-1-28_0-1-36.png

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

pvvx

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

cheblin

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

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

pvvx

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

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

pvvx

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

cheblin

Member
Да, сразу понятно, номер канала (?)... куча функций-прототипов пустых... и всё в таком духе.
нет.
в каждом канале , если у него по дизайну есть возможность отправки пакетов, есть transmitter
upload_2020-1-28_6-44-53.png
у которого есть ссылка на функцию вытягивания пакетов предназначенных для отправки.

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

до более сложного, когда очередь отправляемых пакетов встраивается в структуру канала
upload_2020-1-28_6-40-34.png

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

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

cheblin

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

смотрите в 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

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

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

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

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

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

cheblin

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

A_D

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

pvvx

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