pvvx
Активный участник сообщества
Это не "тошниловка", анормальные опции компилятору
-Wall
-Wpedantic
-pedantic
-Wextra
-Werror
...
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Делюсь опытом AdHoc пошаговое руководство
- Автор темы cheblin
- Дата начала
-Wall
-Wpedantic
-pedantic
-Wextra
-Werror
...
pvvx
Активный участник сообщества
pvvx
Активный участник сообщества
Компилятор и сами процедуры switch протокола это самое последнее, что необходимо решить в описываемых задачах.
На первую необходимо рассмотреть интерфейс физической передачи и ресурсы по производительности MCU.
А имеем:
При минимальном периоде значения замера тока или напряжения от микросхемы INA219 идут через 84 мкс, у INA226 – через 140 мкс.
Без разгона шины i2c их не обслужить. Т.е. стандартные либы и HAL можно сразу отметать. Колдуя с бубном в регистрах делителей i2c выходит максимальный разгон i2c до 800..1000 кГц.
При этом занятость CPU STM32F103C8T6, к примеру для опроса INA226:
Вот этой дырки уже не хватает его дровам USB для получения хотя-бы минимально необходимого трансфера. Тут придется ещё и переписывать HAL и либу USB. Увольте…
Единственным решением является адаптация протокола передачи данных, что AdHoc исключает и предложить пока не может.
Ему кейловский компилятор мешает.
На первую необходимо рассмотреть интерфейс физической передачи и ресурсы по производительности MCU.
А имеем:
- Шину USB 1.1 12 мбит/с с ведущим. Он строго в 1 мs опрашивает наше устройство и если у вас что не готово, то следующая любая транзакция будет возможна только на следующий опрос ведущего через эти 1 ms.
- Шину i2c, с которой большинство MCU не умеют работать без полной озадаченности CPU. Единственный нормальный контроллер i2c/smbus из пролетавших на данном форуме MCU имеется у RTL SoC. В нем загружаете в FIFO набор требуемых для выполнения транзакций с шиной i2c и контроллер без участия CPU их автоматически выполняет, с указанными повторами при ошибках и т.д. По окончанию обработки “скрипта” имеете готовые байтики ответов от устройства. ip модель контролера в нем общедоступная.
При минимальном периоде значения замера тока или напряжения от микросхемы INA219 идут через 84 мкс, у INA226 – через 140 мкс.
Без разгона шины i2c их не обслужить. Т.е. стандартные либы и HAL можно сразу отметать. Колдуя с бубном в регистрах делителей i2c выходит максимальный разгон i2c до 800..1000 кГц.
При этом занятость CPU STM32F103C8T6, к примеру для опроса INA226:
Вот этой дырки уже не хватает его дровам USB для получения хотя-бы минимально необходимого трансфера. Тут придется ещё и переписывать HAL и либу USB. Увольте…
Единственным решением является адаптация протокола передачи данных, что AdHoc исключает и предложить пока не может.
Ему кейловский компилятор мешает.
pvvx
Активный участник сообщества
Устройство давно готово (много лет назад) и ждет вашего кода для испытания и сравнения...
В нем всё предусмотрено естественным путем - чуть больше загрузки CPU или будет тупить протокол и будет лажа
pvvx
Активный участник сообщества
У нас есть ещё аналогичный пример:
Это ESP8266. Скорость внешней “шины” WiFi у него 72 Мбит/с, CPU 160 МГц. Но вот полученный максимум для вашего любимого UART всего до 3 Мбит/с.
Тут мы надеемся, что AdHoc нам поможет и с ним выдаст большую скорость…
Впрочем, если автор AdHoc сможет достичь у данной связки скромных 1 Мбит/с – это будет уже великим успехом.
PS: думается, что никаких ответов от Автора AdHoc мы не получим - он будет исключительно увиливать и ссылаться на кейл и прочее...
Это ESP8266. Скорость внешней “шины” WiFi у него 72 Мбит/с, CPU 160 МГц. Но вот полученный максимум для вашего любимого UART всего до 3 Мбит/с.
Тут мы надеемся, что AdHoc нам поможет и с ним выдаст большую скорость…
Впрочем, если автор AdHoc сможет достичь у данной связки скромных 1 Мбит/с – это будет уже великим успехом.
PS: думается, что никаких ответов от Автора AdHoc мы не получим - он будет исключительно увиливать и ссылаться на кейл и прочее...
cheblin
Member
вот тот код, который мы видим тут был написан либо банщиком, либо ардуинщиком...
впрочим я их слабо различаю
кто?? кто в обычном main цикле ТАК читает и отправляет пакеты в USB? ... а потом ругаеца что пропускная способность недостаточна.
что? стырил демо код вставив в него свои куски?? так делай это с умом...
даже при отправки UART все нормальные используют колбэки от прерываний и в них вычитывают байты либо отправляют...
... а есть ли у использованного USB CDC драйвера колбэки...
оказывается есть прям в файле usb_endp.c один на приём, другой на передачу .
наблюдаем как гений начнёт маняврировать... 4...3...2...
впрочим я их слабо различаю
кто?? кто в обычном main цикле ТАК читает и отправляет пакеты в USB? ... а потом ругаеца что пропускная способность недостаточна.
что? стырил демо код вставив в него свои куски?? так делай это с умом...
даже при отправки UART все нормальные используют колбэки от прерываний и в них вычитывают байты либо отправляют...
... а есть ли у использованного USB CDC драйвера колбэки...
оказывается есть прям в файле usb_endp.c один на приём, другой на передачу .
наблюдаем как гений начнёт маняврировать... 4...3...2...
cheblin
Member
а прочитать моё сообщение внимательно... в приведёном коде, строчкой выше всё тотже компилятор прекрасно с NULL справляется...
банщик?
cheblin
Member
cheblin
Member
мне?
мне реально пофиг, кодогенератор подкрутил, кнопку жмакнул и получил новый код...
а вот кто другой свой рукописный код портировать будет - кекс гарантирован.
STM32F103 уже ппц древний, у него проблем реально много... но для легаси, его всё выпускают. А так - лучше уже взять STM32F042 для мелких свистков или STM32F401\411 для более серьезных проектов. Для вторых уже и аналог блупила давно есть.
Странно.... у меня HAL, F103 и INA219 и замеры в 1мс прекрасно читаются с INA, есть свободное время для MCU и все по USB отправляется. Уже достаточно скоро всё добро выложу на гит.
Выглядит бомж-вариант измерителя так:
Софт, эмулятор устройства:
Софт, USB измеритель (с куллером на 5в в качестве нагрузки):
В динамике это всё намного интереснее смотрится) В телеге могу показать видео.
Софт уже поддерживает USB, LAN (WiFi) измерители, но надо ещё много чего допиливать + железо нормальное разработать (в процессе).
Читаю я по колбеку, а вот отправка... у меня тоже в main сделана.
Оч сложный код)
cheblin
Member
какбудто это что то хорошее...
хорошо бы местный гений понял обсуждаемое, и... держал себя в рамках приличия...
ведь культурно же общаемся...
скоро выложу версию PowerProfiler с AdHoc протоколом, всё намного проще и понятнее получается.
@A_D что у вас за протокол?
у нас тут канун китайского нового года, ...это когда все на всё забивают... образуется некоторый объем свободного времени...
если есть желание/возможность чётко сформулировать, обмен какими данными в вашем проекте нужен, можно было бы обсудить.
всех этих железяк у меня нет(каганову при встречи всё раздарил), да и для того чтобы встраивать код протокола, их и не нужно
от меня код от Вас тестирование.
Если оно и так прекрасно и стабильно работает, иногда нет смысла усложнять...какбудто это что то хорошее...
У меня своё, простое, пакуются данные по структурам описанным и передаются в виде массива байт (буфер), а на софте уже обратно разбирается маршалом (да, на C# работа с указателями..) - проблем с производительностью не заметил, как и усложнять нет смысла пока что. Работает как с USB, так и с UDP пакетами, можно добавить поддержку COM портов, да всё будет аналогично.что у вас за протокол?
у нас тут канун китайского нового года, ...это когда все на всё забивают... образуется некоторый объем свободного времени...
если есть желание/возможность чётко сформулировать, обмен какими данными в вашем проекте нужен, можно было бы обсудить.
всех этих железяк у меня нет(каганову при встречи всё раздарил), да и для того чтобы встраивать код протокола, их и не нужно
от меня код от Вас тестирование.
Желания пробовать что то новое пока нету, т.к. даже работы по допиливанию текущего не мало... а у меня ещё работа есть, да дела домашние.
Я когда глянул код профайлера - сначала вообще ничего не понял) Сильно уж замудрёно. Потом софт глянул, даже не запускал, просто скрины - куча настроек, параметров и т.п. Что то показалось удобным, как идею интерфейса, что то не оч - в общем, некоторое влияние на видение своего софта оказало. В это время писал LAN версию CV Meter и собственно родилась мысль, а почему бы и не добавить поддержку USB устройств. Только удобную и простую для пользователя.
cheblin
Member
всё это за 15 минут делается, вы ж читали, ну ОК, за 22...
Я не про ваш проект, а про свой. У меня комплексный проект - железо + прошифка + софт для пк и вот в этих трёх направлениях работы не на 15 и не на 22 минут.
Как бы прикрутить номер к машине - да, дело 15 минут, но вот создать машину... уже не 15 минут.
pvvx
Активный участник сообщества
Мы же ждем супер правильный код от вас. Я вообще не программист и мне пофигу что вам не нравится в коде десятилетней давности. Та и об этом вас предупреждали - первые дрова ST не содержали явных калбаков
pvvx
Активный участник сообщества
INA219 - 84 us, по русски микросекунд!
Понял, моя ошибка, я подумал, что между 1мс замерами как то пауза в 84мкс получается и всё. А тогда вопрос, смысл в таком некрасивом числе ? Логичнее же что то более целочисленное - 100мкс, 1мс и подобное.