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

[nikolz]

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

потому, что это экспериментальные чипы и никто с ними серьезно, кроме Вас не экспериментирует (шутка).

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

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

 

[pvvx]

На всякий случай "AN_19011501-C5_Telink Kite BLE SDK Developer Handbook.pdf" кинул тут

AN_19011501-C5_Telink Kite BLE SDK Developer Handbook.pdf

Посмотреть и скачать с Яндекс Диска

yadi.sk

Там подробнее о разметках SRAM, FLASH, boot, OTA и т.д.

потому, что это экспериментальные чипы и никто с ними серьезно, кроме Вас не экспериментирует (шутка).

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

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

Это к чему приложить?

 

[pvvx]

Из той доки следует, что 'normal stack', да и размер SRAM у чипов отличается:

А Ai-Thinker во всех своих проделках TB-01..04 на TLSR8253 считает, что размер SRAM 64 килобайта и типа что чип TLSR8258, а не TLSR8253 - не верьте своим глазам

 

[pvvx]

对于功耗调试正确的应用程序（硬件电路和软件的功耗调试都正确），最终 (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 мкА:


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

 

[pvvx]

Каково среднее потребление у прошивки из https://esp8266.ru/forum/threads/tlsr8251-lcd-termometr-lywsd03mmc-xiaomi-bluetooth-termometr.5263/ при default (ADV time cycle 1887 мс, TX +4дБ)

Среднее только по чипу TLSR8253 = 0.0130 мА = 13 мкА.

 

[pvvx]

Но первое включение питания не радует:

Тут atc1441 работать, работать и ещё раз работать!
Примерное поведение при соединении (connect):

Соединение примерно на 4-ой секунде, далее обмен с мастером, чтение атрибутов и переход к коннект time 1 сек...
За период на графике среднее составляет 65 мкА,
в период между 4 и 5 сек при простом sleep и коротком цикле коннект time - полка на уровне 60..75 мкА.

 

[pvvx]

Но первое включение питания не радует:
Посмотреть вложение 10123
Тут atc1441 работать, работать и ещё раз работать!

Ага - в init_lcd() стоит sleep_us(50000), в show_atc_mac sleep_ms(1800 + 200 + 1800 + 200 + 1800) (=5800 ms) вместо сна на это время...

 

[nikolz]

Ага - в 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]

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):

(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 :

Спать долго для теста нет смысла - 20 мс по 3 раза, потом вывод в UART "Hello World" (60-ая мс на графике) и снова на цикл спячки...

 

[nikolz]

инфо от TI:

 

[pvvx]

инфо от TI:

инфо от 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:

Т.е. в режиме останова 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 работать, работать и ещё раз работать!

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

Стало:

Да и размер firmware.bin сократился на дцать килобайт, плюс всё уложилось в 32 кбайта RAM...

GitHub - pvvx/ATC_MiThermometer: Custom firmware for the Xiaomi Thermometers and Telink Flasher

Custom firmware for the Xiaomi Thermometers and Telink Flasher - GitHub - pvvx/ATC_MiThermometer: Custom firmware for the Xiaomi Thermometers and Telink Flasher

github.com

 

[nikolz]

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

Да и размер firmware.bin сократился на дцать килобайт, плюс всё уложилось в 32 кбайта RAM...

GitHub - pvvx/ATC_MiThermometer: Custom firmware for the Xiaomi Thermometers and Telink Flasher

Custom firmware for the Xiaomi Thermometers and Telink Flasher - GitHub - pvvx/ATC_MiThermometer: Custom firmware for the Xiaomi Thermometers and Telink Flasher

github.com

Благодарю.
Вчера получил термометры TLSR8253 .
Теперь можно издеваться над ними.

 

[pvvx]

Благодарю.
Вчера получил термометры TLSR8253 .
Теперь можно издеваться над ними.

Added ComSwireReader for TLSR825x chips
Есть и читалка Flash использующая bin-loader от TlsrTools825x но пока не в паблике...

 

[nikolz]

Added ComSwireReader for TLSR825x chips
Есть и читалка Flash использующая bin-loader от TlsrTools825x но пока не в паблике...

вчера прислали новую версию BDT.
Хотел выложить здесь, но форум пишет ,что файл слишком большой.