SDK 1.4.0 (18/09/2015)

pvvx

Активный участник сообщества
Периодическое пропадание AP модуля может происходить по этой же причине? Наблюдаю такую проблему, есть 3 модуля, на одном ESP-01 всё работает, а на другом ESP-01 и ещё одном ESP-07 нет, точка постоянно отваливается, но бывает что и долго работает.
При разных установках калибровок у меня на модулях вообще бардак. Сказать точно что будет нет возможности, т.к. возникает полная стихия у WiFi и куча китайских сообщений из его кода... По этому пока эти опции в esp_init_data_default.bin[114]=2 и т.д. не трогаю, а для быстрого коннекта через deep-sleep подходит только режим deep-sleep 1. В других полная неопределенность или очень долгое время инициализации...
 

pvvx

Активный участник сообщества
Очередная китайская багофича:
При переключении STATIONAP_MODE в STATION_MODE происходит WiFi event(6): EVENT_SOFTAPMODE_STADISCONNECTED
В нем кол-во подключенных клиентов = 0, но wifi_station_get_connect_status() = STATION_CONNECTING, а не STATION_GOT_IP (хотя соединение есть)!
И данное якобы отключение не сопровождается WiFi event(1): EVENT_STAMODE_DISCONNECTED и последующим WiFi event(3):EVENT_STAMODE_GOT_IP !
Чтобы узнать, что можно все UDP и TCP соединения отключить (для примера чтобы уснуть или перейти в энергосберегающий режим, т.к. нет соединения) требуется производить целое расследование - типа когда и после чего вдруг появляются кривые данные у разных китайских процедур... Espressif программеры = идиоты.
 
Последнее редактирование:

pvvx

Активный участник сообщества
При включении wifi_set_opmode(STATIONAP_MODE) и если не подключаться к внешней AP (wifi_station_set_auto_connect(false) и не давать wifi_station_connect(), или если она уже отсоединилась, или хотим соединится потом с другой, или дали wifi_station_disconnect())
то AP работает 10 секунд, потом не работает 10 секунд и т.д. в цикле!
В логе китайцы выводят:
chg_A3:0 -> поле этого AP работает 10 секунд до
chg_A3:-180 -> тут тайм-аут 10 сек и AP не работает
chg_A3:0 -> поле этого AP опять работает 10 секунд и т.д.
Код:
12:20:00.273> chg_A3:-180
12:20:10.570> chg_A3:0
12:20:20.868> chg_A3:-180
12:20:31.161> chg_A3:0
12:20:41.460> chg_A3:-180
12:20:51.755> chg_A3:0
12:21:02.052> chg_A3:-180
12:21:12.347> chg_A3:0
12:21:22.641> chg_A3:-180
12:21:32.940> chg_A3:0
12:21:43.235> chg_A3:-180
12:21:53.594> chg_A3:0
12:22:03.890> chg_A3:-180
12:22:14.186> chg_A3:0
12:22:29.597> chg_A3:-180
12:22:39.893> chg_A3:0
12:22:50.191> chg_A3:-180
12:23:00.486> chg_A3:0
12:23:10.844> chg_A3:-180
Год прошел, как китайцы отлаживают SDK! Espressif = шарашкина контора.
 
Последнее редактирование:

Tomahawk

New member
pvvx, причём у меня в версии 1.3.0 данный глюк работал более устойчивей, т.е. при пропадании внешней АР цикл пропаданий начинался не сразу, но когда-нибудь всё равно начинался. Вот я и думаю теперь: одно исправляют, другое калечат...
 

pvvx

Активный участник сообщества
pvvx, причём у меня в версии 1.3.0 данный глюк работал более устойчивей, т.е. при пропадании внешней АР цикл пропаданий начинался не сразу, но когда-нибудь всё равно начинался. Вот я и думаю теперь: одно исправляют, другое калечат...
Победил. Нашел обход, с помощью лазания в потроха структур закрытой части китай-SDK :mad: (скоро скину в web-свалке).
Прибавил понижение питание, а то когда ST модуля ищет свою AP, то жрет 75 mA. С паузой ReConnect time, задаваемой в Web-свалке теперь так:
PowerWebReConnect.gif
Режим wifi_fpm_sleep = LIGHT_SLEEP_T и wifi_opmode = NULL_MODE со счетом времени (wifi_fpm_do_sleep(time_us)) жрет 15.5mA на ESP-01
wifi_fpm_sleep = MODEM_SLEEP_T на 1 mA больше.
wifi_fpm_sleep = LIGHT_SLEEP_T без времени, с просыпанием по ногам где-то пару mA (не записал и забыл, потом...)
Но никакие sleep не работают, когда модуль в режиме AP или AP+ST.
И как итог - в режиме ST модуль жрет больше, если не подключен к AP, а ищет её. Равно вечные 75mA, если не применить кучу издевательств над китай-алго в SDK :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Вышел [SDK Patch] esp_iot_sdk_v1.4.1_15_10_27 ...
Исправления:
1. Некоторые устройства могут иметь проблемы подключения к ESP8266 softAP;
2. Проблема отправки UDP данные на несколько устройств.
Извините за неудобства.
Спасибо за ваш интерес в ESP8266!
dhcps_lease испоганена никчемным bool enable:
Код:
struct dhcps_lease {
    bool enable;
    struct ip_addr start_ip;
    struct ip_addr end_ip;
};
Но это уже тянется с их Open source LWIP for ESP_IOT_SDK_V1.4.0.
 
Последнее редактирование:

Vitaly

Member
не догнал, это типа чтоб можно было сделать ап, а адреса давать не будем, руками ставить будете?
 

pvvx

Активный участник сообщества
не догнал, это типа чтоб можно было сделать ап, а адреса давать не будем, руками ставить будете?
Это как и всё чисто китайское очень сложно понять. :(
Это флаг, что типа ip не заданы... и при старте AP "Лизу" установят по ip AP. Иначе проверят и если не понравиться, то изменят флаг и установят по ip AP.
В web-свалке это всё выкинуто (и переворачивание "Лизы" к верх ногами тоже) - иначе возникает неконтролируемый бардак.
Флаг был вынесен, раньше он жил сам по себе и если был изменен, то изменить "Лизу" было незя, да другие заморочки. Но этим выносом флага проблемы не решились, а только увеличились, т.к. менять "Лизу" у китайцев можно только в определенных сложно-запутанных условиях, т.е. совершив сотни никому ненужных переключений режимов WiFi :) Возник он по началу (историческая справка :) ) от того, что китайцам нравиться переворачивание "Лизы" к верх ногами.

Ошибку в system_deep_sleep_local_2 не убрали. После deep-sleep старт опять будет по exception :) Патч актуален.

Из главных блоков (без всяких espconn и т.д.) увеличились по размеру или bss:
wdev.o
esf_buf.o
ieee80211_hostap.o
ieee80211_scan.o
ieee80211_sta.o
if_hwctrl.o
pm_for_bcn_only_mode.o
pp.o
user_interface.o

Единственный pm.o - уменьшился на пару байт.
(итого: bss +240, iram -48, flash +192 байт)
 
Последнее редактирование:
Сверху Снизу