Баги и недосмотры в sdk от espressif

[pvvx]

Как доказательство

Ещё много надо написать, до первого релиза...

 

[clinkme]

Ну мне кажется, что web-сервер сам по-себе - тупиковая ветка,точно также как всякие франкенштейны, xboot-ы и т.п. Все это дело можно (и должно) использовать исключительно для конфигурирования, а сами полезности (управление реле, лампочками и т.д.) надо реализовывать в нативном коде.

 

[pvvx]

Ну мне кажется, что web-сервер сам по-себе - тупиковая ветка,точно также как всякие франкенштейны, xboot-ы и т.п. Все это дело можно (и должно) использовать исключительно для конфигурирования, а сами полезности (управление реле, лампочками и т.д.) надо реализовывать в нативном коде.

Web и делается для конфигурирования, передачи информации и управления датчиками. Любое устройство управления требует запись логов и статистики. Например любой ADC. Сервер и будет делать логирование и сборку статистики за год, к примеру с шагом в усредненных показаний за 30 минут и показ её в графическом виде. Предполагается логирование и сбор статистики с не менее 16 датчиков. А типы датчиков и прочее подключаются библиотеками, а не кодом. Примерно такие наброски только на одно направление, зачем нужен web Есть и другие варианты.
Для реализации любой задачи на esp8266 сначала требуется узнать и найти обходы ошибок SDK и DDK. Только после этого, зная как это всё работает, можно приступать к разработке алгоритма для реализации задачи. Иначе выйдет как уже вышло у многих - все вышедшие на сегодня реализации надстроек на ESP8266 имеют неисправимые алгоритмические ошибки.

 

[CHERTS]

Что-то в новом SDK v0.9.4 LWIP вообще сломали, событие discon_cb 1 раз вызывается и дальше ступор, даже событие connect_cb перестает работать, капец.

pvvx не смотрел что там намесили и как подправить?

P.S. Уже увидел правки на странице ранее, правда даже с ними раза 2-3 данные отправляются, а потом ступор.

 

[CHERTS]

C новой liblwip.a из SDKv0.9.4 перестал работать esphttpd, отображает пустые страницы, с 0.9.3 все нормально Ох уж эти китайцы.

 

[pvvx]

C новой liblwip.a из SDKv0.9.4 перестал работать esphttpd, отображает пустые страницы, с 0.9.3 все нормально Ох уж эти китайцы.

Я её не пользую и не тестировал новую espcon досконально. Но там добавили несколько переменных, описывающих каждый открытый сокет. Памяти для пользования стало меньше
typedef struct _comon_pkt{
void *pcb;
int remote_port;
uint8 remote_ip[4];
uint8 *ptrbuf;
uint16 cntr;
uint16 write_len;
uint16 write_total;
sint8 err;
uint32 timeout;
uint32 recv_check;
enum espconn_option espconn_opt; // =1 -> ESPCONN_REUSEADDR
os_timer_t ptimer;
}comon_pkt;
Введена переменная write_total общего счета переданных байт и с ней, возможно, имеются проблемы. Она влияет на вызов sent_cb.
Введен флаг espconn_opt. Он влияет на закрытие соединения - надвеска для уничтожения TIME_WAIT pcb, не вписывающаяся ни в какие стандарты tcp.
Больше вроде ничего и всё должно работать по старому, как в 0.9.3.
Автор httpd - безграмотный и его код не должен был работать нормально. Он работал, только за счет случайных стечений обстоятельств. Процедура sent успевала передать из заданного буфера в стеке (!) данные в pcb к WiFi и код процедуры передачи туда байт сложился такой, случайно, что добавлял Lwip-у новые данные в pcb при повторном вызове, т.к. какие-то отработки там ещё не завершились.

 

[pvvx]

Что-то в новом SDK v0.9.4 LWIP вообще сломали, событие discon_cb 1 раз вызывается и дальше ступор, даже событие connect_cb перестает работать, капец.
pvvx не смотрел что там намесили и как подправить?
P.S. Уже увидел правки на странице ранее, правда даже с ними раза 2-3 данные отправляются, а потом ступор.

Используйте recon_cb как discon_cb. Это аналогичные вызовы. Один происходит по закрытию соединения без ошибок, а второй, когда закрытие с ошибками. Ну не совсем с ошибками, а например когда соединение закрывается со стороны клиента. Это событие espconn не понимает (основная причина её зависаний по таймеру и лазанию в чужие соединения pcb) и в исправленной версии теперь сразу вызывает recon_cb c ошибкой -11 (потеря pcb, т.к. Lwip уже сам закрыл соединение и удалил pcb, выдав FIN+ACK. У них трактуется как #define ESPCONN_CONN -11 /* Not connected. */).
Проблема кроется в алгоритме работы espconn c Lwip. espconn, при открытии соединения запоминает указатель на pcb и дальше работает с ним, без проверки, а живо ли это соединение ещё. Ситуация, когда по данному указателю в Lwip находится новое соединение бывает часто. Нефиг самостоятельно лезть по указателю, не опросив главного - Lwip. Когда что-то надо, то Lwip вызывает сам назначенные процедуры (калбаки), с правильным указателем на pcb. Так что espconn не лечиться и все её навороты с ssl и т.д. в помойку. Патч будет превышать исходные процедуры и это не переноситься в мультизадачку... как и всё от Espressif Systems (Wuxi).

 

[pvvx]

Пока решение с lwip такое lwip_sdk094_v2.zip https://yadi.sk/d/oFDjOqrpdYYGG
Проверил с tcp - работает.
Удалил write_total
Тест на espconn:

Но надо учитывать все выше описанное...
Теперь конкретнее:
Было вставлено:
if (value && (pnode->pcommon.write_len == pnode->pcommon.write_total)){
espconn_tcp_sent(pnode, psent, length);
}else
return ESPCONN_ARG;
Т.е. пока прошлые данные не переданы, новых добавлять нельзя и надо проверять, что возвращает функция espconn_sent(...).
В приложенной версии патча - по старинке, как в 0.9.3, для тех кто не любит проверять что возвращают функции.
Для нормы используйте lwip_sdk094_v1.zip, выложенный ранее.

 

[CHERTS]

все равно фигня полная, что с lwip_sdk094_v1.zip, что с lwip_sdk094_v2.zip, 1-2 раза данные отправляются, потом пожизненный вызов recon_cb с ошибкой ESPCONN_CONN
может у меня конечно руки-крюки и я написал фигню
pvvx если есть желание, то вот http://rghost.ru/59916951 исходники с которыми я эксперементирую на предмет организации TCP клиента и отправки данных, там все просто, в user_config.h задаются все настройки, далее с периодичностью в N сек. на TCP-сервер отправляется строка, пару раз она отправляется, потом вечный recon_cb. Мне просто важно знать, что я не накосячил в коде.

 

[pvvx]

задаются все настройки, далее с периодичностью в N сек. на TCP-сервер отправляется строка, пару раз она отправляется, потом вечный recon_cb.

У меня ESP8266 с этим кодом не соединяется с базой. Надо глядеть...

 

[CHERTS]

У меня ESP8266 с этим кодом не соединяется с базой. Надо глядеть...

А там нет никакой базы, на ПК нужно запустить TCP-сервер и все, в user_config.h задать его адрес и порт.

 

[pvvx]

А там нет никакой базы, на ПК нужно запустить TCP-сервер и все, в user_config.h задать его адрес и порт.

Там в настройках WiFi задан режим подключения модуля к AP. Автоконнекта не задано и т.д....

 

[pvvx]

все равно фигня полная, что с lwip_sdk094_v1.zip, что с lwip_sdk094_v2.zip,

Они только для tcp сервера и то с натягом. Для tcp клиента исправить невозможно. Espconn не хранит данных, по которым можно узнать, с кем было соединение. Имеются только remote ip и port = 0, а желательно меть и локальный порт и ip, для получения указателя в lwip на есть или нет соединение. Допиленный на данный случай liblwip_cor.a v3 https://yadi.sk/d/euTtL5qUda4Bm , а то дети используют его для клиента. Вставлена проверка на remote ip | port == 0 - при этом оставляет espconn страдать самой.
Я больше не желаю заниматься редактирование каждой бяки от ... в espconn. Исходники даны, ошибка указана - кто понимает, тот сам...

 

[pvvx]

SHERTS: “залог "правильной работы" - это правильный настроенный wi-fi”

Наблюдаю такую зависимость у ESP8266:

При подключении к внешней AP, требуется обязательная настройка его AP на метод шифрования и т.д. (как у внешней AP, к которой подключаемся клиентом)?

Проверить все разнообразия не успел. Но, вроде, настройка внутренней AP инициализирует метод шифрования и протокол для подключения клиентом к другой AP.

 

[pvvx]

Собрал свои используемые поправки к SDK 0.9.4 в libs_sdk094_add_v1.zip https://yadi.sk/d/qWDPJVygdeTVt

 

[clinkme]

0.9.5b не смотрел? По крайней мере, мою ошибку с
wifi_station_get_connect_status() исправили.

 

[pvvx]

0.9.5b не смотрел? По крайней мере, мою ошибку с
wifi_station_get_connect_status() исправили.

Смотрел и дал им ещё. Там ещё много неописанных и не привязанных структур и enum. Скоро народная версия SDK будет круче, чем у Espressif.

 

[Victor]

Скоро народная версия SDK будет круче, чем у Espressif.

В настоящее время, видимо, это самый лучший выход из сложившейся ситуации.

 

[pvvx]

Очень затребованные процедуры для HTTP, дублирующиеся зачем-то многократно в либах SDK:
PROVIDE ( base64_decode = 0x40009648 );
PROVIDE ( base64_encode = 0x400094fc );
Не выходит у меня разобрать в БИОСЕ Неясны параметры вызова... Приходится использовать ещё дубли, а Flash не резиновая.
У Lua - нщиков уже давно проблемы - переносят раздувшиеся блоки кода поправками в ld...
Да и распределение RAM сделано криво. Его там, на чипе, можно выудить и скомпоновать получше. Но, Espressif не хочет сделать востребованным его продукт. Наверно есть перекупщик их, и он и задает/создает им падение стоимости путем кривых выпусков кода и нерабочих версий...
Время идет и кто другой уже скоро может выпустить нормальную версию чипа и SDK к нему. Тогда Espressif отойдет на задний план со своим ES8266EX Рекламу данной ниши для чипов Espressif уже оплатила - скоро будет гулять лесом и с убытками...

 

[pvvx]

Вроде все основные ошибки и как их обходить в SDK от Espressif на сегодня изучены. Можно приступать к написанию программ и портированию разных надстроек...
С Новым годом!