Результаты поиска

Файл в Flash в SPIFFS представляет из себя кусочки данных раскиданные по секторам. Если вы переписываете файл, хоть один бит в нем, то все кусочки будут переписаны в новое место, а старые объявлены как удаленные. При этом переписывается разметка описывающая где и что хранится. Бывают отличия...

У PHY есть hal_pwrmgr. Там назначаются калбаки: int hal_pwrmgr_register(MODULE_e mod, pwrmgr_Hdl_t sleepHandle, pwrmgr_Hdl_t wakeupHandle) Впишите на каждое внутренние устройство (включая GPIO) что ван нужно сделать при просыпании/засыпании. На SPI там вписано: static void...

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

Без осциллографа, PowerProfiler с высокой дискретностью замеров (менее 100 us) и прочих сканерах в BLE делать нечего и лучше вообще не лезть. Иначе не сможете оптимизировать потребление и все переходные этапы.

Пример: Внешнее устройство просыпается при активной “1” на SCL или SDA. Перед обращением к нему вы запрещаете переход в sleep и устанавливаете GPIO подтяжку к “1”. Настраиваете контроллер I2C (включая подачу на него внутреннего CLK). Через тайм-аут (если нужно), переключаете MIX и/или...

Возможно это просто не описано в их либах. В том-же TLSR десятки бит в регистрах по вкл/выкл CLK для каждой малой части контроллеров и плюс такая-же куча бит RESET этих кусочков чипа. Плюс ещё выбор источника тактирования для каждой фигнющки. Для ADC там более 5-ти блоков и для каждого...

У SPI (и прочих устройств) же есть: void hal_spi_init(void) int hal_spi_bus_init(hal_spi_t* spi_ptr,spi_Cfg_t cfg) int hal_spi_bus_deinit(hal_spi_t* spi_ptr) А как можно все состояния описать в документации? По регистрам есть disasm :)

Если чип умеет оставлять что-то активным, то ищите процедуру и флаги как это сделать. Но в таких чипах нужно каждый раз после просыпания инициализировать внутренности и перед засыпанием деинициализировать в состояние минимального потребления. Это принимается по умолчанию и могли даже не писать в...

Это везде так, во всех чипах BLE. Питание с большей части чипа снимается (часто включая и задающий генератор - кварц). Остаются только "подтяжки" на GPIO, но и их назначение для sleep могут отличатся от режима активности. А т.к. Cortex обычно имеет тупую периферию и дикий HAL, то это требует...

С UDP-шниками тут вообще смех и грех.

Ещё интересная ситуация с TCP_RTO_MIN для WiFi (забудем о ESP). Если оно равно 200 ms, то у WiFi период beacon по умолчанию 102.4 ms. Большинство “зеленых” алгоритмов работает по кол-ву пакетов. Например если за время периода паузы beacon проходит 1 или 2 пакета, то происходит переход к DTIM( n...

Узнавать версию не имеет никакого смысла. Если в другой версии что-то изменено, что прокатит в этой ситуации, то остальное всё равно не совместимо с IP и тем более TCP. Т.е. всё равно будут глюки и бардак в сети от ESP, т.к. у ESP не хватает ресурсов для выполнения базовых RFC в части IPv4 и тем...

Из сего вытекает, что не получен ACK по предыдущим пакетам в WIN в течение TCP_RTO_MIN. А отсылка ACK производится не самим сокетом, а драйвером TCP стека – в даyном случае LwIP. Но при опции WiFi Sleep “MODEM” или “LIGH_SLEEP” обращение к LwIP, т.е. передача ему управления для счета всяких...

У сокет TCP с SO_KEEPALIVE по умолчанию тайм-аут пауза вообще 2 часа. А по поводу TCP_RTO_MIN https://pracucci.com/linux-tcp-rto-min-max-and-tcp-retries2.html

В честь чего он шлет retransmission ? Пауза по ping в сетях IP определена как раз как 2*60 сек (2msl timeout) (и не случайно равна TIME_WAIT). Таймер 2MSL заставляет клиента ждать в течение времени, достаточного для потери ACK (один MSL) Скорее всего retransmission возник от непонимания что...

Но это ещё ладно (всякие MODEM/LIGHT_SLEEP), а главное то, что когда автомат будет отключать режим понижения потребления и всякие DTIM( n ) он не будет восстанавливать период отработки таймера для Lwip (стека обработки TCP/IP и т.д.).

Режим MODEM для WiFi обычно включен по умолчанию. Все интеллектуальные “зеленые” режимы работают по анализу кол-ва пакетов за время. У вас всего один запрос на период beacon (102.4 ms по умолчанию), что говорит о том, что режим энергосбережения будет включен. А если он включился, и тем более...

На время активной работы с сетью надо отключать это: https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf wifi_set_sleep_type(MODEM_SLEEP_T) wifi_set_sleep_type(LIGHT_SLEEP_T)

И третье гадание – Espressif вставили в Lwip увеличение периода таймера опроса состояния буферов и соединений. Не на много – в тысячи раз от рекомендованного :) Это включается во всех “энерго-понижалках” для увеличения глюков и у LwIP и системы возникают запоры, до reboot по WDT и типа. Вместо...

Ущё - как в пакет с MSS 536 байт влезет заголовок? Chrome офигеет. IE кидает запросы на канал для уточнения MSS и адаптирует заголовок HTTP под полученные данные. Но ESP не имеет такого сервиса :) Даже если всё правильно описали в части socket и принимают полный WIN, но он у вас 2144 байта :) В...