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

BLE модули TB-04 (TLSR8251)

nikolz

Well-known member
И самый главный вопрос - почему тогда её не подавили efuse - ведь оно ЖРЕТ(!), даже если не используется, а в чипе есть ключи по питанию сегментов!
Если не отключена - лишняя жручка в sleep и чипы должны отличаться по потреблению в sleep (не deep-sleep) в документации!
потому, что это экспериментальные чипы и никто с ними серьезно, кроме Вас не экспериментирует (шутка).

Вспомнил такую фишку из старых времен, заказали у советского разработчика экспериментальные чипы.
Получили, стали экспериментировать, а сигналов на некоторых пинах нет как нет.
Звоним разработчикам. А они говорят, что на эти пины еще не завели сигналы,
а чипы которые прислали - это так в основном корпуса.

Теперь так уже не делают.
В России теперь делают лишь то, что никто не делает, потому что не нужно.
 

pvvx

Активный участник сообщества
На всякий случай "AN_19011501-C5_Telink Kite BLE SDK Developer Handbook.pdf" кинул тут
Там подробнее о разметках SRAM, FLASH, boot, OTA и т.д.
потому, что это экспериментальные чипы и никто с ними серьезно, кроме Вас не экспериментирует (шутка).

Вспомнил такую фишку из старых времен, заказали у советского разработчика экспериментальные чипы.
Получили, стали экспериментировать, а сигналов на некоторых пинах нет как нет.
Звоним разработчикам. А они говорят, что на эти пины еще не завели сигналы,
а чипы которые прислали - это так в основном корпуса.

Теперь так уже не делают.
В России теперь делают лишь то, что никто не делает, потому что не нужно.
Это к чему приложить?
 

pvvx

Активный участник сообщества
Из той доки следует, что 'normal stack', да и размер SRAM у чипов отличается:
1605381512105.png
А Ai-Thinker во всех своих проделках TB-01..04 на TLSR8253 считает, что размер SRAM 64 килобайта и типа что чип TLSR8258, а не TLSR8253 - не верьте своим глазам :p
 

pvvx

Активный участник сообщества
1605384981331.png
对于功耗调试正确的应用程序(硬件电路和软件的功耗调试都正确),最终 (I_suspend - I_ deepRet)是一个固定的值,比如suspend 为30uA,deepsleep retention 为2uA 时,(I_suspend - I_ deepRet) = 28uA;(T_init*I_init)最终也是固定 的值,比如I_init 为3mA,T_init 为400 uS,(T_init*I_init)为1200 uA*uS
I_avgSuspend – I_avgDeepRet
= T_cycle (28 – 1200/T_cycle)
可以看到,当T_cycle 的值较小时(例子中T_cycle < 43 mS),使用suspend mode 最终的平均功耗更低;当T_cycle 较大时(T_cycle > 43 mS),使用deepsleep retention mode 最终的平均功耗会更低。
---
Для приложений с правильной отладкой энергопотребления (аппаратная схема и программная отладка энергопотребления верны) окончательное (I_suspend-I_deepRet) является фиксированным значением, например, когда приостановка составляет 30 мкА, а сохранение глубокого сна - 2 мкА, (I_suspend-I_ deepRet ) = 28uA; (T_init * I_init), наконец, является фиксированным значением, например, I_init - 3 мА, T_init - 400 мкс, (T_init * I_init) - 1200 мкА * мкс

I_avgSuspend – I_avgDeepRet = T_cycle (28 – 1200/T_cycle)

Можно видеть, что когда значение T_cycle небольшое (T_cycle <43 мс в примере), конечное среднее энергопотребление при использовании режима ожидания ниже;

когда T_cycle большое (T_cycle> 43 мс), используется окончательное среднее энергопотребление в режиме глубокого сна. Расход будет ниже.
---
Но для AT прошивки при T_cycle 33 мс приостановка составляет 70 мкА:
1605384821902.png

Ai-Thinker - работать, работать и ещё раз работать! :)
 

pvvx

Активный участник сообщества
Но первое включение питания не радует:
1605387515570.png
Тут atc1441 работать, работать и ещё раз работать! :)
Примерное поведение при соединении (connect):
1605387604345.png
Соединение примерно на 4-ой секунде, далее обмен с мастером, чтение атрибутов и переход к коннект time 1 сек...
За период на графике среднее составляет 65 мкА,
в период между 4 и 5 сек при простом sleep и коротком цикле коннект time - полка на уровне 60..75 мкА.
 

pvvx

Активный участник сообщества

nikolz

Well-known member
Ага - в init_lcd() стоит sleep_us(50000), в show_atc_mac sleep_ms(1800 + 200 + 1800 + 200 + 1800) (=5800 ms) вместо сна на это время...
интересно,
1) сколько потребляет чип при вычислениях с отключенным модулем BLE ?
2) можно ли без дополнительных внешних чипов обеспечить просыпание с периодом десятки минут или часов?
3) можно ли сформировать свой протокол связи?
4) какая получится скорость передачи коротких и редких сообщений с учетом установления соединения?
 

pvvx

Активный участник сообщества
интересно,
1) сколько потребляет чип при вычислениях с отключенным модулем BLE ?
3..3.3 mA при 24 MHz
2) можно ли без дополнительных внешних чипов обеспечить просыпание с периодом десятки минут или часов?
да. RTC
3) можно ли сформировать свой протокол связи?
Если надо принимать/передавать всякую белиберду смотри https://github.com/Ai-Thinker-Open/Telink_825X_SDK/tree/master/example/8258_feature_test
Там должно быть передача и прием raw RF на разных модах...
4) какая получится скорость передачи коротких и редких сообщений с учетом установления соединения?
Вопрос не ясен, т.к. всё стандартно для BLE 5.0. Или вы не разбирались в стандарте BLE?
Время установки соединения в BLE зависит от вопрошающего. Скорость передачи данных - от connection interval и установленного MTU.
См. Google что-то типа Maximizing BLE Throughput
Установить connection interval в 7.5 ms чип позволит, но сможет ли внешнее устройство поддержать - зависит от его древности, тупости и дешевизны... Особливо касается iOS устройств :) Современные андроиды тянут.
Сможете ли вы использовать всё время connection interval для приема и передачи большого MTU - зависит от загрузки опрашивающего устройства. Он может не хотеть говорить только с вами и опрашивает несколько устройств... :)
Так что четкого ответа на некорректный ваш вопрос нет. А на данные вопросы можно написать книгу... и всё равно ясности не прибавится, т.к. будет многобукав.
 

nikolz

Well-known member
3..3.3 mA при 24 MHz

да. RTC

Если надо принимать/передавать всякую белиберду смотри https://github.com/Ai-Thinker-Open/Telink_825X_SDK/tree/master/example/8258_feature_test
Там должно быть передача и прием raw RF на разных модах...

Вопрос не ясен, т.к. всё стандартно для BLE 5.0. Или вы не разбирались в стандарте BLE?
Время установки соединения в BLE зависит от вопрошающего. Скорость передачи данных - от connection interval и установленного MTU.
См. Google что-то типа Maximizing BLE Throughput
Установить connection interval в 7.5 ms чип позволит, но сможет ли внешнее устройство поддержать - зависит от его древности, тупости и дешевизны... Особливо касается iOS устройств :) Современные андроиды тянут.
Сможете ли вы использовать всё время connection interval для приема и передачи большого MTU - зависит от загрузки опрашивающего устройства. Он может не хотеть говорить только с вами и опрашивает несколько устройств... :)
Так что четкого ответа на некорректный ваш вопрос нет. А на данные вопросы можно написать книгу... и всё равно ясности не прибавится, т.к. будет многобукав.
Благодарю за ответы.
 

pvvx

Активный участник сообщества
Благодарю за ответы.
Уточнение по п.п.1 - смотря какие драйвера/куски чипа типа UART, SPI, Flash, GPIO и т.д. активны и интенсивности работы шин (хоть к памяти). Без них может выйти и менее 2 мА.
Уточнение по п.п.2 - Таймер для deep-sleep работает от RC или внешнего кварца на 32768 Гц. Но в SDK время во всяких pm_sleep ограничено...
 

pvvx

Активный участник сообщества
2) можно ли без дополнительных внешних чипов обеспечить просыпание с периодом десятки минут или часов?
В SDK cpu_sleep_wakeup(DEEPSLEEP_MODE_RET_SRAM_LOW16K , PM_WAKEUP_TIMER, clock_time() + x*CLOCK_16M_SYS_TIMER_CLK_1S) имеет ограничение:
wakeup_tick - the time of short sleep, which means MCU can sleep for less than 5 minutes.
Но есть pm_long_sleep_wakeup()...
Фиг с лонгами, т.к. и 5 минут достаточно - за это время всё равно устройству что-то необходимо делать.
Но если надо больше, то без проблем можно перезарядить deep-sleep, т.к. на это уходит слишком мало энергии.
Пример: Перезарядка deep-sleep( Timer + Retention 16 KiB SRAM):
1605501553016.png
(500uA/200us клетка)
(1.82mA*0.5ms+2.7ma*0.9ms)/1.4ms = ~2.39 мА средних у фигулины в 1.4 ms
В режиме cpu_sleep_wakeup(DEEPSLEEP_MODE_RET_SRAM_LOW16K , PM_WAKEUP_TIMER, clock_time() + x*CLOCK_16M_SYS_TIMER_CLK_1S) TLRS8253 жрет около 1.87 мкА по тесту из SDK

Вышли из deep-sleep, проверили-уменьшили счетчик сколько ещё раз слипать и снова в deep-sleep, пока счетчик не обнулится.
Общая картинка из такого теста слепленного из 00_HelloWorld :):
1605502139600.png
Спать долго для теста нет смысла - 20 мс по 3 раза, потом вывод в UART "Hello World" (60-ая мс на графике) и снова на цикл спячки...
 

pvvx

Активный участник сообщества
инфо от pvvx: :)
Максимально корректируемая cpu_sleep_wakeup(DEEPSLEEP_MODE_RET_SRAM_LOW16K , PM_WAKEUP_TIMER, clock_time() + 8*CLOCK_16M_SYS_TIMER_CLK_1S) в Telink_825X_SDK составляет всего до 8 секунд. (8 включительно)
Далее счетчик вытягиваемый по clock_time() и прочие счетчики таймеров при просыпании не соответствуют, т.е. корректируются неверно (бага в либах SDK - наверно переполнение).
До 8 сек - всё пучком - время счета идет с точностью кварцев - их 2 внешних у чипов TLSR825x. Модули BT-0x имеют 2 кварца-стекляшки: 24МГц и 32768 Гц.
 

pvvx

Активный участник сообщества
Тест использования sleep только CPU для выяснения когда надо применять более глубокий сон...
Пример с помощью SAR-ADC считывает состояние внутреннего датчика температуры выводя примерно такую логу в UART:
20:43:18.430> ADC Temp: 0x0223 # 158 mv, run 237 us
20:43:18.620> ADC Temp: 0x021f # 157 mv, run 237 us
20:43:18.805> ADC Temp: 0x0222 # 158 mv, run 237 us
20:43:19.056> ADC Temp: 0x0226 # 159 mv, run 237 us
20:43:19.246> ADC Temp: 0x0223 # 158 mv, run 237 us
20:43:19.426> ADC Temp: 0x0221 # 158 mv, run 237 us
20:43:19.676> ADC Temp: 0x0221 # 158 mv, run 237 us
20:43:19.866> ADC Temp: 0x0221 # 158 mv, run 237 us
20:43:20.052> ADC Temp: 0x0221 # 158 mv, run 237 us

20:43:20.303> ADC Temp: 0x0221 # 158 mv, run 237 us
и делает cpu_stall_wakeup_by_timer0(200*CLOCK_SYS_CLOCK_1MS).
WaitMs() в SDK заменен на
_attribute_ram_code_ void pm_WaitMs(unsigned int ms) {
cpu_stall_wakeup_by_timer0(ms*CLOCK_SYS_CLOCK_1MS);
}
В итоге CPU не занимается никакими ожиданиями. Актуальность cpu_stall_wakeup_by_timer0(N мкс) сказывается от сотни мкс.
Но разница по току всего до 2-х раз - сам SoC при активности IC-cache, system timer и прочих необходимых для работы кусков жрет много (~1.4 мА).
Ток по 3.3V:
1605638284818.png
Т.е. в режиме останова CPU* имеем около 1.479..1.48 мА**, а среднее за представленное окно графика с почти 2-мя периодами - 1.4835 мА.
* Большинство встроенных устройств и их тактирование в SoC отключено, SWS и UART в примере не отключались.
** Третий знак зависит от температуры, влажности, стабильности питания и прочих факторов при замере. Шум по току неизбежен - в SoC работает встроенный импульсный DC-DC.

Далее уже просто рассчитать соотношение когда выгодно использовать уже deep-sleep c retention RAM и программным автоматом по стадийности ветвления при просыпании...
 

pvvx

Активный участник сообщества
Т.к. у меня нет никаких NDA с Telink и неизвестно есть ли у них замеры потребления по каждой части SoC в режиме активности, то пришлось это выяснить самому.
Часть инфы "засИкречу", на всякий пожарный и чтобы было неповадно :)
Но пару основных примеров дам, т.к. это часто забывают при проектировании ПО:
  • Включение ADC при штатных параметрах из SDK для замера питания = + 0.4 мА. Не забывайте включать питание ADC только на измерение.
  • Включение температурного датчика = + 0.44 мА.
  • Отключение только тактирования неиспользуемой периферии дает уменьшение ещё на 0.1..0.2 мА (если остальное уже ухожено).
  • Правильная настройка GPIO, т.е. избавление от висящих выводов и наводок, лишних подтяжек и прочей связанной лабуды может обеспечить уменьшение потребление и на более чем 3 мА! При старте и просыпании SoC его GPIO назначены на прием всего на свете и чем быстрее установите правильные настройки – тем меньше будет жрать и это значительно, т.к. обычный цикл активной работы нужной части программы в режимах BLE значительно менее времени инициализации SoC при просыпании.
 

pvvx

Активный участник сообщества
Но первое включение питания не радует:
Посмотреть вложение 10123
Тут atc1441 работать, работать и ещё раз работать! :)
Применение описанных основ, не меняя алгоритмов самого ПО:
Было:
1605642434896.png
Стало:
1605642439721.png
Да и размер firmware.bin сократился на дцать килобайт, плюс всё уложилось в 32 кбайта RAM...
 

nikolz

Well-known member
Применение описанных основ, не меняя алгоритмов самого ПО:
Было:
Стало:

Да и размер firmware.bin сократился на дцать килобайт, плюс всё уложилось в 32 кбайта RAM...
Благодарю.
Вчера получил термометры TLSR8253 .
Теперь можно издеваться над ними.
 
Сверху Снизу