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

Стек нужен максимальный - у чипа 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. Если вычисленный интервал не позволяет выполнить...

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

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

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

Очень наглядно выполнение из XIP видно на обработке I2C или других аппаратных интерфейсов. При работе из XIP наблюдаются рандом паузы межу транзакциями… По этому, детские сравнения производительности мелких чипов, да сравнения по частоте CPU – это смешное шоу. Код библиотек в Arduino ESP32 –...

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

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

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