Как это можно оценить? Пока только смотрю за коэффициентом пересчёта RC Clk в XTAL16. Он стабилен, в моем варианте RC Clk ниже на ~0.5%, питание 3.3В.Какая стабильность пересчета RC вышла в новых вариантах SDK?
Можно взять уход за сутки для версии работающей по типу THB2, т.е. дающей рекламу со средним периодом...Как это можно оценить? Пока только смотрю за коэффициентом пересчёта RC Clk в XTAL16. Он стабилен, в моем варианте RC Clk ниже на ~0.5%, питание 3.3В.
почему-то не потянуло. Батарейка дает нестабильное напряжение. После разной нагрузки напряжение в sleep восстанавливается по разному. Даже при малейшей разнице нагрузки. Там отношения более 1000 токов sleep и работы с TX. Естественно батарейка восстанавливает напряжение в sleep разное время после удара... И коэф. плавает.Судя по стабильности коэффициента, можно калибровку делать реже, раз в 10 циклов сна.
От какого-то внутреннего опорника скорее всего.Так же неизвестно от какого источника питается RC ген.
Можно попробовать запретить сон до получения первого пакета или таймаута. Но нужно иметь устройство в руках, чтобы точно убедиться, что причина в этом.pvvx написал(а):пользовали пишут что некоторые единичные варианты чипов не хотят работать (сказывается именно на начало BLE соединения - не соединяется)
wakeup_init1()
и wakeupProcess1()
у вас и в SDK3.1.3. Больших отличий не увидел. Из того, что бросилось в глаза. Вы закомментировали вызов hal_system_clock_change_process()
, но это просто заглушка, код будет вызываться, только если адрес записан в jump tablevoid hal_system_clock_change_process(void)
{
typedef void (*my_function)(void );
my_function pFunc = NULL;
pFunc = (my_function)(JUMP_FUNCTION(HAL_SYS_CLK_CHG_PROC));
if (pFunc != NULL)
pFunc();
}
Там вроде всё по мелочи, но в разных местах. В инициализация переменных и вообще использовании самих переменных пересчета частоты RC...Бегло пробежался по текстам сравнивая кодwakeup_init1()
иwakeupProcess1()
у вас и в SDK3.1.3. Больших отличий не увидел.
Это всё выкинуто, путем назначения CLK_16M_ONLY = 1И ещё у вас намного больше задержки в RC32K clock при просыпании - 50 и 15: patch.c line:5480
В SDK3.1.3 соответственно 15 и 5. Получается порядка 1.5мс дополнительно.
С этим трудно не согласиться.Чистка была только для CLK_16M. Остальное просто откинуто defined CLK_16M_ONLY и явно нерабочее.
Нафига в прошивке ветвления на несколько килобайт в критических местах, если другой CLK не используется?
В этом случае, весь код исполняется из RAM и все упирается в производительность. Если переключить Clk на 16М, то соединение перестает устанавливаться. PHY не успевает ответить на запрос.Дык производительность CPU в данном SoC зависит не от CLK CPU, а от CLK SPI к Flash.
Это плохо, т.к. при большей частоте увеличивается ток потребления, а время активности не сокращается из-за длительности RF транзакций и необходимых пауз. Но из-за увеличения тока более всего сказывается просадка батарейки на её внутреннем сопротивлении.Из-за большой задержки в аппаратном блоке PHY при тактовой 16 МГц не укладывается в этот интервал.
Попробую.Т.е. отладку надо делать через резистор в ~150 Ом от источника в 3.3В (?)
11:54:38: Ожидание соединения с TH05
11:54:40: Выбрано неверное устройтво!
11:54:40: Устройство отключено.