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

Всё обновлено Ток 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 с нулевой задержкой исполнения не всегда выйдет. И некоторые процедуры, такие как обслуживание внешних...

Т.е. монстр на 240МГц c двумя ядрами (ESP32) не успевает за тупым чипом на 16 МГц, работающим через ужасно тормозную XIP с малой памятью. А виновники - ардуино-долбанутые наголову.

Это было раскрытие "сИкрета" почему выходит так.

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

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

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