BLE модуль JDY-10 на чипе TLSR8266

[pvvx]

Во как сметили ноль, чтобы вписаться в заявленные параметры

+++ booster

 

[pvvx]

Кто может подсказать, т.е. дать ссылки на исходники дров к UPS в Windows?
Хочу выкинуть соединение по USB и заменить на BLE. Тогда все устройства смогут получать сообщения о скором отключении (кончине заряда) и прочие данные с UPS.
Почему этого не сделали производители UPS (не вставили чип за $1) неизвестно.

 

[Kabron]

Почему этого не сделали производители UPS (не вставили чип за $1) неизвестно.

Потому что BLE в Винде в рудиментарном состоянии.

 

[pvvx]

Потому что BLE в Винде в рудиментарном состоянии.

Мышки и клавы давно пашут без проблем. USB затычку воткнул и псё.
Накалякать профиль UPS на USB в JDY-10 недолго. Надо только уточнить что в энтом профиле HID точно надо и какие цифирьки куда кидать... Не лазал пока в эту тему - UPS.
А снимать логи по USB с работающего нет желания...

 

[Kabron]

Впрочем, есть интересная темка:

Owon B41T+ BLE Client for Windows 10 - No Dongle Needed! - Page 1

Owon B41T+ BLE Client for Windows 10 - No Dongle Needed! - Page 1

www.eevblog.com

я с чуваком пообщался

GitHub - jtcash/OwonB41T: A Windows Bluetooth(BLE) client for the Owon B41T+ multimeter. Any BLE adaptor is compatible, so no dongle needed!

A Windows Bluetooth(BLE) client for the Owon B41T+ multimeter. Any BLE adaptor is compatible, so no dongle needed! - jtcash/OwonB41T

github.com

 

[GermanIvanov]

Накалякать профиль UPS на USB в JDY-10 недолго.

А профиль обновления прошивки через Ble?
А то разъем для перепрошивки не позволяет делать устройство максимально герметичным... да и вообще дофига лишнего монтажа для вывода на cp2102, в небольших девайсах эт может быть критично.

 

[pvvx]

А профиль обновления прошивки через Ble?
А то разъем для перепрошивки не позволяет делать устройство максимально герметичным... да и вообще дофига лишнего монтажа для вывода на cp2102, в небольших девайсах эт может быть критично.

OTA в SDK есть и включается опцией в *.h проекта...

 

[GermanIvanov]

Сенкс поковыряю. а то как то некудряво получилось в прототипе.


Размер девайса и объем аккумулятора определяется размерами найденных в закромах акка и корпуса (батарейка от Cannon)

ps: Я правильно предпложиил что ldo-шка встроенная в акселлерометр прокормит еще и JDY-10?

 

[pvvx]

ps: Я правильно предпложиил что ldo-шка встроенная в акселлерометр прокормит еще и JDY-10?

Если она тянет 50 мА и дельту от АКБ 4.2-3.3, то это примерно максимальный ток и нагрев при работе на USB и прочего.

 

[mikolainer]

Привет форумчанам! хочу разобраться с BLE. Есть трудности с перепрошивкой TLSR8266.
что делал:
1) купил модули здесь
2) установил Telink IDE, скачал их SDK V3.3.0, на телефон поставил нордиковский BLE сканнер
3) поставил BDT и TlsrTools
4) считал FLASH. (по USB и через STMку с помощью TlsrTools). полностью совпадает с JDY-10-V2.5, а неиспользуемое место заполнено FFFFFFFF....
5) написал blink (архив проекта, архив папки в которую собрался), прошил
6) светодиодик то радостно замигал, а вот по USB камушек признаки жизни подавать перестал, а TlsrTool говорит что всё ок, типа я твою FLASH перепрошил, но фактически программа остаётся прежней, а при попытке чтения притворяется что она заполнена нулями.
7) Подумал что надо было что-то в коде прописать, чтобы сохранить доступ к памяти. Купил новый камушек. Собрал slave пример module из SDK. Зашил. В BLE сканнере вижу "tModule", но память снова больше не меняется и притворяется что заполнена нулями. Но теперь там точно не нули т.к. при перезагрузке я снова вижу "tModule" сканнером.
8) Подумал что что-то не так с TlsrTool. Попробовал подёргать GPIO порт напрямую через TlsrTool и светодиодик таки мигает (хоть и очень тускло).
таки вопрос к знающим: что я делаю не так? как достучаться до памяти после первой перепрошивки? как-то неинтересно с "одноразовыми" модулями...

 

[pvvx]

но фактически программа остаётся прежней, а при попытке чтения притворяется что она заполнена нулями.

"притворяется" - это что такое?
Соедините всё правильно, как указано на рисунке в репо
Первое действие после включения программатора к чипу всегда "Activate".

 

[pvvx]

mikolainer - В int main (void) выполняется gpio_init() и ваш код

void user_init (void){
    gpio_set_func (LEDpin, AS_GPIO);
    gpio_set_input_en (LEDpin, 0);
    gpio_set_output_en (LEDpin, 1);
    gpio_set_data_strength (LEDpin, 1);
    gpio_write (LEDpin, 1);
}

не нужен. Он устанавливает все выводы чипа в соответствие с "gpio_default_826x.h"
Т.е. описывается по другому, в "app_config.h" по типу:

#define    PC0_FUNC                            AS_GPIO
#define PC0_INPUT_ENABLE                    0
#define    PC0_OUTPUT_ENABLE                    1
#define    PC0_DATA_OUT                        1
#define PC0_DATA_STRENGTH    1
#define PULL_WAKEUP_SRC_PC0    0

 

[pvvx]

TLSR8266 по всяким sleep отключает Flash и схему работы с ней. Включить её можно только путем передергивания питания у чипа, т.к. документация как это сделать программно по SWS отсутствует.
Чтобы не плясать с бубном при отладке таких проектов документация гласит использовать:
#if(__TL_LIB_8266__ || MCU_CORE_TYPE == MCU_CORE_8266)
blc_pm_disableFlashShutdown_when_suspend();
#endif
TlsrTools может работать с такими отключениями Flash если питание чипа дать от STM32 c вывода "B0" и перевести этот вывод в "push-pull".

 

[pvvx]

Для других чипов TLSR826x/825x и в других SDK такой фичи нет. Там работа с Flash восстанавливается при активации внутренних питаний CPU (режимов работы SoC) и подачи на Flash команды выхода из sleep.
На TLSR8266 восстановление работы Flash после отработки функций sleep в SDK - засИкречено - требует множество доп. действий с регистрами чипа. Т.е. возможно только при использовании стартовых процедур из SDK и правильной последовательности выполнения. Вывод RST во время выполнения sleep у TLSR8266 не отрабатывает полностью - если использовать RST во время сна то чип не всегда запускается...
Для программирования проще скинуть питание чипа при старте "Активации", как указано в прошлом сообщении.
@mikolainer Вы сами загоняете чип в это состояние в своей программе, которая далека от реальных вариантов использования. Ваш код в main_loop() останавливает работу BLE, т.к. не выполняется ble_loop()
Т.е. в main_loop() не должно быть длительных процедур. BLE в данных SDK не работает по прерываниям.
GPIO сбрасывают состояние при засыпании SoC, а работать остаются только аппаратные притяжки и то, что вы задали работать - таймеры и контролер прерываний.
А если вы используете чип без BLE - тогда зачем у вас вся его инициализация?
Естественно светодиод от gpio_write(LEDpin, 1) не будет работать пока чип спит с отключенным контроллером GPIO.
Так-же в режиме BLE переход к sleep отрабатывается в ble_loop(), а не в пользовательском коде. Задаются флаги и PM сама решает когда чипу спать и на сколько в зависимости от арбитража BLE...
В итоге ваш код - это какая-то каша с непонятным функционалом и построен "вопреки" алгоритмам предназначения данного SDK.

 

[mikolainer]

@pvvx спасибо за ответ!

"притворяется" - это что такое?

я имел ввиду что TlsrTools ведёт себя как будто считывает память, но если её открыть hexEditor'om то видно что он считал просто нули.
соединено всё верно. SRAM слушается. при ошибке подключения вылазит ошибка подбора скоростей или ошибка чтения.

не нужен. Он устанавливает все выводы чипа в соответствие с "gpio_default_826x.h"
Т.е. описывается по другому, в "app_config.h"

верно, но это не ошибка. в документации написано что можно прописать дефайнами в app_config.h, а также в user_init() или комбинировать эти методы.

которая далека от реальных вариантов использования.

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

TLSR8266 по всяким sleep отключает Flash и схему работы с ней.

этого я не видел и это проясняет ситуацию. большое спасибо!

А если вы используете чип без BLE - тогда зачем у вас вся его инициализация?

я просто писал то, что рекомендуют в документации ещё не вполне разобрался с принципом построения приложений для этой железяки.

Чтобы не плясать с бубном при отладке таких проектов документация гласит использовать:
#if(__TL_LIB_8266__ || MCU_CORE_TYPE == MCU_CORE_8266)
blc_pm_disableFlashShutdown_when_suspend();
#endif

попробую это и то, что вы писали в одном из более ранних сообщений (только сейчас на него наткнулся) для чипов с уже отключенной памятью.

 

[pvvx]

ещё не вполне разобрался с принципом построения приложений для этой железяки.

Там понимать нечего:
CPU слабый и тормозной, т.к. работает от SPI Flash с малой "кэш". По этому код, который требует быстрой обработки помещается в RAM, чем уменьшает её объем для данных.
Вектор прерывания всего один и в нем последовательно по флагам разгребается кто вызвал прерывание, на что тратятся драгоценное время = потребление и скорость обработки.
RTOS там нет, как и нет "красивостей" - код пишется для процессора, а не для понятия его "домохозяйкой" или увлеченными в типовые и шаблонные подходы как в Arduino.
Стандартизаторам - кентам с шаблонным типовым мышлением там делать нечего. Их вариант все должны ходить парами по кругу с флагом и тупить не прокатит

 

[pvvx]

Для любых BLE код не строится по классическим схемам.

RTOS в принципе не годится, т.к. чип должен спать и не считать какие-то тики и какой поток сейчас ему запустить... Любое “пробуждение” и засыпание CPU и контроллеров требует дополнительной энергии. По этому в приоритете только пробуждения по арбитражу для обслуживания BLE, а не таймера тиков распределения задач в RTOS. И, следовательно, все ваши процессы должны быть синхронны с арбитражем BLE. Т.е. не вызывать пробуждений просто так, а использовать интервалы обслуживания BLE и привязываться к ним.

В итоге система строиться и не по принципу работы по событиям, а как программный автомат, отрабатывающий по тикам пробуждений для обслуживания BLE и флагам.

nRF52 SDK так не умеет и постоянно жрет лишнее питание на обслуживание всяких системных таймеров, callback-ов и прочей фигни, которые нафиг не сдались для работы BLE или ZigBee.

 

[pvvx]

Система BLE работает примерно так:
1. Пробуждение. Чип включает питания и производит инициализацию своих частей. Бывает разного типа - первое или повторное пробуждение. Т.е. надо ли инициализировать всё с нуля или нет.
2. Вызывается процедура sdk, которая определяет, что там следующее по RF части и её арбитражу, отрабатывает RF процедуры.
3. Однократно вызывает ваш код main_loop() который совсем не Loop. Ему предоставлены все состояния текущего RF обмена. В main_loop() вы должны быстро отработать текущую задачу и подготовить ответ для RF (если требуется) и указать – далее спать или нет для отработки вашей задачи.
4. Опять вызывается процедура sdk, которая настраивает таймер на следующее просыпание согласно арбитражу BLE. Если разрешено спать, тогда в ней всё, кроме таймера пробуждения и назначенных прерываний отключается. Иначе опять вызовет ваш код main_loop(). И так по кругу.

У чипа TLSR8266 старая система и он не умеет делать deep-sleep без отключения RAM. По этому используется не полный сон. Т.е. он устаревший и тем более у него короткий буфер RF = BT4.0, а не BT4.2 c от 256 полезных байт PDU данных... TLSR8269 уже BT4.2 (т.е. аппаратно совместим и с BT5.2, без неких специфических фич, которых у пользователей пока нет).

 

[mikolainer]

код, который требует быстрой обработки помещается в RAM, чем уменьшает её объем для данных.

система строиться и не по принципу работы по событиям, а как программный автомат, отрабатывающий по тикам пробуждений для обслуживания BLE и флагам.

это я уже понял из документации


вот и разбираюсь как именно это делать... но чтобы понять как сделать что-то правильно надо сначала научиться делать хоть что-то рабочее.

 

[pvvx]

Пример потребления nRF52 Видно что SoC только и занят отработкой тиков таймера для обслуживания системы созданной для восприятия кода домохозяйками, а не реальной работы.
А это TLSR825x. Лишних пробуждений и действий нет. В итоге только из-за этого чип с более худшими характеристиками по энергопотреблению потребляет меньше и с меньшими аппаратными ресурсами выполняет больше задач.
При этом и создание приложения на TLSR требует меньше специфических знаний по примененному SDK и соответственно времени на разработку.