Прошивка TCP2UART переходника с настройкой по Web

pvvx

Активный участник сообщества
Народ, подскажите пожалуйста.
Я собрал проект TCP2UART переходника в eclipse, прошил модуль, в целом всё работает, но не смог разобраться с выводом отладочной информации по UART. На сколько я понял вывод осуществляется через GPIO2?
Но я не смог разобраться в каком файле производится настройка данного модуля UART и на какой скорости ведётся передача? Также где можно включить/отключить вывод отладочной информации?
Было бы не плохо если бы кто нибудь сделал FAQ по структуре файлов данного проекта, думаю это многим было бы полезно.
"вывод отладочной информации по UART" производится процедурой printf() и подобными (os_sprintf(), os_sprintf_plus(), ets_sprintf(), ... относятся к закрытой части китайского-SDK, а в проекте используют только часть - см. esp8266web/os_printf.c at master · pvvx/esp8266web · GitHub )
Настройка скорости вывода отладочной информации на UART производится в меню System Setup Web-сервера.
Названа как "Debug UART".
 

Pavel_x

New member
@pvvx, большое спасибо!
Я поменял в указанном файле UART1_DEFBAUD на значение 115200 и у меня в терминал выводится мусор, но после установки скорости 115200 в меню System Setup Web-сервера, отладочная информация стала выводится корректно.
Не подскажете с чем это может быть связанно?
 

pvvx

Активный участник сообщества
Я поменял в указанном файле UART1_DEFBAUD на значение 115200 и у меня в терминал выводится мусор, но после установки скорости 115200 в меню System Setup Web-сервера, отладочная информация стала выводится корректно.
Не подскажете с чем это может быть связанно?
На ESP8266 первые сообщения при старте идут из его ROM на скорости 78800 baud и это не поменять. Далее стартует SDK, в моем проекте MinEspSDK (meSDK). Там можно поменять скорости вывода его сообщений или вообще отключить, а далее уже само приложение... esp8266web/sdk_config.h at master · pvvx/esp8266web · GitHub
MinEspSDK (meSDK) используется разных версий, т.е. его можно менять на разные версии, т.к. не все части китайского SDK "реверсированы" в СИ код, но содержат разные ошибки...
 

DimaO

New member
Добрый день.

Есть пара вопросов по режиму работы переходника в качестве клиента.

1. Client/Server IP там только IP или переваривает и имя хоста?

2. Возможна ли работа одновременно в режимах и клиент и сервер, в таком виде - что пришло из TCP неважно откуда - отправляем в UART, что пришло из UART - отправляем и клиенту и серверу?
С доработками прошивки естественно.

Спасибо.
 

pvvx

Активный участник сообщества
1. Client/Server IP там только IP или переваривает и имя хоста?
Только IP.
2. Возможна ли работа одновременно в режимах и клиент и сервер, в таком виде - что пришло из TCP неважно откуда - отправляем в UART, что пришло из UART - отправляем и клиенту и серверу?
Не предусматривалось - не было в этом нужды и сейчас не видно.
С доработками прошивки естественно.
Возьмите модуль поновее c большей RAM и на простых сокетах это решается в пару строк СИ/С++, включая Arduino. Т.е. кроме как ради “спортивного интереса” изгаляться в реализации описанных вами вопросах на ESP8266 нет смысла, т.к. выйдет себе дороже, дольше, усеченней и глючнее.
 
Последнее редактирование:

DimaO

New member
Это просто было не нужно, или там какие-то ограничения есть для использования имени хоста, а не адреса?
Не предусматривалось - не было в этом нужды и сейчас не видно.
У меня тоже в таком нужды не было, пока не оказалось, что не везде и не всегда есть белые IP, и проще попасть наружу, чем вовнутрь.
Возьмите модуль поновее c большей RAM и на простых сокетах это решается в пару строк СИ/С++, включая Arduino. Т.е. кроме как ради “спортивного интереса” изгаляться в реализации описанных вами вопросах на ESP8266 нет смысла, т.к. выйдет себе дороже, дольше, усеченней и глючнее.
Да оно сейчас на этапе оценки общего объема переделок, и там такой ворох изменений, что проще ставить для поделок с ESP отдельный роутер и поднимать на нем VPN наружу.
 

pvvx

Активный участник сообщества
Это просто было не нужно, или там какие-то ограничения есть для использования имени хоста, а не адреса?
Надо допиливать и дописывать, а смысла в этом нет на ESP8266.
Да оно сейчас на этапе оценки общего объема переделок, и там такой ворох изменений, что проще ставить для поделок с ESP отдельный роутер и поднимать на нем VPN наружу.
Т.е. вы ещё надеетесь, что ESP8266 можно сделать что-то надежное в описанных рамках?
 

DimaO

New member
Т.е. вы ещё надеетесь, что ESP8266 можно сделать что-то надежное в описанных рамках?
У меня она именно в том виде, как и задумано - простой переходник TCP-UART с удобной веб-мордой. Не более.
Вся остальная часть - на отдельном МК, никаких Ардуин и лишнего кода внутри самой ЕСП.
Работает нормально, все устраивает.

Появился вопрос о чуть большей функциональности - решил поинтересоваться сложностями в будущей реализации.
 

aneox

Member
У меня пара устройств работает на этой прошивке, успешно, версия 0.5.9.
Все тестирования делались с MacOs и Андроида. Полет нормальный. Не считая того, что при передачи большого обьема в направлении уарт->тсп, пришлось вставить паузу 6мс каждый 1460 байт потока, для стабильной доставки всего потока. В направлении тсп -> уарт, не требуется. Меньше 6мс, пропадают байты, затупы. Ну да Бог с ним, и так хорошо.

Но вот добрался до iOs, так встерил проблему.
Если в уарт есп передавать пакет меньше 1460 байт, то он не доходит до тсп сокета очень часто. Иногда доходит, иногда нет. Ждал по 2-3 секунды и перезапрашивал пакет.
Потом стал добивать нулями кол-во до 1460 байт, вроде помогло, но костыль и охото обойтись без него.
Не могу утверждать на 100% что проявляется только на iOs, но на MacOs и Андроид кажется не замечал такое, если и бывает, то намного реже.
Может что-то посоветуете. Спасибо.
 

aneox

Member
к сожалению нет, девайсы в корпусах стоят на обьектах работают, простого доступа нет, надо снимать, останавливать работу. пока добивание нулями до 1460 спасает вроде как, не лезу. но на будущие проекты призадумался, tcp2uart на rtl от pvxv кажется не будет в ближайшее время, придется ковырять есп. подумал мож кто сталкивался уже с подобным

еще из наблюдений, если есп получил пакет и тут же на него ответил, то кажется реже бага проявляется. если же есп отвечает попозже, допустим через 2-3 секунды, то бага проявляется чаще.
 

pvvx

Активный участник сообщества
У меня пара устройств работает на этой прошивке, успешно, версия 0.5.9.
Все тестирования делались с MacOs и Андроида. Полет нормальный. Не считая того, что при передачи большого обьема в направлении уарт->тсп, пришлось вставить паузу 6мс каждый 1460 байт потока, для стабильной доставки всего потока.
Для этого есть сигналы RTS/CTS. WiFi имеет помехи и в WiFi сети работает множество устройств... Гарантии по времени доставки или большого буфера в RAM ESP8266 нет. Арбитраж сети (канала), кто и когда передает-принимает осуществляется в WiFi AP. Помехи, коллизии и пропуски beacon всегда есть и передать весь стек TCP за 6 ms (beacon по умолчанию и тот 100 ms) не имеет никакой гарантии.
В направлении тсп -> уарт, не требуется.
Там работает запрет приема по ограничению размера окна TCP стека. Если ваш код, на внешнем клиенте отсылает пакеты не по стандартам TCP и не сморит ничего, то это ваша беда, а не iOs или ещё какой оси... Драйвер стека TCP не угомониться пока не передаст все байты, но может послать вас, если вы в него пихаете ещё и у него кончился буфер (вернет флаг занятости и выкинет ваш блок данных в запросе передачи - у него тоже буфера не резиновые, если вы игнорируете что конечное устройство занято и прием у него временно закрыт).
 
Последнее редактирование:

aneox

Member
Если ваш код, на внешнем клиенте отсылает пакеты не по стандартам TCP и не сморит ничего, то это ваша беда, а не iOs или ещё какой оси...
Вы наверное не так поняли. Со стороны клиента отправка работает у меня вообще без сбоев, любого размера пакет.
Проблема со стороны уарта, когда я с уарта передаю на клиента. rts cts не использую..

Простой пример, я запрашиваю клиентом данные через есп тсп, запрос приходит в уарт целым.
МК формирует ответ, скажем 2500 байт и шлет его в уарт. Клиент получает только 1460 и все, остатка нет.
Я правильно понимаю, что при получении 1460 байт, есп дергает ногой RTS, мол занят, нужно ждать?
Тогда я попробую поискать свободный ноги на МК и хотябы софтово следить за RTS есп. Аппаратных RTS CTS к сожалению нет, эти ноги заняты под другое у МК.
 
Последнее редактирование:

pvvx

Активный участник сообщества
МК формирует ответ, скажем 2500 байт и шлет его в уарт. Клиент получает только 1460 и все, остатка нет.
Не может такого быть. Там буфер для более 2-х пакетов TCP, а это значит что и 3 килобайта сожрет за раз, если до этого всё передал.
Я правильно понимаю, что при получении 1460 байт, есп дергает ногой CTS, мол занят, нужно ждать?
Нет - когда нет места в буфере передачи в TCP то выставится RTS (запрос на отправку). Далее, после выставления сигнала RTS дается возможность запихать десяток байт, пока передающее в RX устройство сообразит и поймет что выставлен сигнал занятости. Ведь скорость передачи может быть и 10 Mbaud...

RTS/CTS - это смотря с какой стороны смотреть - внешнего устройства или модуля WiFi. Они соединяются крест-накрест RTS-CTS и CTS-RTS...

При передаче с модуля ESP так-же рассматривается и CTS. Если внешнее устройство занято, то в буфер модуля по TCP примется максимальный объем и закроется WIN окно TCP стека, что объявит передающему о невозможности приема больше. Когда буфер начнет сливаться в UART, то WIN окно TCP стека будет увеличиваться с нуля на кол-во освободившегося буфера, достигнув объявленного максимума в lwIP (буфер для передачи имеет большее значение). Размер WIN окна передается каждый раз при переговорах в TCP и передающий знает сколько он может послать за раз (не более указанного там размера). Это обеспечивает сам принцип TCP. "Детские" программы обычно это всё игнорируют и никогда не следят за ошибками из возвращаемых сетевых функций :) Передадут сразу Гегобайт дровам в стек TCP и думают, что ось справиться и не пошлет их, а обязана где-то это хранить по мере передачи через узкое горлышко UART в конце пути . :)
 
Последнее редактирование:

aneox

Member
Нет - когда нет места в буфере передачи в TCP то выставится RTS (запрос на отправку). Далее, после выставления сигнала RTS дается возможность запихать десяток байт, пока передающее в RX устройство сообразит и поймет что выставлен сигнал занятости.
понял, спасибо, буду пробовать
 

pvvx

Активный участник сообщества
понял, спасибо, буду пробовать
При более менее чистом эфире WiFi ESP8266 тянет практически линейный (редкие RTS/CTS) односторонний поток в 3 Mbit/s UART, при дуплексе к 1 Mbit/s в обе стороны. Более не хватает производительности CPU ESP8266 с работой без DMA с UART - будут частые RTS/CTS. Всё это без каких либо потерь данных.
Всё остальное, что обсуждается здесь - это кривость стороннего совта и глюки в китай-WiFi-SDK у самой ESP (которые невозможно исправить).
 
Последнее редактирование:
Сверху Снизу