BLE SoC PHY6202

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

Также возможно имеет смысл запускать CPU с меньшей частотой, например в 2 раза меньше - 48МГц?

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

 

[pvvx]

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

 

[pvvx]

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 wmt10x_phy6222
- { first: 0x11020000, last: 0x1102993E, length: 0x0000993F }
- { first: 0x11029940, last: 0x1102AC67, length: 0x00001328 }
- { first: 0x1FFF0000, last: 0x1FFF07FF, length: 0x00000800 }
- { first: 0x1FFF1838, last: 0x1FFF5EDF, length: 0x000046A8 }

Sleep не в норме, на много более = 4.7мкА.


SDK_3.1.1.2 с собранными либами:
- { first: 0x11020000, last: 0x11028FA1, length: 0x00008FA2 }
- { first: 0x11028FA4, last: 0x11028FAB, length: 0x00000008 }
- { first: 0x11028FB0, last: 0x11029557, length: 0x000005A8 }
- { first: 0x1FFF0000, last: 0x1FFF03FF, length: 0x00000400 }
- { first: 0x1FFF1838, last: 0x1FFF441B, length: 0x00002BE4 }
Sleep не в норме - 3.7 мкА.
Сборка на Keil в этом SDK - всегда меньше 3.0 мкА.

 

[pvvx]

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

 

[cool2000]

Сборка на Keil в этом SDK - всегда меньше 3.0 мкА.

Вероятно *.lib keil собраны из других исходников, чем те, что приложены.
Что-то не усыпляется или инициализируется по другому.

 

[cool2000]

Вот к примеру, код закомментирован:

    //====  20180416 commented by ZQ
    //      to enable flash access after wakeup
    //      current consumption has been checked. No big different
    //rom_set_flash_deep_sleep();

Приложил Makefile для сборки библиотек. Запускать из директории lib.

 

[pvvx]

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

 

[pvvx]

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

 

[cool2000]

Несколько небольших дополнений, косметических правок.

• SDK/misc/CMSIS/device/phyplus/phy6222_start.s размер init stack у keil 0x400, вряд ли gcc нужно больше, 4096 явно избыточно.
• SDK/misc/jump_table.c у keil hard_fault и _hard_fault загружаются в sram
• libc memset, memcpy можно заменить на функции из rom, для этого нужно добавить в файл SDK/misc/bb_rom_sym_m0.gcc:

memset = 0x00000ea5;
memcpy = 0x00000e81;

• gcc case helpers из ld скрипта лучше убрать. ld разместит их в том же сегменте где и функции с case, это позволит избежать избыточных межсегментных переходов.

*libgcc.a:_thumb1_case_sqi.o(.text)
*libgcc.a:_thumb1_case_uqi.o(.text)

• из исходников в директории SDK/lib/ble_controller нужен только файл rf_phy_driver.c. Вероятно удобнее собрать эти библиотеки отдельно, см. Makefile выше и далее использовать без перекомпиляции.

Также прикладываю исходники mini printf c github с небольшой коррекцией. Для компиляции нужно добавить define -DPRINTF_INCLUDE_CONFIG_H

 

[cool2000]

Ключи gcc для сборки, чтобы в модуль не затаскивался всякий мусор:

--static -nostartfiles -nostdlib
-mcpu=cortex-m0 -mthumb -mthumb-interwork
-specs=nosys.specs
-Wl,--gc-sections
-Wl,--start-group -lgcc -lnosys -Wl,--end-group

 

[cool2000]

Пересчёт значений с округлением (без деления):

• температура в 0.01 C (_r16 * 100 + 50) >> 8
• влажность в 0.01 % (_r32 * 10000 + 5000) >> 15
• заряд батареи в % ((battery_mv - 2000) * 6534 + 3277) >> 16
• заряд батареи в 0.1% (((battery_mv - 2000) << 16) + 32768) >> 16

 

[pvvx]

Вероятно удобнее собрать эти библиотеки отдельно, см. Makefile выше и далее использовать без перекомпиляции.

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

 

[pvvx]

Несколько небольших дополнений, косметических правок.

• SDK/misc/CMSIS/device/phyplus/phy6222_start.s размер init stack у keil 0x400, вряд ли gcc нужно больше, 4096 явно избыточно.

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

 

[pvvx]

В BLE процесс исполнения каждой задачи в пару мс активности такой:

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

В итоге такие реализации, как Heap memory не используются и всё упрощается.

 

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

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

Т.е. 32 килобайта стека.