Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

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

Тема в разделе "SDK и создание собственных прошивок", создана пользователем pvvx, 13 мар 2015.

  1. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Это не моя программа - это https://yadi.sk/d/6XQP3voHfLmsc (даю сам, т.к. у источника оно теперь с вирусом - на неё орет, но есть ли он там - неизвестно).
    Это "выставляет" программа терминала.
     
  2. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Та же байда, 1 в 1 не передает, различия видны глазами. В основном здесь пропускаются пробелы при передаче.
    И терминал подобный встречал, только по-моему он на китайском был. Еще при старте продаж 8266-х, но у него больше 115200 не выставляется.
     
  3. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Он и есть на китайском. Но единственный передает на UART без межсимвольной задержки в 1 ms, правда кусками, по размеру буфера для драйвера...
    TCP2UART у меня на разных модулях ничего не теряет. Это проверено и сегодня и месяц назад...
     
  4. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Попробуйте на досуге, для чистоты эксперимента. Взять вложенный файл, перевести терминал в HEX и отправить его. Словите файл в текстовом формате, где будут вставлены принятые HEX символы. (их можно не в файл сбрасывать, а просто после приема в правом окне просмотреть, оно сдвигается, что-бы удобней было отформатировать принятый поток) В конце файла идут повторяющиеся последовательности из FF FF FF 00 по ним удобно в первом приближении отлавливать разницу глазами. У меня там есть варианты FFFF FF 00 (пропущен пробел) и другие.
    Я не говорю, что это верные телодвижения для передачи бинарников, просто как обычно пытаюсь выловить баги нестандартным подходом. Практика показала, что если их вычистить там, то в обычном режиме 99,9999% устройство будет работать корректно в своей ограниченной песочнице.
    Если Вам кажется, что подход к тестированию неверный - готов выслушать доводы (если есть время/желание).
    Файл вложил, обычная мелкая картинка, смотреть WihHEX-ом, естественно (или чем Вы там HEX-ы смотрите, не принципиально). Полученный поток - хоть блокнотом. Просто исходник нужно смотреть HEX редактором, принятый - текстовым. И глазами ключевые места словить.

    20150317032823 — копия.png
     

    Вложения:

  5. JustACat

    JustACat Moderator Команда форума

    Сообщения:
    568
    Симпатии:
    121
    Так, стоп, а разве в текстовом режиме некоторые символы не являются управляющими и потому выбрасываются?
    Потому в текстовом режиме бинарники обычно и нельзя принимать/отправлять...

    Update:
    Как по мне, верная процедура такая: отправляем бинарник, принимаем тоже бинарник (в бинарном режиме то есть и то и это), а затем полученные файлы сравниваем хоть по хеш-сумме, хоть тем же WinMerge (оч. советую).

    Update 2:
    Могу предложить свою программу, но в ней есть пара ограничений:
    Передает тоже с задержками, но пакетами до 256 байт вроде... Точно не помню...
    И самое главное - она передает в порт, а читает из сокета, или наоборот - передает в сокет, а читает из порта... То есть там проверяется передача именно по кругу: COM->ESP->TCP либо обратно.
    Скриншот есть по первой ссылке из моей подписи.
    А, еще там вроде скорости любые не выставить... 256 вроде потолок... Хотя, я не разбирался, нужно поковырять...
     
    Последнее редактирование: 18 мар 2015
  6. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Вы абсолютно правы для "сферического коня в вакууме". В приложенном файле, в указанных местах нет нечитаемых символов, (исходник рассмотрен HEX-ом).
    Терминал в HEX, я выше это написал. Смысл в другом, есть некая передаваемая последовательность, пусть это будут FF и нули. Они передаются с вставленными пробелами между ними. На другом терминале мы и должны увидеть 100% повторяющуюся последовательность. Если есть изменения - значит что-то по дороге потеряли. Вот и все. А бинарники передают в бинарном виде для того, что бы можно было применить коррекцию и поправить, что упустили. Плюс передача не ascii, естественно.
     
  7. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Какой терминал, какой hex? Вы предлагаете проверять глючные терминалы? :) Для начала проверьте терминал, а проще написать свой. И здесь тема не о терминалах :) :)
    У вас есть CP2104. По началу соедините её с какой другой микрухой и передайте на скорости более 115200 Baud 1 Гег без ошибок. Когда удастся это сделать - пишите - я подожду (ведь полученные условия, когда это сработает, очень интересны) :)
    Мир устроен гораздо проще - RS-232 не является протоколом с гарантиями передачи, при малейшем расхождении частот приемника и передатчика :p
    А тут потерь нет. Они возможны только в аппаратной части и в TCP соединении, при условии контроля сигнала RTS :p Если ошибки в TCP и они не отображены в отладке - значит пора закрывать весь Инет :)
    После выставления сигнала RTS данная прошивка может принять ещё 15 байт как минимум и передаст их потом, если встали из-за затыка в сети.
     
    Последнее редактирование: 18 мар 2015
  8. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Вами предложенный
    Внутри включается, Receive As HEX называется :)
    Ни в коем разе, они же глючные :) Меня неглючный конвертер TCP2UART гораздо больше интересует
    Мне лично написать свой терминал явно не проще, выше писАл.
    Тоже об этом подумал, ближайшее время проверю. Кроме CP2104 есть еще кучка разных, на них тоже посмотрю, какой результат получается. Это вполне верное замечание.
    Вы, наверное, имели ввиду не гарантирует доставку, при расхождении частот? :) Передавать устройство или будет (если ему разрешает приемник) или не будет (если приемник тормоз, или уснул). А если его еще и "слуха" лишить, то в пустоту будет тарабанить, что умалишенный, только его никто не услышит :)
    Ух ты, а меня в детском саду учили, что TCP-IP это протокол ГАРАНТИРОВАННОЙ ДОСТАВКИ. Не? Или садик был другой? Мы ж не по UDP работаем. Верно? :)
    Если Вы привыкли менять авто, когда пепельница заполнится, а вычистить некому - то да. Но в TCP есть свои методы борьбы с потерянными пакетами. Иначе бы киношка, скачанная в торрентах не показывала бы :)
    Здесь что-бы дать аргументированный ответ - нужно с калькулятором посидеть. Пока не вижу в этом необходимости, ввиду ниженаписанного.

    Итак, веселая полемика окончена, надеюсь. Теперь по существу.
    Имеем:
    1) TCPIP стек, позволяющий получить среду гарантированной доставки (не оптика, и даже не медь, но при достаточном перекрытии по скорости должны успевать набирать кольцевой буфер, разбирать на пакеты, отсылать пакеты, ретрейнить, если попросят, собирать обратно и вкладывать в выходной кольцевой)
    2) Скорости контроллеров с обеих сторон, превышающие скорости передачи RS232 на порядки. Т.е. софтово будем успевать корректировать ошибки.
    3) Энтузиастов, готовых вкладывать свое время в развитие интересной для них темы (это о Вас конкретно, и о тех, кто подпишется лаконично-достаточный интерфейс )
    4) Энтузиастов, готовых вкладывать свое время в поиски багов, коих еще будет (это о мне и подобных)

    Не имеем:
    1) Возможности получить полнейшую нормальную документацию по сему "произведению искусств"
    2) Достаточного количества оперативки в esp8266. (здесь я не уверен, возможно и имеем)
    3) НЕ криворуких китайцев, выпускающих продукт, соответствующий заявленным характеристикам. (здесь я уверен :-D )
    4) Возможности оторвать им эти самые руки :)

    Что хотим:
    1) Получить возможность гарантированно стабильно передаватьRS232 протокол поверх относительно нестабильной WiFi сети.

    СМОГЁМ? :)

    От себя готов выступить дотошным тестером. Конечный продукт мне интересен. Если параллельно будет возможность и RAW-ить со стандартных фотоприемников, так вообще красота.
     
  9. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Ужо. Он прошит в вашем модуле. :) Но это не переходник TCP - RS-232, т.к. по сети не передаются состояния дополнительных линий. Для этого есть готовые специализированные проекты с драйверами, эмулирующими COM порт, в каждую операционную систему на модулях поддерживающих систему не менее OpenWRT и реализованные на линух.
    И это не проект для опроса, накопления и передачи данных с датчиков. Таковой будет позже. Это просто TCP2UART для использования модуля как беспроводного удлинителя при подключении к внешним устройствам общающимся по RX-TX+RTS-CTS. Типа у вас есть устройство с выходами RS-TTL и вам надо его подключить удаленно или просто протестировать в терминале типа hypertrm.exe. Подключаете к устройству модуль с прошивкой TCP2UART и открываете на компе (или телефоне) TCP сокет (winsoket) и вперед...
    Проверяйте. Должно работать. У мня и нескольких других людей это работает. Остальные ещё не тестировали :)
     
    Последнее редактирование: 19 мар 2015
  10. Артемий

    Артемий Читатель

    Сообщения:
    166
    Симпатии:
    8
    Уважаемьій pvvx. А можно как то получить монолитньій дамп флешь со своими страницами и настройками? Сегодня продолбался несколько часов... Так и не получилось считать дамп из флешь... Даже ID не читается... Стоит защита?
     
  11. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    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 куда и какие блоки записывать.
     
    Последнее редактирование: 19 мар 2015
    Артемий нравится это.
  12. Артемий

    Артемий Читатель

    Сообщения:
    166
    Симпатии:
    8
    И мне интересно :)) программатор данньіе флешки поддерживает . А ID все нули , ну и прошивка соответственно тоже :)
     
  13. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    "Электроника - это наука о контактах. Находим, почему они есть там, где не должны быть. И почему их нет там, где должны."
    Мне кажется - Ваш случай.
     
    Артемий нравится это.
  14. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Тестирование показало, что SDK 0.9.6 (b1) никуда не годится.
    Выложена новая версия, на SDK 0.9.5. Она гораздо стабильнее.
     
    Последнее редактирование: 20 мар 2015
  15. Артемий

    Артемий Читатель

    Сообщения:
    166
    Симпатии:
    8
    Оказывается у TL866 совмещенный интерфейс ISP из интерфейсом SPI при программировании флешь ...
    У меня на ISP болталась Atmega32 ))) Вот вся и проблема .
     
  16. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Наверное я опять что-то не так тестирую :) но:
    1) Проверил связку из двух CP2104+RTS+CTS в гипертерминале, на максимальной для него скорости (921600), по ZModem-у.
    Перелил 40мегабайтный видеоролик в одну и другую сторону. Сравнил все три файла - идентичны.
    2) Подключаю winsock с одной стороны и один из CP2104-х с другой (второй проверил тоже). RTS+CTS включил везде. Скорость даже стандартная - 115200.
    Пытаюсь отправить 91 кбайтную прошивку - обрывается. Как в одну, так и в другую сторону.
    Во вложении 4 скрина по п.2.

    Из надцати попыток пару раз получилось-таки залить этот мелкий файл безошибочно, но...

    ЧЯДНТ?

    upd. в одной из следующих попыток CP2104 зафиксировал ответ от модуля (wdt, как в один из первых раз). В этот раз я даже убрал галку со 160МГц.

    socket-hardware.png usb-hardware.png socket-to-usb.png usb-to-socket.png socket-wdt.png
     
    Последнее редактирование: 20 мар 2015
  17. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    Расскажите лучше, пожалуйста, почему этот "гипер" на скорости 921600Baud передает в порт по одному символу в более 200ms:
    1sec921600Baud.gif
    Тогда я вам расскажу, как на нем тестировать :)
    g21.gif
    Я устал ждать передачи 500 кило на 921600Baud в нем :) До сих пор жду...
    Вы пробовали в нем передать короткий файл в несколько байт на Zmodem? Попробуйте :)
    Всё - оно передало 591кило с 0 повторов и 0 ошибок на Kermit за пол часа при скорости UART 921600...
     
    Последнее редактирование: 20 мар 2015
  18. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Ну что я Вам могу сказать по этому поводу?
    Смотрите сами (файл 79МБ, все скорости видны )
    hyper1.png
    Это на двух CP2104, на 921600 и с хардварным RTS+CTS

    Я надеюсь не нужно рассказывать, почему на Kermit долго, медленно и получилось? И почему я использовал ZModem?
     
  19. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.091
    Симпатии:
    1.303
    http://en.wikipedia.org/wiki/ZMODEM : В эпоху 300 бит / с модемов на весь пакет 132-байт уходило немногим более 3,5 секунд, чтобы отправить (132 байт * 8 бит на байт / 300 бит в секунду)… Я плакаль...
    Давайте - рассказывайте - посмеюсь... :)
    У него наверно повторы кончаются? Он устает? Или что?
     
  20. shaman1010

    shaman1010 Читатель

    Сообщения:
    128
    Симпатии:
    14
    Я Вам свой скрин для чего прикладывал? Посмотрите, там видны все скорости, размер файла, скорость обмена.
    Вот здесь очень коротко и по делу о различиях.
    Смейтесь...

    Кстати, 80мегабайт уже перекинулись, вложил скрин настроек и скрин отчета о идентичности файлов
    winmerge1.png hyper2.png
    Это все на двух CP2104-х.

    Продолжайте посмеиваться, и по возможности покажите на Вашем переходнике аналогичный результат, может у меня с модулем esp8266 что-то...
     
    Последнее редактирование: 20 мар 2015

Поделиться этой страницей