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

Извините, но я ког-да-то давно сам модифицировал эти протоколы для своих нужд.

А при чем тут протокол? Терминал то не полный = демо. Это раз. Во вторых он не умеет работать с COM портом. В третьих - он не умеет работать с TCP/IP. А главное в четвертом - но это я зажму - так веселее. Wireshark вам в помощь...
А в пятых - здесь не тема про глючные терминалы. Пишите свой и показывайте где ошибка. Исходники даны

 

Похвально

Виндошный гипертерминал и демо? С чего бы вдруг?

Кто не умеет? Гипертерминал? Винда? CP2104?

Гипер нативно с Winsock-етом работает. Не понял, чего он там не умеет.

Главное не пережмите, а то раздавится и потечет

И Вам не хворать...

Я Вам про Фому, а Вы мне про Ерему.
Наверное стоит лечь спать уже, утро вечера мудренее...

 

Откройте его Help и почитайте
HyperTerminal предназначен для простой в использовании инструмент, а не заменяет другие инструменты Full Feature, доступных на рынке.

Забыли ещё прокладку меду ними.

А на каком протоколе и с какими таймингами? Ещё раз - Wireshark в руки.
Может не нативно, а наивно?

Ну дык - повторю ещё раз - это не аппаратная эмуляция RS-232 со всеми сигналами и их синхронизацией, а просто потоковое устройство
Вам для начального обучения http://citforum.ru/nets/hard/tcptechnet/
В данном случае использовался протокол передачи Zmodem with Crash Recovery, передача данных прошла без разрыва соединения, но с ошибками при приеме.
И это при специализированном конвертере порта RS 232 и не с помощью глючного "терминала" для windows того века.
Вы так и не сказали, по чему данный терминал передает по одному байту в COM порт за +200ms и при этом обратного потока нет. А так-же каким образом он прерывает передачу файла сам, произвольно, при этом соединение не разрывается
Ещё изучите на досуге различия "синхронный и асинхронный поток".

 

Вы смешиваете понятия. Какое отношение имеет "Демо" продукт (как Вы изволили высказаться) к отмазкам мелкософта, почему они предлагают купить что-то взамен?

Ничего я не забыл.

...

...

Которое просто не выполняет с достаточной надежностью свои функции...

Прочитал, глупейшая с точки зрения раскрытия темы статья. Больше на такие не ссылайтесь, пожалуйста.

В каком в данном?

Конвертер порта - это электрическое устройство, выполняющее преобразование физических уровней для UART-а,
а "глючный терминал" - это ПО, для преобразования протоколов.
Будете продолжать сравнивать транзистор и кофейный напиток?

Я немного не пойму, либо Вы не читаете, либо мы не на одном и том-же языке разговариваем.

 

По тому, что данная программа не полная и она не мелкосовтовская и если занаете историю с ней, то поймете почему "demo"
>В каком в данном?
Это цитата из статьи.
>Я немного не пойму, либо Вы не читаете, либо мы не на одном и том-же языке разговариваем.
Ну не понимает ваш "терминал" как работать по TCP/IP, если соединение не принимает данные, если у него заполнен буфер. Для него это ошибка.
А про его работу с COM портом и говорить не о чем. Баг на баге.
По тому данный терминал работает только в идеальных условиях, достаточно далеких от реальных. И сделано это чтобы вы купили полную версию, а не использовали Demo.

>Которое просто не выполняет с достаточной надежностью свои функции...
Оно выполняет свои функции именно как TCP-UART из двух потоков туда-сюда, а не навязываемые ему вами, с поддержкой глючных терминалов использующих одновременно синхронно-асинхронные потоки по одному каналу и не умеющими работать с драйверами TCP/IP и последовательного порта.
Почему ваш "гипертерминал" передает в COM в пределе до 1000 байт в сек?
Вы предлагаете сделать специализированный проект - мост UART-ESP8266-ГиперТерминал из старой Windows?

 

ГДЕ??? скорость видна на скриншоте, о каких 1000 байт в секунду Вы говорите?

 

У меня так на Win7. Замеры приведены тут:
http://esp8266.ru/forum/threads/raz...logo-webservera-na-esp8266.56/page-3#post-748
Другие "терминалы" - каждый по своему. Указанный китайский не вставляет межсимвольную паузу, но не понимает закрытие окна приема по TCP и многое другое... У него очень прикльная зависимость поведения от межпакетной паузы в окошке и он любит перекодировать символы на китайский и обратно
Сделать спец прошивку под него?
Мне совсем не понятен ваш метод “тестирования” – берете какие-то кривые программы и тыкаете ими куда не попадя. Никто не оспаривает, что в программе TCP2UARTвозможны ошибки. Но приведите конкретно, где и какие, а не отсылайте к убогим программам, которые не работают и с промышленными устройствами аналогичного типа. А то пока один общий отсыл – типа у меня не пашет, а с моей любимой гармошкой пашет. Больше пока никакой информации вы не дали за последние несколько страниц…
Хотя-бы конкретизируйте место появления ошибок - когда заполнен буфер передачи (?) или приема (?) или при сливе буфера происходит какие-то потери или перестановки байт (?) или ?

В инете для луниха и винды есть несколько драйверов с удаленными COM портами по TCP. Но ни один из них не работает должным образом, хотя там задействованы спец. протоколы по TCP. И не путайте их – они всегда держат связь и переговариваются - пуст или забит буфер и т.д. Т.е. они имеют синхронный интерфейс с внутренним потоком данных и ВСЕГДА отвечают на запрос состояния и прочего – переговариваются на дополнительном протоколе. Тут нет такого – тут всё проще. Послал – передало, приняло – послало. Буфер передачи забит –> прием по TCP закрыт, а соединение не закрыто и передающий должен ждать, когда ему драйвер TCP скажет, что прием возобновлён, а не беситься, переполняя TCP стек у собственного драйвера и удивляться от куда у него ошибки . Проще уже некуда.

 

Вы давно туда заглядывали? Думаю, что давно.

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

Вы. Несколькими постами выше.

"бла, бла, бла... я здесь написал лучшую программу, а вы не можете всего-то зеркально ровный асфальт для нее организовать, предлагая разные убогие промышленные составы...", "бла бла бла", "бла бла бла"

Даже спорить нет желания. Оставайтесь при своем мнении.
Когда будете на 120% уверены в верности своего подхода, но чтото не будет работать - просто пересмотрите свое отношение к окружающему пространству.
За сим хочу откланяться, больше Ваше Величество не смею отвлекать. Удачи в достижении цели.

 

Они мне не нужны. В теплице помидоры...

Не собираюсь уподабливаться вам.
У меня всё проще и проблем нет. Если есть время пушу тест и проверяю:

Как видите всё Ok - ничего не потерялось и всё передано туда и сюда изумительно. Могу и видео выложить...
В программе ничего специального нет - просто вывод и ввод в сокет и аналогично в COM порт с RTS/CTS двух раздельных потоков с контролем и т.д.:

if TcpClient.SendBuf(TcpTxBuf, 8192,0) <> 8192 then begin
Memo.Lines.Add('TCP SendBuf error');
... if(TcpClient.WaitForData(50)) then begin ...
... if ReadFile(hCom,ComRxBuf,SizeOf(ComRxBuf),CountComRxBuf,nil) ....
... if not WriteFile(hCom,Buf^,BufLen,txLen,Nil) then begin ....

Очень хорошо, а только замусорили тему

 

Доброй ночи pvvx! Может тут уже бьіло. Вопрос:
Можно как то получить доступ к uart через 80-й порт ? То есть через веб интерфейс? Нужно отправлять данньіе ну и получать .
Спасибо Вам за ссьілки по просмотру и скачивания флешь! Єто супер прошивка! Очень оригинально сделано! Спасибо )

 

Можно, но... имеется масса проблем, не в прошивке, а в алгоритмах использования UART в HTTP.
Счас можно просто вывести байт в порт (указано в примере sample.htm, в большой свалке).
Опишите предполагаемый интерфейс общения в HTTP c UART.

 

Я предполагаю "общаться" для запроса данньіх через гет запросьі: GET/ "желаемая информация" , передавать что то через пост запрос.

 

Уважаемый pvvx! Просьба выложить прошивку 0.1.3. - 0.1.4. - прошивается, но дальше практически не работает((. До этого круглосуточно гонял 0.1.3. в режиме TCP2COM - отлично гонял байты туда и обратно)) Даже странички настроек - 1-2 откроются, потом всё-зависон..

 

Аналогичный вопрос я поднимал в теме "Разработка ‘библиотеки’ малого webсервера на esp8266"

для себя сделал не элегантный вариант, в web_srv.c сразу после urldecode поставил условие
if(!os_memcmp((void*)pcmp, "uartSend=", 9)) {
...
return;
}
с переброской содержимого pcmp буфера от 9 симбола на UART,
в web_int_vars.c не получается поставить, так как cmpcpystr() срезает все что ниже пробела, а в запросе нужны управляющие симболы CR, LF, ESCAPE... было бы неплохо чтобы в POST все пропускалось до web_int_vars.c ....

а в web_int_callbacks.c условие
else if(!os_memcmp((void*)cstr, "uartRead", 8)) {
...
}
с считыванием с UART и передачей на tcp,
так как у меня ответ всегда в JSON формате, считывание прдолжается до последней закрывающей скобки '}'

в результате передача из javacript на UART получается примерно:

Код (Text):

1.  
2. ....
3. var data = '\x1B\n0?5\x1B\r';// данные
4. var params = "uartSend="+encodeURIComponent(data);
5. req.open('POST',"/uartRead.htm",true);
6. req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')
7. req.setRequestHeader("Content-length", params.length);
8. req.setRequestHeader("Connection", "close");
9. req.send(params);
10. ...

а в uartRead.htm только одна переменная ~uartRead~
в которой javacript получает ответ от UART в JSON формате, примерно так:

Код (Text):

1.  
2. ...
3.     req.onreadystatechange=function(){
4.        if (req.readyState==4){
5.          if (req.status < 400){
6.            var response={};
7.            if (req.responseText){
8.              eval('var response='+req.responseText);
9.            }
10.            callback(response);
11.          }
12.        }
13.      }
14. ...
15.  

если уважаемый pvvx добавил бы похожую функциональность, чтобы была "из коробки", было бы очень удобно...

 

Это спец проект и к данной теме (TCP2UART) не имеет никакого отношения.

Там отличия минимальны и старой у меня уже нет. У меня в одном из модулей прошито новой прошивкой и он постоянно работает и не виснет. Пробуйте сами пересобрать из исходников или что-то ещё... Или ошибки со ссылкой в первом сообщении? Счас проверю...
Скачал, прошил fullflash100.bin FLASH_DOWNLOAD_TOOLS_v0.9.3.1, протестировал прием-передачу TCP2UART своей программой - всё Ok.

 

А url-декодирование?
Как сами видите - возникает масса проблем. К примеру, зачем в поток передачи другого канала TCP2UART вставлять какие-то символы из асинхронного ему канала HTTP? Это разве не бардак?
Аналогично как отдавать страницу с UART, если скорость UART 300 Baud?
Пишите спец. драйвер, который будет управляться переменными с HTTP и иметь свои файлы в статических буферах, принятых по UART. Но это никак к данному проекту не относится и драйвер должен работать независимо от Web, всего предоставляя ему готовые страницы в виде файловой структуры...
А раз требуется именно это, то зачем тут нужен UART? Интерфейс к внешней файловой структуре в таком случае делают на SPI на скорости в 80Mbit/s. Всё остальное - детсад.
Большинство датчиков может обслуживать сам ESP8266 и внешний MCU, тем более со связью по UART, ему не требуется.

 

Добрый день!
Хочу сказать спасибо за проделанную работу и задать несколько вопросов.
Сразу оговорюсь, что я пока "теоретик" - модули ESP-07 только едут ко мне из Китая...

1. Почему Вы так ревностно относитесь к скорости передачи? Этот проект заточен под Ваши конкретные цели или это спортивный интерес? ИМХО скорости 115 200 для компорта хватает за глаза. Давайте подумаем, где может быть полезен этот переходник. Для удаленного доступа к порту конфигурации циски или другого оборудования, для работы с UART МК, для чего еще... Где необходимы такие скорости?
Опять же ИМХО там, где используется ком порт, не требуется передача больших объемов данных и скорости 9600 хватает в большинстве случаев.

2. Так и хочется за Вас закончить эту фразу: "или принимая их".
Что мешает драйверу принимать данные от WEB? Почему так сложно реализовать функционал, о котором писалось выше - пришел POST запрос, поместили его в буфер передачи, а из буфера приема в HEX формате выдали ответ в виде WEB страницы. Для работы в этом режиме будет полезно запретить работу в качестве стандартного переходника.
Мне это не нужно, просто интересно очень... К тому же эти китайские модули можно рассматривать только как заготовку для технического творчества и для подавляющего большинства радиолюбителей этот функционал будет более востребован, нежели стандартный переходник TCP2UART.

3. Проблемы с различными терминалами начинаются только на скоростях выше стандартных (если не рассматривать скоростные характеристики и задержки)?
Если нет, значит имеет место какая то ошибка или недоработка, в SDK или у Вас.

4. HW Virtual Serial Port или в Linux "socat pty,link=/dev/ttyV0,echo=0 tcp:192.168.1.1:1111 &" будет работать с этим устройством?

PS Еще раз спасибо за проделанную работу.

 

pvvx, спасибо за труды!
Прошился TCP2UART. Вещь нужная давно и везде. Надо мне сделать web интерфейс к своей железяке. Контроллер анализирует GET, POST и выдает соответствующие ответы. Все понятно. Когда передаю из контроллера в ESP, то ESP вставляет в произвольное место перевод строки (\r\n). В зависимости от скорости обмена это место варьируется. Контроллер выдает все как положено, проверял логгером. Причем если выдавать одну и ту же посылку непрерывно, то в этих последующих послыках нет проблем. Как будто ESP при приходе ему первых байт начинает просыпаться и где-то вставляет этот ненужный перевод строки. Бывает что их может быть несколько. Конечно же эти лишние байты портят ответ и браузер ничего не дожидается. Но больше всего меня зацепило то, что если я подключу ESP к компу через USB-переходник и буду отправлять ответы через терминалку (hTerm), то никаких проблем нету. У переходника используются только выводы Rx и Tx, управления потоком нету. Не могу объяснить это. Нет ли автоподстройки скорости в ESP? Пока приходит мысль что не совсем совпадают скорости обмена ESP и контроллера. А вот когда с компа, тогда скорости наиболее близки и поэтому работает. Выше писали что было бы неплохо чтобы можно было назначить 80-й порт для этого проекта. Было бы неплохо, но если так и не получится победить устойчивую передачу данных, то тогда нет необходимости.
У вас есть какие либо мысли по поводу описанного? В чем может быть особенность?


все же и из терминалки тоже есть глюки, но реже. поэтому сразу не заметил... эх

Попробовал штатную передачу AT командами. Через терминалку пока работает. Буду пробовать контроллер...

 

При любом подключении внешнего MCU. На 115200 очень тормозит сеть (инет и WiFi). Номинальная скорость где-то 1..2Mbit/s.
Низкие скорости UART (включая и 115200) используются для передачи на большие расстояния по длиннющим проводам. У нас таких проводов нет.
>Что мешает драйверу принимать данные от WEB?
По тому, что это другой проект, а тут TCP2UART.
> Проблемы с различными терминалами начинаются только на скоростях выше стандартных (если не рассматривать скоростные характеристики и задержки)?
Ошибки у большинства терминалов, размешенных в инет, находятся в них самих. Пока не одного бесплатного и кракнутого терминала, правильно работающего с RS-232 не найдено. Тем более с TCP. Они все имеют ненужные навороты с работой по TCP и бездарно расставленные задержки и размеры буферов для работы с UART. Их писали учащиеся младших классов школы и далекие от hard оборудования. 99% из этих писак не проверяло свою работу даже на примитивном логере, что и как выводит их терминал.
Ныне ошибки с UART наблюдаются и в серьезных проектах. Особенно в java. На рынке развелось масса кривых драйверов от китайцев...
И вообще это общая тенденция современного ПО - иметь вопиющие ошибки в главных функциях. Всё "для галочки" - писанули не проверяя, повесили (с) GPL (типа нам всё пофиг), но зато кричат, что типа у нас всё есть - галочку же видите в описании, что данный функционал есть? А работает он или нет - не важно (гарантий то никаких)

Да, в прошлой версии 0.1.4 вроде было забыто сохранение конфигурации номера порта TCP2UART в тексте HTML. В новой - вставил.

 

Согласен, но уж очень близкий по теме.
У Вас же телефон с камерой - это абсолютно разные вещи, но объединенные в одно устройство и телевизор фильмы из сети показывает, почему бы не сделать, чтобы TCP2UART умел чуть больше, чем сейчас. Ну да ладно, это не важно.

Эти ошибки проявляются на всех скоростях, которые поддерживаются Вашим проектом или только на нестандартных? Уверен, Вы прекрасно понимаете причины возникновения ошибок на нестандартных скоростях.

Аналогично. Только я не встречал оборудования, не работающее с этими "кривыми" терминалами. PuTTY, чем он не устраивает? У меня он отлично работает, только не с Wi-Fi, а с обычным сетевым TCP2UART через виртуальный порт HW Virtual Serial Port. Так же работают и остальные (включая виндовый гипертерминал), только PuTTY для меня удобнее.
Не в обиду, только я делая что то подвергаю сомнению не только чужой код, но и свой.

PS Пока это не переросло в очередной флуд, я завязываю, прошу только ответить на пару последних вопросов - интересно.
PPS Может у ESP просто ресурсов не хватает? Хочу понять причину проблемы, стоит на нее рассчитывать в этом вопросе или тянуть провода.