Вами предложенный
Внутри включается, Receive As HEX называется
Вы предлагаете проверять глючные терминалы?
Ни в коем разе, они же глючные
Меня неглючный конвертер TCP2UART гораздо больше интересует
Для начала проверьте терминал, а проще написать свой.
Мне лично написать свой терминал явно не проще, выше писАл.
У вас есть CP2104. По началу соедините её с какой другой микрухой и передайте на скорости более 115200 Baud 1 Гег без ошибок. Когда удастся это сделать - пишите - я подожду (ведь полученные условия, когда это сработает, очень интересны)
Тоже об этом подумал, ближайшее время проверю. Кроме CP2104 есть еще кучка разных, на них тоже посмотрю, какой результат получается. Это вполне верное замечание.
Мир устроен гораздо проще - RS-232 не является протоколом с гарантиями передачи, при малейшем расхождении частот приемника и передатчика
Вы, наверное, имели ввиду не гарантирует доставку, при расхождении частот?
Передавать устройство или будет (если ему разрешает приемник) или не будет (если приемник тормоз, или уснул). А если его еще и "слуха" лишить, то в пустоту будет тарабанить, что умалишенный, только его никто не услышит
А тут потерь нет. Они возможны только в аппаратной части и в TCP соединении, при условии контроля сигнала RTS
Ух ты, а меня в детском саду учили, что TCP-IP это протокол ГАРАНТИРОВАННОЙ ДОСТАВКИ. Не? Или садик был другой? Мы ж не по UDP работаем. Верно?
Если ошибки в TCP и они не отображены в отладке - значит пора закрывать весь Инет
Если Вы привыкли менять авто, когда пепельница заполнится, а вычистить некому - то да. Но в TCP есть свои методы борьбы с потерянными пакетами. Иначе бы киношка, скачанная в торрентах не показывала бы
После выставления сигнала RTS данная прошивка может принять ещё 15 байт как минимум и передаст их потом, если встали из-за затыка в сети.
Здесь что-бы дать аргументированный ответ - нужно с калькулятором посидеть. Пока не вижу в этом необходимости, ввиду ниженаписанного.
Итак, веселая полемика окончена, надеюсь. Теперь по существу.
Имеем:
1) TCPIP стек, позволяющий получить среду гарантированной доставки (не оптика, и даже не медь, но при достаточном перекрытии по скорости должны успевать набирать кольцевой буфер, разбирать на пакеты, отсылать пакеты, ретрейнить, если попросят, собирать обратно и вкладывать в выходной кольцевой)
2) Скорости контроллеров с обеих сторон, превышающие скорости передачи RS232 на порядки. Т.е. софтово будем успевать корректировать ошибки.
3) Энтузиастов, готовых вкладывать свое время в развитие интересной для них темы (это о Вас конкретно, и о тех, кто подпишется лаконично-достаточный интерфейс )
4) Энтузиастов, готовых вкладывать свое время в поиски багов, коих еще будет (это о мне и подобных)
Не имеем:
1) Возможности получить полнейшую нормальную документацию по сему "произведению искусств"
2) Достаточного количества оперативки в esp8266. (здесь я не уверен, возможно и имеем)
3) НЕ криворуких китайцев, выпускающих продукт, соответствующий заявленным характеристикам. (здесь я уверен :-D )
4) Возможности оторвать им эти самые руки
Что хотим:
1) Получить возможность гарантированно стабильно передаватьRS232 протокол поверх относительно нестабильной WiFi сети.
СМОГЁМ?
От себя готов выступить дотошным тестером. Конечный продукт мне интересен. Если параллельно будет возможность и RAW-ить со стандартных фотоприемников, так вообще красота.