Прошивка 2.21.31 для китайского клона сканматика 2прo

  • Автор темы Автор темы ZeVVs
  • Дата начала Дата начала
В свободное время если лень не одалеет попробую потестить...

а китайматик на прошивке с 2 процессами иногда задумывается. причину надо еще выяснить.
2 ядра больше жрут. Замерить бы потребление и температуру в 2 и 1 ядерном режиме. Ну а причину можно примерно понять прогнав код через ИИ:)

Анализ скорости и частоты опроса для ESP32​

Исходные данные:

  • Скорость UART: 921600 бод (115200 * 8)
  • Тактовая частота ESP32: 240 МГц
  • Размер FIFO: 4096 байт (SIZE_FIFO)
  • Режим: SAVE_MODE с динамической задержкой

1.​

  • Битрейт UART: 921600 бит/с
  • Байтрейт (с учётом старт/стоп-битов):
    • 1 байт = 10 бит (8 данных + 1 старт + 1 стоп)
    • Максимальная скорость:
      921600 / 10 = 92160 байт/с ≈ 92.16 КБ/с

2.​

Чтобы не терять данные, ESP32 должна успевать обрабатывать каждый байт.

  • Время передачи 1 байта:
    1 / 92160 ≈ 10.85 мкс
  • Минимальная частота опроса:
    1 / 10.85 мкс ≈ 92.16 кГц
    (92 тысячи проверок в секунду)

3.​

Ваш код использует динамические задержки для балансировки нагрузки:

cpp

#ifdef SAVE_MODE
uint32_t min_delay = 1; // 1 мс (1000 проверок/сек)
uint32_t max_delay = 1024; // 1024 мс
uint32_t critical_size = 3072; // 75% FIFO
#endif
  • При заполнении буфера > 75%:
    Задержка уменьшается до 1 мс (частота опроса ≈ 1000 Гц).
  • При отсутствии данных:
    Задержка увеличивается до 1024 мс (частота ≈ 0.98 Гц).

4.​

  • Теоретически требуется: 92.16 кГц
  • Реализовано: до 1 кГц (при min_delay=1 мс)
  • Разница: в 92 раза меньше требуемой частоты!
Последствия:
При непрерывном потоке данных на максимальной скорости:

  • Буфер FIFO (4096 байт) заполнится за:
    4096 / 92160 ≈ 44.4 мс
  • За это время задача выполнится всего ~44 раза (1 раз/мс), что недостаточно для своевременной очистки буфера.

5.​

Чтобы успевать обрабатывать данные, нужно:

  • Уменьшить min_delay до 0.25-0.5 мс (2000-4000 проверок/сек)
  • Использовать прерывания вместо опроса

Вариант 1: Уменьшение задержки​

cpp

#ifdef SAVE_MODE
uint32_t min_delay = 0.5; // 0.5 мс (2000 проверок/сек)
uint32_t max_delay = 1024;
uint32_t critical_size = (SIZE_FIFO / 4) * 3;
#endif

Вариант 2: Прерывания (рекомендуется)​

Заменяем активный опрос на события:

cpp

#include <freertos/queue.h>

// Создаём очередь для UART событий
QueueHandle_t uart_queue;
uart_event_t event;

void setup() {
// Настройка прерываний UART
uart_driver_install(UART_NUM_0, SIZE_FIFO, SIZE_FIFO, 20, &uart_queue, 0);
}

// Задача для UART
void serial_reader_task(void* param) {
for (;;) {
if (xQueueReceive(uart_queue, &event, portMAX_DELAY)) {
if (event.type == UART_DATA) {
size_t len = event.size;
uart_read_bytes(UART_NUM_0, buffer, len, portMAX_DELAY);
SerialBT.write(buffer, len);
}
}
}
}

6.​

  • Тактовая частота ESP32: 240 МГц
  • Один цикл задачи: ~50 тактов (оптимизированный код)
  • Проверок в секунду:
    240 000 000 / 50 = 4 800 000 (4.8 МГц)
Вывод:
Даже при частоте опроса 2000 Гц (каждые 0.5 мс) нагрузка на ядро составит:
(2000 * 50) / 240 000 000 ≈ 0.04%
Ресурсов более чем достаточно для уменьшения задержки.


Рекомендации:​

  1. Уменьшите min_delay до 0.5 мс:

    cpp

    uint32_t min_delay = 0.5; // Для pdMS_TO_TICKS(0.5)
    • Убедитесь, что configTICK_RATE_HZ = 1000 в FreeRTOSConfig.h
  2. Используйте прерывания UART вместо Serial.available():
    • Это исключит потерю данных и снизит нагрузку на CPU.
  3. Протестируйте пропускную способность:

    cpp

    // В конец задач добавьте:
    static uint32_t counter = 0;
    if (++counter % 1000 == 0) {
    printf("Bytes sent: %d\n", bytesWrite);
    }
Итог: С уменьшением задержки до 0.5 мс или переходом на прерывания вы гарантированно обработаете поток 921600 бод без потерь.

Но ИИ может насоветовать так что вообще ничего работать не будет..)))
 
меньше 1 мсек задержку использовать проблематично в том методе что используется. так бы уменьшил до 0.1 мсек. действительно, сегодня выяснял успеваем мы принимать все данные или нет и мои расчеты показали что опаздываем примерно в 3 раза. В общем, я принял волевое решение при заполнении буферов ФИФО больше половины задержку отключить полностью. также для улучшения отзывчивости максимальную задержку я ограничил 128 мсек. получился вполне неплохой вариант! почти не уступает оригиналу по отзывчивости и при этом не греется как утюг. думаю на этом остановиться. хотел еще вариант на прерываниях для сравнения, но пока повременю. вчера еще узнал что бывают платы-обрезки с одним ядром вместо двух и пониженной тактовой частотой. за этим тоже надо следить.. итоговый скетч приложил

выкладываю прошивку в бинарном виде. заливать примерно так:
esptool.py write_flash \\
--flash_mode dio \\
--flash_freq 40m \\
--flash_size detect \\
0x1000 bootloader.bin \\
0x8000 partitions.bin \\
0x10000 app.bin \\
0x100000 data.bin

Еще одна оптимизация прошивки. Хотел так сделать изначально но глупый ИИ отговорил. Сколько раз уже убеждался что ему нельзя верить! Теперь потребление в режиме ожидания 50 ма, при полной загрузке 135-140 ма.

Тот же вариант в бинарном виде
 

Вложения

Потестил на прошивке блока.... не работает "велосипед".
Оптимизируйте потом выкладывайте.
 
А по поводу режима диагностики, энергопотребления, температурных режимов есть информация?
Почему через USB работает быстрее? ну так это и ежу понятно. USB 1 версии 12 мбит/с, 2 версии 480 мбит/с. а в беспроводном режиме скорость блютуз предположительно 2-3 мбит/с, но после него идет проводное соединение с контроллером сканматик 128 кбайт/с которое и является узким местом. скорость каншины обычно 500 кбит/с а если к-line то не более 115200 бит/с. в таких условиях многое зависит от прямых рук и используемого софта. а прошивка модуля блютуз выполняет простую работу - пересылает данные в обеих направлениях. и ей пофигу что это за данные и для чего они нужны. причем мой вариант это делает эффективно, а ваш пытается прочитать данные на порядок больше раз чем объем самих данных. И тут главный вопрос - как быстро микроконтроллер включает Троттлинг?
 
Всем привет. Поскажите по прошивке Китайматика, народ выложил прошивку .31 хотя в ветке пишут что есть какие то критические ошибки. Пользуюсь им иногда дря работы с Pcm, так стоит шить на эту версию или не трогать?
 
после него идет проводное соединение с контроллером сканматик 128 кбайт/с которое и является узким местом
Откуда такие данные?
Скорость этого соединения вы задаете в прошивке и она 921600 попробуйте ее изменить и вы с контролером сканмата не соеденитесь. Так как он настроен на эту скорость. Отсюда и была проблемма с обычними блютуз модулями так как они без спец прошивке на этой скорости не работают.
 
народ выложил прошивку .31 хотя в ветке пишут что есть какие то критические ошибки
Последняя выложенная 32 версия. Работает нормально. Говорят что в свежих версиях проги уже идет доработка под 3 сканматик с вайфаем. Для второго 32 версии достаточно.
 

Вложения

Спасибо. Тогда завтра обновлю свои приборы.

Главное что бы потом PCM не начал ложить блоки ))
 
  • Like
Реакции: vic_pnz
Откуда такие данные?
Скорость этого соединения вы задаете в прошивке и она 921600 попробуйте ее изменить и вы с контролером сканмата не соеденитесь. Так как он настроен на эту скорость. Отсюда и была проблемма с обычними блютуз модулями так как они без спец прошивке на этой скорости не работают.
921600 б/сек это 115200 байт/сек. не путайте боды и байты. но передача на блютуз действительно идет с меньшей скоростью. примерно на уровне CAN шины 500 кбит/сек. Хотя это может зависеть от модели передающего устройства блютуз. теоретически должна быть больше
 
921600 б/сек это 115200 байт/сек. не путайте боды и байты. но передача на блютуз действительно идет с меньшей скоростью. примерно на уровне CAN шины 500 кбит/сек. Хотя это может зависеть от модели передающего устройства блютуз. теоретически должна быть больше
Ну ну..... вам бы теорию подтянуть потом писать. Почитайте что такое uart.
 
921600 бит/с (baud rate) в UART примерно соответствует 1 мегабит/с, но не является точным эквивалентом. Хотя 921600 близко к 1000000 (1 мегабит), следует учитывать, что UART использует асинхронную передачу данных, и реальная скорость передачи может немного отличаться из-за накладных расходов на служебные биты (старт, стоп, четность).

Более подробно:
  • UART (Universal Asynchronous Receiver/Transmitter):
    Асинхронный последовательный интерфейс, используемый для связи между устройствами, где данные передаются по одному биту за раз.

  • Baud rate:
    Скорость передачи данных в UART, измеряется в битах в секунду (bps).

  • 1 мегабит/с (Mbps):
    1 миллион бит в секунду.

  • 921600 бит/с:
    Более точное значение для многих UART-устройств.
Почему не совсем эквивалентно:
При передаче данных по UART, помимо самих данных, передаются также служебные биты, которые необходимы для синхронизации и определения начала и конца пакета данных. Эти служебные биты занимают место и снижают эффективную скорость передачи полезной информации. В результате, при скорости 921600 бит/с, фактически передается меньше 1 мегабита полезных данных в секунду.

В заключение:
Хотя 921600 бит/с в UART можно считать приблизительно равным 1 мегабит/с, следует помнить о накладных расходах на служебные биты, которые делают реальную скорость передачи данных немного ниже.
 
это противоречит тому что я писал? в байтах это 115200. 1 байт = 8 бит. знаний у вас крайне мало чтобы заниматься программирование. не ваше это
 
Так я и не программист... но код у меня получился рабочий в отличии от вашего.
 
Так я и не программист... но код у меня получился рабочий в отличии от вашего.
ваш код годится разве что в качестве стресс-теста. ну это для любителей как быстрей угробить железку. и ваше утверждение что моя прошивка якобы уваливает ЭБУ не вызывает у меня никакого доверия. да, при непрерывной передаче там может быть небольшая задержка, которую можно легко убрать при желании, изменив один параметр. но опять же! никто в здравом уме не будет заливать прошивку через блютуз.
 
Ну хорошо.. вы супер программист теоретик. Не будем разводить споры. Ваша задача написать код, моя протестить. Есть эталон... допустим моя прошивка. Сдалайте прошивку на 2 ядрах с изменением имени блютуз которая будет читать блок быстрей моей и начнет писать блок а не уваливать. Желательно тоже быстрее моей наче зачем заморачиватся. Готов вам продоставить видосы тестов если вы не верите. Как сделаете, я на всех форумах где вы выложели напишу что ваша прошивка лучшая еще и репу подниму. Поймите у меня нет задачи кагото там упрекать обсирать и т д. Задача получить рабочий вариант прошивки. Оптимизированный для работы с контроллером сканматика stm32 а не передачей фоток или файлов по блютузу.
 
ваш код годится разве что в качестве стресс-теста
Основной код находится в библиотеках ардуино Ide своим кодом я лишь указываю пины скорость и что куда слать.... а библиотеки не мои и вы ими так же пользуетесь. Или я не прав
 
никто в здравом уме не будет заливать прошивку через блютуз.
Это не аргумент отказатся от рабочего варианта и перейти на не рабочий.
Может пошивка с использованием задач а не лупа (RTOS) и быстрая но в связке с stm32 ее что то тормозит. Опять же там аппаратное управление потоком (cts rts) все ваши тайм ауты уже реализованы в библиотеках зачем еще что то добавлять? Или я опять не прав поправте меня.
 
Это не аргумент отказатся от рабочего варианта и перейти на не рабочий.
Может пошивка с использованием задач а не лупа (RTOS) и быстрая но в связке с stm32 ее что то тормозит. Опять же там аппаратное управление потоком (cts rts) все ваши тайм ауты уже реализованы в библиотеках зачем еще что то добавлять? Или я опять не прав поправте меня.
вы путаете системный код и пользовательский. прошивку в данном случае рассматриваем как пользовательскую программу. ваша прошивка посылает примерно 2 млн запросов чтобы получить 1 байт данных. считал ИИ все претензии по расчетам к нему. ну это просто бессмысленная трата ресурсов. На днях напишу версию для десктопа в вашем варианте и немного оптимизированном и будет наглядно видно как это работает. и опять же непонятно по какой шине вы заливаете прошивку и какой скорости? если CAN 1мбит/с то да, через блютуз не будет успевать, а если 500 кбит/сек то скорости хватает и причину увала надо искать в другом месте. и я подозреваю вы мою прошивку дополняете еще кодом по смене имени блютуз. делаете это не очень грамотно, потому как необходимые навыки отсутстуют.
 
Опять вы про мои навыки... нет, ничем не доплняю. Только ваш код. Мой подопытный блок edc16c34. Pcmflash. Считать с него можно только калибровки... по к линии, моя читает за 3.11 минут ваша последняя 14.14, фул в него пишется по кану моя пинет за 9.20 мин. Ваша виснет после стирания области данных с увалом.
Давайте без смен имени.. просто на 2 ядрах...
Я неделю вечерами пробовал и ИИ подключал толком ничего не вышло. Либо висло либо медленно работало. Закончилось терпение. И я остановился на рабочем и наиболее быстром варианте.
Но так как вы программист у вас думаю получится.

ваша прошивка посылает примерно 2 млн запросов чтобы получить 1 байт данных.

А в какой части кода это можно увидеть?
 
Есть еще момент при тестировании.
Уваленный блок поднимается повторной прошивкой. (Специально уваливал отключая питание). Через юсб влёхкую. А вот через блютуз не все мои варианты смогли это сделать. Остановился на том который смог.