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

BLE SoC PHY6202

pvvx

pvvx

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

pvvx

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

pvvx

Активный участник сообщества
Нужно "ИИ" тренировать не болталогии, а на оптимизацию кода. Но кто же выделит на это энергию и прочее, вместо обучения "ИИ" рекламе по втюхиванию всего доверчивым человекоподобным?
 
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

pvvx

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

cool2000

Member
Вот к примеру, код закомментирован:
C: 
    //====  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

pvvx

Активный участник сообщества
Я уже накалякал нужный мне makefile для всех имеющихся SDK версий....
 
C

cool2000

Member
Несколько небольших дополнений, косметических правок.
  • 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
 

Вложения

C

cool2000

Member
Ключи gcc для сборки, чтобы в модуль не затаскивался всякий мусор:
Код: 
--static -nostartfiles -nostdlib
-mcpu=cortex-m0 -mthumb -mthumb-interwork
-specs=nosys.specs
-Wl,--gc-sections
-Wl,--start-group -lgcc -lnosys -Wl,--end-group
 
C

cool2000

Member
Пересчёт значений с округлением (без деления):
  • температура в 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

pvvx

Активный участник сообщества
cool2000 написал(а):
Вероятно удобнее собрать эти библиотеки отдельно, см. Makefile выше и далее использовать без перекомпиляции.
Нажмите для раскрытия...
Нет смысла - время сборки всего проекта составляет до пары секунд.
Улучшать можно бесконечно, но надо решить основную задачу - минимизация потребления.
 
pvvx

pvvx

Активный участник сообщества
cool2000 написал(а):
Несколько небольших дополнений, косметических правок.
  • 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

pvvx

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

pvvx

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

pvvx

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

pvvx

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

pvvx

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

Т.е. 32 килобайта стека.
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу