Результаты поиска

В итоге оставил как в последнем SDK - 64МГц. Разница между 64МГц и 96МГц для всего кода старта с кучей циклов не зависящих от XIP примерно 10..15%. Как раз наглядное пособие для ESP32 требующего код для 2x240МГц CPU от XIP SPI Flash в десятки раз меньше. А тут CPU 16МГц и разница от CLK SPI...

Смысла загрузки первых сегментов RAM для ROM в GCC нет. Они потом обнуляются или копируются из Flash. Global_config обнуляется в init_config() (rf/patch.c). Таблица векторов где-то тоже. В Keil очке это всё ненаглядно и было невозможно проследить. В Eclipse сразу стало видно... Это всё и исправил.

Разница в исполнении кода программы из Flash, только после 150 мс от страта. До этого работает ROM - наверно ожидает с ком порта на 9600 страт перепрошивки. А после 150 мс и исполняется переключение CLK SPI Flash/XIP. Т.е. итог серьезен - 16 и 96 = 2 раза. Я не перепахивал, а убрал Warning-и и...

Есть такая функция - spif_config(sysclk_t ref_clk, uint8_t div, uint32_t rd_instr, uint8_t mode_bit, uint8_t QE) Она задает работы XIP c Flash. Если менять ref_clk, то время старта (TestTHB2) от ноги RST выходит: Шкала времени в секундах. Чем занят чип первые 150 мс - непонятно. Но далее...

@cool2000 - предложения по оптимизации и прочему просьба направлять в Pull requests или регистрируйтесь как соучастник проекта (пишите тут в личку). Проекты (всё ПО и коменты в github) с PHY62x2 будут только на русском языке. Нечего более засорять форум техническими деталями... Тут люди болтают...

Всё обновлено Ток sleep в GCC сборке равен сборке в Keil и составляет 2.8 мкА. Стек более 32-х килобайт.

А конструкция .stack: { *(.stack*) } > RAM используется только для того, чтобы написать warning - превышен размер retention RAM. Но лучше это определять/cделать по другому...

Вот правильная инициализация указателя стека из *.ld __initial_sp = ORIGIN(RAM) + LENGTH(RAM); __StackTop = ORIGIN(RAM) + LENGTH(RAM); при hal_pwrmgr_RAM_retention(RET_SRAM0); Т.е. 32 килобайта стека.

А каждый лишний кусок сохраняемой памяти - это жручка на её утечку во время сна чипа.

Сегмент "bss" во многих SoC BLE тоже не сохраняется на время sleep. Т.е. он не входит в retention RAM и при просыпании обнуляется. Кроме того, в некоторых реализациях и rodata не сохраняется, а каждый раз при просыпании чипа восстанавливается и на это уходит время и энергия. Т.е. чем меньше...

Т.е. тема уменьшать размер стека, навязанная непонятно кем - это не соответствует концепции работы в BLE, т.к. затребует других более сложных решений и нагромождений ненужного хлама. Учитесь писать вложенные вызовы с переменными в стеке, вместо статических буферов и всяких "heap" моделей...

В BLE процесс исполнения каждой задачи в пару мс активности такой: Чип проснулся, стек пуст, т.к. область 32 кило не сохранялась, установки контроллеров сброшены. Отработали задачу с использованием буферов в стеке и инициализацией контроллеров. Отключили все используемые контроллеры. Чип заснул...

Стек нужен максимальный - у чипа 64 килобайта RAM и она пустая. Если под retention использовать по минимуму 32 килобайта, то 32 килобайта остается на стек. Heap не используется, а для OTA надо будет иметь буфер на сектор flash. Для BLE другая политика использования RAM. "memcpy()" и прочее лучше...

Нет смысла - время сборки всего проекта составляет до пары секунд. Улучшать можно бесконечно, но надо решить основную задачу - минимизация потребления.

Один из вариантов, для eclipse и Keil: https://disk.yandex.ru/d/_HKwYWX7Nkm6og

Я уже накалякал нужный мне makefile для всех имеющихся SDK версий....

Собираемые исходники TestTHB2 и define везде одинаковы, кроме 3.1.3 - добавляется USE_ROMSYM_ALIAS. И средний ток в версиях GCC более 10 мкА, вместо 7.9 мкА в Keil-SDK 3.1.1.2.

GСС SDK_3.1.3 от Ai-Thinker - { first: 0x11020000, last: 0x1102982E, length: 0x0000982F } - { first: 0x11029830, last: 0x1102AB57, length: 0x00001328 } - { first: 0x1FFF0000, last: 0x1FFF07FF, length: 0x00000800 } - { first: 0x1FFF1838, last: 0x1FFF5E97, length: 0x00004660 } SDK_3.1.3...

Нужно "ИИ" тренировать не болталогии, а на оптимизацию кода. Но кто же выделит на это энергию и прочее, вместо обучения "ИИ" рекламе по втюхиванию всего доверчивым человекоподобным?

Если писать правильно - то почти без разницы. Потребление CPU растет не совсем линейно от частоты. Работа XIP требует энергии - надо дергать линии к Flash. А всё разместить в RAM и ROM с нулевой задержкой исполнения не всегда выйдет. И некоторые процедуры, такие как обслуживание внешних...