pvvx
Активный участник сообщества
Это не моя программа - это https://yadi.sk/d/6XQP3voHfLmsc (даю сам, т.к. у источника оно теперь с вирусом - на неё орет, но есть ли он там - неизвестно).
Это "выставляет" программа терминала.
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Прошивка TCP2UART переходника с настройкой по Web
- Автор темы pvvx
- Дата начала
shaman1010
Member
Та же байда, 1 в 1 не передает, различия видны глазами. В основном здесь пропускаются пробелы при передаче.
И терминал подобный встречал, только по-моему он на китайском был. Еще при старте продаж 8266-х, но у него больше 115200 не выставляется.
pvvx
Активный участник сообщества
Он и есть на китайском. Но единственный передает на UART без межсимвольной задержки в 1 ms, правда кусками, по размеру буфера для драйвера...
TCP2UART у меня на разных модулях ничего не теряет. Это проверено и сегодня и месяц назад...
shaman1010
Member
Попробуйте на досуге, для чистоты эксперимента. Взять вложенный файл, перевести терминал в HEX и отправить его. Словите файл в текстовом формате, где будут вставлены принятые HEX символы. (их можно не в файл сбрасывать, а просто после приема в правом окне просмотреть, оно сдвигается, что-бы удобней было отформатировать принятый поток) В конце файла идут повторяющиеся последовательности из FF FF FF 00 по ним удобно в первом приближении отлавливать разницу глазами. У меня там есть варианты FFFF FF 00 (пропущен пробел) и другие.
Я не говорю, что это верные телодвижения для передачи бинарников, просто как обычно пытаюсь выловить баги нестандартным подходом. Практика показала, что если их вычистить там, то в обычном режиме 99,9999% устройство будет работать корректно в своей ограниченной песочнице.
Если Вам кажется, что подход к тестированию неверный - готов выслушать доводы (если есть время/желание).
Файл вложил, обычная мелкая картинка, смотреть WihHEX-ом, естественно (или чем Вы там HEX-ы смотрите, не принципиально). Полученный поток - хоть блокнотом. Просто исходник нужно смотреть HEX редактором, принятый - текстовым. И глазами ключевые места словить.
20150317032823 — копия.png
Так, стоп, а разве в текстовом режиме некоторые символы не являются управляющими и потому выбрасываются?
Потому в текстовом режиме бинарники обычно и нельзя принимать/отправлять...
Update:
Как по мне, верная процедура такая: отправляем бинарник, принимаем тоже бинарник (в бинарном режиме то есть и то и это), а затем полученные файлы сравниваем хоть по хеш-сумме, хоть тем же WinMerge (оч. советую).
Update 2:
Могу предложить свою программу, но в ней есть пара ограничений:
Передает тоже с задержками, но пакетами до 256 байт вроде... Точно не помню...
И самое главное - она передает в порт, а читает из сокета, или наоборот - передает в сокет, а читает из порта... То есть там проверяется передача именно по кругу: COM->ESP->TCP либо обратно.
Скриншот есть по первой ссылке из моей подписи.
А, еще там вроде скорости любые не выставить... 256 вроде потолок... Хотя, я не разбирался, нужно поковырять...
Последнее редактирование:
shaman1010
Member
Вы абсолютно правы для "сферического коня в вакууме". В приложенном файле, в указанных местах нет нечитаемых символов, (исходник рассмотрен HEX-ом).
Терминал в HEX, я выше это написал. Смысл в другом, есть некая передаваемая последовательность, пусть это будут FF и нули. Они передаются с вставленными пробелами между ними. На другом терминале мы и должны увидеть 100% повторяющуюся последовательность. Если есть изменения - значит что-то по дороге потеряли. Вот и все. А бинарники передают в бинарном виде для того, что бы можно было применить коррекцию и поправить, что упустили. Плюс передача не ascii, естественно.
pvvx
Активный участник сообщества
Какой терминал, какой hex? Вы предлагаете проверять глючные терминалы?
Для начала проверьте терминал, а проще написать свой. И здесь тема не о терминалах У вас есть CP2104. По началу соедините её с какой другой микрухой и передайте на скорости более 115200 Baud 1 Гег без ошибок. Когда удастся это сделать - пишите - я подожду (ведь полученные условия, когда это сработает, очень интересны)
Мир устроен гораздо проще - RS-232 не является протоколом с гарантиями передачи, при малейшем расхождении частот приемника и передатчика
А тут потерь нет. Они возможны только в аппаратной части и в TCP соединении, при условии контроля сигнала RTS
Если ошибки в TCP и они не отображены в отладке - значит пора закрывать весь Инет После выставления сигнала RTS данная прошивка может принять ещё 15 байт как минимум и передаст их потом, если встали из-за затыка в сети.
Последнее редактирование:
shaman1010
Member
Вами предложенный
Внутри включается, Receive As HEX называется
Ни в коем разе, они же глючныеВы предлагаете проверять глючные терминалы?
Меня неглючный конвертер TCP2UART гораздо больше интересуетМне лично написать свой терминал явно не проще, выше писАл.
Тоже об этом подумал, ближайшее время проверю. Кроме CP2104 есть еще кучка разных, на них тоже посмотрю, какой результат получается. Это вполне верное замечание.У вас есть CP2104. По началу соедините её с какой другой микрухой и передайте на скорости более 115200 Baud 1 Гег без ошибок. Когда удастся это сделать - пишите - я подожду (ведь полученные условия, когда это сработает, очень интересны)
Вы, наверное, имели ввиду не гарантирует доставку, при расхождении частот?Мир устроен гораздо проще - RS-232 не является протоколом с гарантиями передачи, при малейшем расхождении частот приемника и передатчика
Передавать устройство или будет (если ему разрешает приемник) или не будет (если приемник тормоз, или уснул). А если его еще и "слуха" лишить, то в пустоту будет тарабанить, что умалишенный, только его никто не услышит Ух ты, а меня в детском саду учили, что TCP-IP это протокол ГАРАНТИРОВАННОЙ ДОСТАВКИ. Не? Или садик был другой? Мы ж не по UDP работаем. Верно?А тут потерь нет. Они возможны только в аппаратной части и в TCP соединении, при условии контроля сигнала RTS
Если Вы привыкли менять авто, когда пепельница заполнится, а вычистить некому - то да. Но в TCP есть свои методы борьбы с потерянными пакетами. Иначе бы киношка, скачанная в торрентах не показывала быЕсли ошибки в TCP и они не отображены в отладке - значит пора закрывать весь Инет
Здесь что-бы дать аргументированный ответ - нужно с калькулятором посидеть. Пока не вижу в этом необходимости, ввиду ниженаписанного.
Итак, веселая полемика окончена, надеюсь. Теперь по существу.
Имеем:
1) TCPIP стек, позволяющий получить среду гарантированной доставки (не оптика, и даже не медь, но при достаточном перекрытии по скорости должны успевать набирать кольцевой буфер, разбирать на пакеты, отсылать пакеты, ретрейнить, если попросят, собирать обратно и вкладывать в выходной кольцевой)
2) Скорости контроллеров с обеих сторон, превышающие скорости передачи RS232 на порядки. Т.е. софтово будем успевать корректировать ошибки.
3) Энтузиастов, готовых вкладывать свое время в развитие интересной для них темы (это о Вас конкретно, и о тех, кто подпишется лаконично-достаточный интерфейс )
4) Энтузиастов, готовых вкладывать свое время в поиски багов, коих еще будет (это о мне и подобных)
Не имеем:
1) Возможности получить полнейшую нормальную документацию по сему "произведению искусств"
2) Достаточного количества оперативки в esp8266. (здесь я не уверен, возможно и имеем)
3) НЕ криворуких китайцев, выпускающих продукт, соответствующий заявленным характеристикам. (здесь я уверен :-D )
4) Возможности оторвать им эти самые руки
Что хотим:
1) Получить возможность гарантированно стабильно передаватьRS232 протокол поверх относительно нестабильной WiFi сети.
СМОГЁМ?
От себя готов выступить дотошным тестером. Конечный продукт мне интересен. Если параллельно будет возможность и RAW-ить со стандартных фотоприемников, так вообще красота.
pvvx
Активный участник сообщества
Ужо. Он прошит в вашем модуле.СМОГЁМ?
Но это не переходник TCP - RS-232, т.к. по сети не передаются состояния дополнительных линий. Для этого есть готовые специализированные проекты с драйверами, эмулирующими COM порт, в каждую операционную систему на модулях поддерживающих систему не менее OpenWRT и реализованные на линух.И это не проект для опроса, накопления и передачи данных с датчиков. Таковой будет позже. Это просто TCP2UART для использования модуля как беспроводного удлинителя при подключении к внешним устройствам общающимся по RX-TX+RTS-CTS. Типа у вас есть устройство с выходами RS-TTL и вам надо его подключить удаленно или просто протестировать в терминале типа hypertrm.exe. Подключаете к устройству модуль с прошивкой TCP2UART и открываете на компе (или телефоне) TCP сокет (winsoket) и вперед...
Проверяйте. Должно работать. У мня и нескольких других людей это работает. Остальные ещё не тестировали
Последнее редактирование:
pvvx
Активный участник сообщества
http://192.168.4.1/protect/flash.bin (если записан диск с файлом protect/flash.bin)
HexDamp для просмотра (всегда):
http://192.168.4.1/web.cgi?hexdmpb0x40200000=0x80000 в bytes виде
http://192.168.4.1/web.cgi?hexdmpd0x40200000=0x80000 в dwords виде
Только не на Google Chrome - он тормоз!
Не умеет общаться с устройствами у которых малый TCP стек .Это интересно - что не читается и как поставить защиту?
Исходники пока соответствуют соседней теме. Там есть всё блоками и Web_Base2\bin\readme.txt куда и какие блоки записывать.
Последнее редактирование:
И мне интересноhttp://192.168.4.1/protect/flash.bin (если записан диск с файлом protect/flash.bin)
HexDamp для просмотра (всегда):
http://192.168.4.1/web.cgi?hexdmpb0x40200000=0x80000 в bytes виде
http://192.168.4.1/web.cgi?hexdmpd0x40200000=0x80000 в dwords виде
Только не на Google Chrome - он тормоз!
Это интересно - что не читается и как поставить защиту?
Исходники пока соответствуют соседней теме. Там есть всё блоками и Web_Base2\bin\readme.txt куда и какие блоки записывать.
) программатор данньіе флешки поддерживает . А ID все нули , ну и прошивка соответственно тоже
shaman1010
Member
"Электроника - это наука о контактах. Находим, почему они есть там, где не должны быть. И почему их нет там, где должны."И мне интересно
Мне кажется - Ваш случай.
Оказывается у TL866 совмещенный интерфейс ISP из интерфейсом SPI при программировании флешь ...
У меня на ISP болталась Atmega32 ))) Вот вся и проблема .
shaman1010
Member
Наверное я опять что-то не так тестирую
но:1) Проверил связку из двух CP2104+RTS+CTS в гипертерминале, на максимальной для него скорости (921600), по ZModem-у.
Перелил 40мегабайтный видеоролик в одну и другую сторону. Сравнил все три файла - идентичны.
2) Подключаю winsock с одной стороны и один из CP2104-х с другой (второй проверил тоже). RTS+CTS включил везде. Скорость даже стандартная - 115200.
Пытаюсь отправить 91 кбайтную прошивку - обрывается. Как в одну, так и в другую сторону.
Во вложении 4 скрина по п.2.
Из надцати попыток пару раз получилось-таки залить этот мелкий файл безошибочно, но...
ЧЯДНТ?
upd. в одной из следующих попыток CP2104 зафиксировал ответ от модуля (wdt, как в один из первых раз). В этот раз я даже убрал галку со 160МГц.
Последнее редактирование:
pvvx
Активный участник сообщества
Расскажите лучше, пожалуйста, почему этот "гипер" на скорости 921600Baud передает в порт по одному символу в более 200ms:
Тогда я вам расскажу, как на нем тестировать
Я устал ждать передачи 500 кило на 921600Baud в нем
До сих пор жду...Вы пробовали в нем передать короткий файл в несколько байт на Zmodem? Попробуйте
Всё - оно передало 591кило с 0 повторов и 0 ошибок на Kermit за пол часа при скорости UART 921600...
Последнее редактирование:
shaman1010
Member
Ну что я Вам могу сказать по этому поводу?Расскажите лучше, пожалуйста, почему этот "гипер" на скорости 921600Baud передает в порт по одному символу в более 200ms:
...
Я устал ждать передачи 500 кило на 921600Baud в нем
Вы пробовали в нем передать короткий файл в несколько байт на Zmodem? Попробуйте
Смотрите сами (файл 79МБ, все скорости видны )
Это на двух CP2104, на 921600 и с хардварным RTS+CTS
Я надеюсь не нужно рассказывать, почему на Kermit долго, медленно и получилось? И почему я использовал ZModem?
pvvx
Активный участник сообщества
http://en.wikipedia.org/wiki/ZMODEM : В эпоху 300 бит / с модемов на весь пакет 132-байт уходило немногим более 3,5 секунд, чтобы отправить (132 байт * 8 бит на байт / 300 бит в секунду)… Я плакаль...
Давайте - рассказывайте - посмеюсь...
У него наверно повторы кончаются? Он устает? Или что?
shaman1010
Member
Я Вам свой скрин для чего прикладывал? Посмотрите, там видны все скорости, размер файла, скорость обмена.http://en.wikipedia.org/wiki/ZMODEM : В эпоху 300 бит / с модемов на весь пакет 132-байт уходило немногим более 3,5 секунд, чтобы отправить (132 байт * 8 бит на байт / 300 бит в секунду)… Я плакаль...
Давайте - рассказывайте - посмеюсь...
У него наверно повторы кончаются? Он устает? Или что?
Вот здесь очень коротко и по делу о различиях.
Смейтесь...
Кстати, 80мегабайт уже перекинулись, вложил скрин настроек и скрин отчета о идентичности файлов
Это все на двух CP2104-х.
Продолжайте посмеиваться, и по возможности покажите на Вашем переходнике аналогичный результат, может у меня с модулем esp8266 что-то...
Последнее редактирование: