-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Esp8266 at команды на русском
- Автор темы Victor
- Дата начала
pvvx
Активный участник сообщества
Зачем это всё, если текущие версии всех прошивок имеют десятки глобальных ошибок?
Побаловаться?
Ни на одной не организовать простейший WEBсервер или простой socket tcp/ip. Исправление будет длиться ещё годами. Китайцы же.
Замучился исправлять китайскую писанину – там сплошная бездарная “накидка” AT команд на чужой код. Работать будет, если передавать 10 байт в минуту и каждый раз перезагружать ES8266 с помощью снятия питания. Ножкой сброса выйдет не всегда.
Глобальный пример: отправка в буфер сокета блока в ATинтерфейсе (пусть AT+CIPSTART), да и в IoTдемо не контролируется, а “в нутре” делает так:
if (pcb -> sndbuf < length) { len = pcb -> sndbuf; } else { len = length; };
if (len > (2 * pcb->mss)) { len = 2 * pcb->mss; };
Т.е. обрезается по тому, что влезет, без предупреждения. В прошивке с ATразмер MSS = 1460 или 1448 байта (зависит от флага поддержки тимештампа в стеке ип…). Внутренний буфер “стека TCP” заполняется и держится занятым, пока принимающая сторона не подтвердит принятые блоки (ACK) и при интенсивной отправке и плохом соединении часто полон (там всего весь стек до около 5800 байт). А передается – пакетами, кусками… Движок стека (HTTP) приемной стороны, например GoogleХрома, подтверждает пакеты чрез очень большую задержку (несколько ms), в десятки раз большую, чем Internet Explorer (десятки us). В итоге передача выливается в тусовку по сотне байт и ожиданием ACK от Хрома. Предел скорости передачи выходит до 10 кбайт в сек при уверенном приеме по WiFi. По этой причине о WEB-HTTP - только мечтать, без основательного переписывания всей этой каши. Если исправить и дополнить скорость выходит за сотни кбайт/сек...
Номер “соединения” выдаваемый в AT прошивках при приеме и передаче данных может быть любой (в DemoIoTпроекте так-же). Это, если есть несколько соединений, то данные, запрошенные одним, передаются любому следующему, открывшему соединение в Demo IoT. А в AT прошивке путаются номера <id> — "идентификатор соединения". В текущей версии (9.2.2+) бывает более двух одинаковых номеров (+IPD)… Всего уже не припомню, так как уже переписал как надо мне и забыл (делал нормальный WEBс ajax + json + )….
Если ещё багов поперечислять – спрашивайте. Будет время и возможно вспомню. Но это бессмысленно – от перечисления ошибок рабочей версии у вас не будет, пока не дадут DDK. Плакали все Arduino+ ESP8266 и т.д....
Побаловаться?
Ни на одной не организовать простейший WEBсервер или простой socket tcp/ip. Исправление будет длиться ещё годами. Китайцы же.
Замучился исправлять китайскую писанину – там сплошная бездарная “накидка” AT команд на чужой код. Работать будет, если передавать 10 байт в минуту и каждый раз перезагружать ES8266 с помощью снятия питания. Ножкой сброса выйдет не всегда.
Глобальный пример: отправка в буфер сокета блока в ATинтерфейсе (пусть AT+CIPSTART), да и в IoTдемо не контролируется, а “в нутре” делает так:
if (pcb -> sndbuf < length) { len = pcb -> sndbuf; } else { len = length; };
if (len > (2 * pcb->mss)) { len = 2 * pcb->mss; };
Т.е. обрезается по тому, что влезет, без предупреждения. В прошивке с ATразмер MSS = 1460 или 1448 байта (зависит от флага поддержки тимештампа в стеке ип…). Внутренний буфер “стека TCP” заполняется и держится занятым, пока принимающая сторона не подтвердит принятые блоки (ACK) и при интенсивной отправке и плохом соединении часто полон (там всего весь стек до около 5800 байт). А передается – пакетами, кусками… Движок стека (HTTP) приемной стороны, например GoogleХрома, подтверждает пакеты чрез очень большую задержку (несколько ms), в десятки раз большую, чем Internet Explorer (десятки us). В итоге передача выливается в тусовку по сотне байт и ожиданием ACK от Хрома. Предел скорости передачи выходит до 10 кбайт в сек при уверенном приеме по WiFi. По этой причине о WEB-HTTP - только мечтать, без основательного переписывания всей этой каши. Если исправить и дополнить скорость выходит за сотни кбайт/сек...
Номер “соединения” выдаваемый в AT прошивках при приеме и передаче данных может быть любой (в DemoIoTпроекте так-же). Это, если есть несколько соединений, то данные, запрошенные одним, передаются любому следующему, открывшему соединение в Demo IoT. А в AT прошивке путаются номера <id> — "идентификатор соединения". В текущей версии (9.2.2+) бывает более двух одинаковых номеров (+IPD)… Всего уже не припомню, так как уже переписал как надо мне и забыл (делал нормальный WEBс ajax + json + )….
Если ещё багов поперечислять – спрашивайте. Будет время и возможно вспомню. Но это бессмысленно – от перечисления ошибок рабочей версии у вас не будет, пока не дадут DDK. Плакали все Arduino+ ESP8266 и т.д....
Ну, баловаться тоже интересно )
А если серьезно, то с вами согласен в той части, что глюков много. Готовых, стабильно работающих устройств, сейчас пока не сделать. Уйдут годы на исправление? Вряд ли. Да и надо ли развивать решение на AT командах? Возможно, что стандартом де-факто станет прошивка или nodemcu со встроенным интерпретатором lua, или франкенштейн от нашего соотечественника, или вообще какая-то другая, о которой мы пока не слышали. Обе прошивки развиваются прямо на глазах. Коммиты почти ежедневные. Так что может всего пара месяцев понадобится до выхода реально работающих решений. Так что я полон оптимизма!
А если серьезно, то с вами согласен в той части, что глюков много. Готовых, стабильно работающих устройств, сейчас пока не сделать. Уйдут годы на исправление? Вряд ли. Да и надо ли развивать решение на AT командах? Возможно, что стандартом де-факто станет прошивка или nodemcu со встроенным интерпретатором lua, или франкенштейн от нашего соотечественника, или вообще какая-то другая, о которой мы пока не слышали. Обе прошивки развиваются прямо на глазах. Коммиты почти ежедневные. Так что может всего пара месяцев понадобится до выхода реально работающих решений. Так что я полон оптимизма!
pvvx
Активный участник сообщества
Я вижу единственное позиционирование данного модуля как самостоятельного устройства с опросом датчиков или канала RS-232 TTL для других устройств.
В итоге управлять соединением модуля с сетью устройство не должно. Это задача самого модуля.
Для этого на модуле должен присутствовать полный интерфейс пользователя организованный на WEB сервисе и доступный с любого браузера. Должны задаваться адреса контакта – рабочий порт, в случае моста RS-232 или другие настройки и управление, в случае IoT.
Систему предоставления модулем моста RS-232 я и делаю. WEBстраницы организованы на подобии MPSF2 файловой системы от TCP-IP стека Микрочипа. Общий объем диска с файлами выходит за 200кБ частично сжатых данных (gzip). Имеется поддержка вывода и графиков пользователю – на swf или java, а данные модуль дает в xml. Основное ПО в модуль уже почти закончил и тестирую – устраняю последние глюки, связанные с кривостью драйверов. Нет ещё дизайна HTML страниц настройки модуля... Пришлось пользоваться дизассемблированными данными по драйверам модуля – исходников их нет. Без этого, как и писал, ничего дельного у народу с имеющимся SDK не выйдет. А такое, что у меня счас, выкладывать в общаг пока некорректно и не готов – это чистые хаки и не причесано... Требуется DDK.
Да, по поводу lua– это баловство, т.к. есть SDKи продвинутый пользователь может вписать что ему вздумается в ПО самого модуля.
В итоге управлять соединением модуля с сетью устройство не должно. Это задача самого модуля.
Для этого на модуле должен присутствовать полный интерфейс пользователя организованный на WEB сервисе и доступный с любого браузера. Должны задаваться адреса контакта – рабочий порт, в случае моста RS-232 или другие настройки и управление, в случае IoT.
Систему предоставления модулем моста RS-232 я и делаю. WEBстраницы организованы на подобии MPSF2 файловой системы от TCP-IP стека Микрочипа. Общий объем диска с файлами выходит за 200кБ частично сжатых данных (gzip). Имеется поддержка вывода и графиков пользователю – на swf или java, а данные модуль дает в xml. Основное ПО в модуль уже почти закончил и тестирую – устраняю последние глюки, связанные с кривостью драйверов. Нет ещё дизайна HTML страниц настройки модуля... Пришлось пользоваться дизассемблированными данными по драйверам модуля – исходников их нет. Без этого, как и писал, ничего дельного у народу с имеющимся SDK не выйдет. А такое, что у меня счас, выкладывать в общаг пока некорректно и не готов – это чистые хаки и не причесано... Требуется DDK.
Да, по поводу lua– это баловство, т.к. есть SDKи продвинутый пользователь может вписать что ему вздумается в ПО самого модуля.
Последнее редактирование:
pvvx
Активный участник сообщества
От темы топика отклонились совсем – AT команды нужны только для конфигурации соединения модуля в составе устройства, а создаваемый проект устраняет и замещает это дело полностью. Один я это долго буду делать до "кошерного" релиза 
Слишком много вариантов интерфейсов и их решений. Не известно, что приживется в народе. По тому и пишу – необходимо консолидироваться, а это не быстро.
Слишком много вариантов интерфейсов и их решений. Не известно, что приживется в народе. По тому и пишу – необходимо консолидироваться, а это не быстро.
Приживется то, что будет удобно и будет больше продвигаться. Подробная документация, туториалы, примеры и прочее, причем разного уровня: как для профессионалов, так и для любителей.
Ну и, почти в тему нашей дискуссии, в подтверждение моих слов о том, что потребуется немного времени, espressif сегодня выпустила SDK 9.3
pvvx
Активный участник сообщества
Потестил - старые глюки не исправили, новые наделали. Теперь виснет совсем глухо - что-то в tcp_disconnect ... это не совсем точно, но предпосылки есть.
Как сменить выдаваемую мощность передатчика? Надо понизить - на близком расстоянии от станции (ASUS RT-N56) вроде глушит и прием не уверенный. На других - с похуже антеннами, работает. Сильно не копал, но параметра изменения мощности передатчика пока не нашел.
Последнее редактирование:
pvvx
Активный участник сообщества
Но ничего не исправили. Для выяснения влезут или нет данные в передачу по espconn_sent(...) приходится делать так (см. вложение).
Иначе, в текущей реализации прошивок и SDK, данные обрежутся или просто “скипнутся” и не передадутся (см. файл в примере IoT espconn_tcp.c: espconn_tcp_sent() строка. 158…)
Да, и патч esp_iot_sdk_v0.9.3_14_11_21_patch1.zip никак не коснулся прошивки AT. Компиляция с новой libpp.a не меняет ни байта в выходных фалах. Касается только Demo IoT - там номерки версии библиотеки новее и всё
А PHY Mode уже задействовал - в выложенном видео по HTTP+MPFS уже в отладке (через UDP) читается (выводит в RS строку) и устанавливается...
Иначе, в текущей реализации прошивок и SDK, данные обрежутся или просто “скипнутся” и не передадутся (см. файл в примере IoT espconn_tcp.c: espconn_tcp_sent() строка. 158…)
Да, и патч esp_iot_sdk_v0.9.3_14_11_21_patch1.zip никак не коснулся прошивки AT. Компиляция с новой libpp.a не меняет ни байта в выходных фалах. Касается только Demo IoT - там номерки версии библиотеки новее и всё
А PHY Mode уже задействовал - в выложенном видео по HTTP+MPFS уже в отладке (через UDP) читается (выводит в RS строку) и устанавливается...
Последнее редактирование:
Может пока лучше обходится вообще без сервера на ESP8266, а использовать сторонний сервис типа https://thingspeak.com, использовать его как прокладку. Это, конечно, добавит время реакции, но позволит обойти текущие проблемы. Это правда не очень подойдет для вашего проекта, а для других может стать вполне реальным компромиссом.
pvvx
Активный участник сообщества
Для России не покатит. У нас не везде Инет по WiFi - территория бооольшая и не покрыта инетом...
Работает уже всё. Осталось малость - выловить потери линковки к соединениям. Там смешно работает калбака от espconn_regist_reconcb...
Потом причесать всё (это самое долгое) и можно будет выложить с исходниками...
Как пример, для чего это всё нужно:
Сделал Петя регулируемый БП, а на управление TFTпанель ставить лень и накладно. Подсоединил к данному модулю по RS-232 и зашли на его APс любого устройства, да сказал какой порт будет управлять из вне. В любой яве или любом языке открыть сокет для передачи данных очень просто, тем более закатать панель управления с swf или простым НТМLпрямо в модуль, который будет грузиться на любое устройство…
Iotу нас ещё не прорастет. Поиск по русскоязычному инету дает пару ссылок на перевод статей многолетней давности и переводы пары новостей про серверы от Интел
Работает уже всё. Осталось малость - выловить потери линковки к соединениям. Там смешно работает калбака от espconn_regist_reconcb...
Потом причесать всё (это самое долгое) и можно будет выложить с исходниками...
Как пример, для чего это всё нужно:
Сделал Петя регулируемый БП, а на управление TFTпанель ставить лень и накладно. Подсоединил к данному модулю по RS-232 и зашли на его APс любого устройства, да сказал какой порт будет управлять из вне. В любой яве или любом языке открыть сокет для передачи данных очень просто, тем более закатать панель управления с swf или простым НТМLпрямо в модуль, который будет грузиться на любое устройство…
Iotу нас ещё не прорастет. Поиск по русскоязычному инету дает пару ссылок на перевод статей многолетней давности и переводы пары новостей про серверы от Интел
Последнее редактирование:
pvvx
Активный участник сообщества
Как, оптимизм ещё не отпал?
Ну “тогда мы идем к вам”, с новой баго-фичей. Её китайцы быстро не исправят и она сидит во всех прошивках и SDK. Прошлые бяки уже описал, теперь следующая, очень хорошая баго-фича.
Назовем – пожирание Heapпамяти и отдача обратно по таймеру при работе стека TCP. Если таймер не успел, то 'malloc assert!' и перезагрузка. Подробное представление:
pvvx
Активный участник сообщества
Со стеком TCP в либе от Espressif немного разобрался. При открытии соединения, он отъедает память для сохранения информации по соединению и т.д., а при команде disconnectосвобождает её только через 60 сек (параметр TCP_MSL) по таймеру. Если за 60 сек было много соединений и приема-передач, то память заканчивается и происходит перезагрузка модуля. Во всем виновата логика в liblwip.a и писателей из Espressif… Данное безобразие устраняется сложно – или полным переписыванием всего, или несколькими дикими патчами …
Исходники для демоснтарции багов с простейшим веб-сервером https://yadi.sk/d/Va0ZNv6BcxYTk
Последнее редактирование:
pvvx
Активный участник сообщества
Получена суточная стабильность под нападками поисковиков и прочих запросов из всемирной паутины веб-http-сервера. Т.е. выловлены основные баги испоганенного lwip 1.4.0 китайцами и сделаны затычки. Можно приступать к причесыванию кода и оптимизациям.
По обещанию оглашения новой баги каждую неделю – есть такая. Выражается в несоответствии кол-ва обращений к callback-ам установленным по espconn_regist_xxx listen и закрытия соединений. Итог, в текущих прошивках, потеря привязок и нумерации открытых соединений. Очень актуально для AT прошивки. Выражается в том, что путается идентификатор соединения у ‘+IPD’...
По обещанию оглашения новой баги каждую неделю – есть такая. Выражается в несоответствии кол-ва обращений к callback-ам установленным по espconn_regist_xxx listen и закрытия соединений. Итог, в текущих прошивках, потеря привязок и нумерации открытых соединений. Очень актуально для AT прошивки. Выражается в том, что путается идентификатор соединения у ‘+IPD’...
А в AT v0.20 тоже присутствует?
Нужно давать команду или ATE0 или ATE1, а просто ATE, действительно не работает
pvvx
Активный участник сообщества
Это связано со стеком и кривой надстройкой в lwip 1.4.0. Если его не правили, а это SDK 0.9.3, то ошибка может проявится. Связано с вызовом fun_xxx установленной в espconn_regist_reconcb(pesp_conn, fun_xxx); Возникает при ошибках приема/передачи... Например вызывается с кодом ошибки -11 ("Not connected"), а соединение удаляется - uart0_sendStr("Unlink\r\n"). Но это не точно - я тестирую с другим кодом и AT прошивку глубоко не копал, за ненадобностью. Кому это надо (?) - устанавливать соединение через AT команды, если это уже внешний MCU, то его можно поставить и посовременнее и он полностью сделает и стек TCP и всё остальное гораздо лучше встроенного в ESP8266 и с меньшим потреблением...
Начал оптимизацию WEBсервера на скорость. Пока выходит поток в 500 килобайт в секунду…
Глянул новую прошивку AT(020) – похоже там линкована другая, перекомпилированная, либа lwip-а. Я прикладываемой к SDKliblwip.a теперь не пользуюсь, т.к. изменил и исправил под себя. Её исходные коды даны в ‘IoT_Demo’… компилируйте на здоровье, но поправьте хотя-бы espconn_tcp_disconnect_successful(). Там никакого ‘закрытия’ нет, а есть бросание на произвол (на 60 сек) открытой TCPструктуры соединения.
Последнее редактирование: