• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

BLE SoC PHY6202

pvvx

Активный участник сообщества
Плюс новые версии SDK жирнее и из них не вырезать ненужное из blob-libs.
А makefile нужно чтобы он не сваливал все obj в одну директорию. Заменять невозможно SDK файлы на патченные, без переименования. Да и вообще это бардак - валить все obj в одну директорию нарываясь на конфликт имен.
Можно попросить выложить map файл от сборки keil?
Инсталляция Keil вложена во все SDK от китайцев :) Плюс всё для SEGGER
 

cool2000

Member
Библиотеки собираются без проблем, но какие именно вызовы rom подменяются долго разбираться.
Всё-таки пришлите keil map файл, если не затруднит, можно в лс. Не хочу с keil заморчиваться. Надо виртуальную машину настраивать, ставить систему, и т. д.
 

cool2000

Member
Пересобрал библиотеки с ключом -Os. Получился модуль размером D900 (A9A4+2F5C):
Код:
  - { first: 0x11020000, last: 0x1102A9A0, length: 0x0000A9A1 }
  - { first: 0x1FFF0000, last: 0x1FFF07FF, length: 0x00000800 }
  - { first: 0x1FFF1838, last: 0x1FFF4793, length: 0x00002F5C }
У keil: 0xD8FC.
Осталось разобраться с функциями rom, какие нужно патчить и со списком функций, которые должны находиться резидентно в sram.
 

cool2000

Member
gcc13 ещё поджал размер кода
Код:
  - { first: 0x11020000, last: 0x1102A8F4, length: 0x0000A8F5 }
  - { first: 0x1FFF0000, last: 0x1FFF07FF, length: 0x00000800 }
  - { first: 0x1FFF1838, last: 0x1FFF4763, length: 0x00002F2C }
 

cool2000

Member
Добавил mini sprintf
Код:
  - { first: 0x11020000, last: 0x1102AE6C, length: 0x0000AE6D }
  - { first: 0x1FFF0000, last: 0x1FFF07FF, length: 0x00000800 }
  - { first: 0x1FFF1838, last: 0x1FFF4763, length: 0x00002F2C }
 

pvvx

Активный участник сообщества
Осталось разобраться с функциями rom, какие нужно патчить и со списком функций, которые должны находиться резидентно в sram.
Это очень просто если смотреть исходники.
В RAM нужны функции, которые должны работать когда Flash стирается/пишется (т.е. занята).
И другие функции, требующие строгого исполнения по времени. В Flash код исполняется медленнее - пока там XIP отработает...
Код в Flash потребляет больше и работает дольше.
 

pvvx

Активный участник сообщества
В итоге в RAM помещается код в зависимости от проекта. Если всё лезет в один регион retention RAM, то это лучший вариант.
При сборке проекта https://github.com/pvvx/THB2 я перекинул некоторые функции связанные с проектом в Flash, что дало увеличение потребления на пару процентов.
Т.е. всегда нужно искать баланс и без PowerProfiler там делать нечего...
 

pvvx

Активный участник сообщества
XIP в PHY6222 всего 2-х проводный (DSPI, не QSPI) к Flash.
К примеру, если брать ESP32 с DSPI, то если код не помещается в кэш, то производительность 2-х ядер при выполнении кода ESP32 из XIP равна производительности одного ядра 10..16 MHz Cortex M0. При этом потребление чипом максимально.
 

pvvx

Активный участник сообщества
Очень наглядно выполнение из XIP видно на обработке I2C или других аппаратных интерфейсов. При работе из XIP наблюдаются рандом паузы межу транзакциями…

По этому, детские сравнения производительности мелких чипов, да сравнения по частоте CPU – это смешное шоу. Код библиотек в Arduino ESP32 – это вообще прикол, который давно не лезет в кэш и исполняется на уровне производительности 8-ми битных чипов прошлого века.
 

pvvx

Активный участник сообщества
В итоге если SPI Flash и XIP - задирать частоту CPU выше нескольких десятков MHz нет смысла. (Смысл коммерческий есть - чип будет больше греться и жрать :) )
 

pvvx

Активный участник сообщества
Время стирания сектора SPI Flash критично для тайминга протокола BLE. В принципе критична любая задержка более пары мкс. Произойдет потеря или сбой соединения, но может восстановиться, если участники соединения смогут пересогласоваться. В WiFi – аналогично.
По этому код обработки RF и прерываний от него нужно помещать в RAM (или ROM).
(По этому ESP32 выжирает батарейки у всех BLE при соединении - требует постоянного дублирования передач и пересогласований, т.к. не успевает обрабатывать)
 

pvvx

Активный участник сообщества
Я не нашел, т.е. ещё не искал, функций в PHY SDK указывающих или опрашивающих систему таймингов BLE для выполнения (выделения времени для) длительных процедур типа стирания сектора Flash. В других SDK к таким действиям идут описания в мануале – какие, как и когда вызывать функции.

У PHY SDK, как и у некоторых других закрытых SDK, этого может вообще не быть – думайте и пишите сами такой функционал, используя исходники, выдаваемые при заключении NDA. Это необходимо чтобы написать OTA.
 

cool2000

Member
Спасибо за подробное объяснение. В таком случае, все функции, вызываемые через jump table, нужно однозначно поместить в sram. ld скрипт был написан так, что gcc старается код по максимуму разместить во flash. В китайских исходниках куча неиспользуемого и просто закомментированного кода.
Также возможно имеет смысл запускать CPU с меньшей частотой, например в 2 раза меньше - 48МГц?
 

pvvx

Активный участник сообщества
Для любых функций, запрещающих выполнение из XIP или запрет прерываний во время соединения требуется отрабатывать такой task-событие:

  • Вычислить сколько есть свободного времени до следующего события приема-передачи, путем опроса обработчика RF.
  • Если вычисленный интервал не позволяет выполнить “долгую” функцию – выход.
  • Если вычисленный интервал позволяет выполнить “долгую” функцию – выполнить и переключиться на новый event.
Конкретно для BLE соединения есть “connection interval”, “connection latency”, “connection timeout”.

“Connection interval” обычно меньше чем время стирания сектора Flash. Приемник включает малое окно приема на назначенном канале от устройства с этим шагом. Если приема нет или шум в эфире в течении этого короткого окна – приемник следует к следующему окну приема через “connection interval” и так до “connection timeout”.

“Connection latency” – это кол-во “connection interval”, которые устройство может (максимально) пропустить до следующей транзакции.

В итоге, для OTA необходимо установить “connection latency” * “connection interval” более чем время стирания/записи Flash в вашей функции.
Через (“connection latency”+1) * “connection interval” происходит обязательная транзакция согласования дальнейшего соединения.

Если тупой BT адаптер не умеет переключать/согласовывать connection интервалы (и такого китайского г.. много) – тут ничего не поделать – пользователю следует выбросить такой адаптер. Иначе он намучается с любыми BLE.
 

pvvx

Активный участник сообщества
Через (“connection latency”+1) * “connection interval” происходит обязательная транзакция согласования дальнейшего соединения. При этом связь в BLE прыгает по каналам.
И если интервалы уходят на пару мкс, то соединение тю-тю.

ESP32 и не может держать соединение на своем RC генераторе :p
 

pvvx

Активный участник сообщества
Из этого следует смешная история про “heap” (особенно в C++ и детских реализациях библиотек ESP). Во время распределения “heap” прерывания запрещены. При большом количестве фрагментов время выделения нового куска в “heap” превышает время рассогласования тайминга соединения или смещение окна приема. Это приводит к требованию повтора передачи у батарейного устройства. Потери приемов у ESP либ достигают десятикратных значений, что требует от батарейного устройства не спать и заниматься дублированием каждой передачи десятки раз (с последующим ожиданием приема подтверждения после каждой передачи).
 
Сверху Снизу