Проблема кодключения к RPi через USB-to-RS232, не все символы приходят в терминал Опции

[Mickey Rourke]

Здравствуйте! Возникла необходимость посмотреть что происходит во время загрузки Raspberry Pi 3B. Настроил cmdline.txt, config.txt по инструкции, подключился через вот такой конвертер, но в терминал приходят не все символы, многие хаотично пропускаются. Подключаюсь через minicom (115200, 8N1, NOR). Вывод выглядит вот так:


Подскажите пожалуйста, в чем может быть проблема? Не из-за конвертера ли это вообще происходит? Может быть такое что пересылка через UART не успевает за выводом отладочных данных ядром Linux?
Я полный ноль в этом деле.

Сообщение отредактировал Mickey Rourke - Sep 22 2018, 09:55

[aaarrr]

Не из-за конвертера ли это вообще происходит?

Вряд ли, но такие конвертеры после покупки следует препарировать на предмет "забытых" при сборке конденсаторов.

Может быть такое что пересылка через UART не успевает за выводом отладочных данных ядром Linux?

Не может.

А чем принимаете (хост, ПО)?

[kovigor]

в терминал приходят не все символы, многие хаотично пропускаются

В управлении потоком дело, скорее всего. Персоналка 'захлебывается' данными, приходящими в порт. Попробуйте и на Raspberry и на персоналке включить управление потоком, как минимум, Xon/Xoff, а лучше - аппаратное, RTS/CTS. В крайнем случае - попробуйте уменьшить скорость до 9600.
Еще вариант - аппаратное повреждение приемника или передатчика на одном из устройств (занижен один из уровней). А проверяется это осциллографом ...

[Mickey Rourke]

Спасибо, aaarrr!

А чем принимаете (хост, ПО)?

Использую minicom

Попробуйте и на Raspberry и на персоналке включить управление потоком, как минимум, Xon/Xoff, а лучше - аппаратное, RTS/CTS. В крайнем случае - попробуйте уменьшить скорость до 9600.

minicom включен режим Аппаратное управление потоком, а с RPi похоже все сложно, CTS/RTS вынесены на 36 и 11 пины и так просто это не решить. А вот включение XOFF и XON помогло на хосте. Большое спасибо, kovigor!

Сообщение отредактировал Mickey Rourke - Sep 22 2018, 10:51

[kovigor]

Большое спасибо, kovigor!

На здоровье.
Так я не понял, вы и на хосте и на Raspberry включили Xon/Xoff ? Тогда все правильно ...

[Tarbal]

На здоровье.
Так я не понял, вы и на хосте и на Raspberry включили Xon/Xoff ? Тогда все правильно ...

Я не сталкивался с такой проблемой, хотя много раз подключал UART к различным карточкам, включая малину. Все контроли отключены. Все работает нормально.
Проверьте кабель и разъемы. Попробуйте с другим компьютером. Короче ишите комбинации, что работают. Это поможет локализовать причину.

Если вас устраивает посмотреть последние системные сообщения после загрузки, то в терминале исполните команду dmesg. Это о том, что некоторые вещи можно сделать и другим путем.

[rx3apf]

Не может.

А почему бы и нет ? Не знаю как с Prolific, но вот CP2102 у меня теряла данные, начиная с некоторого объема входных. Т.е. идет поток 115200, если непрерывный блок больше какой-то величины - потеря. Если чуть-чуть притормозить передачу - потери нет. Управления потоком не было, естественно, но это никак не повод терять. С другими адаптерами - проблемы не было.

А, нет, наврал. Эта она (2102) по передаче дохла, а не по приему, запамятовал уже...

Сообщение отредактировал rx3apf - Sep 22 2018, 20:55

[kovigor]

Управления потоком не было, естественно, но это никак не повод терять.

Ну почему же ? Размер приемного буфера драйвера в Windows по умолчанию равен 4096 байтам. На скорости в 115200 он заполняется за полсекунды. Если машина чем-то сильно занята и драйвер не успевает опустошать буфер, то он переполняется. Управление потоком ведь не просто так придумали. Я понимаю, для современных высокопроизводительных машин это уже не так актуально. Но все же ...

[rx3apf]

В моем случае машина была пустая. Но я просто подзабыл уже, только сейчас вспомнил - она дохла по передаче ! И пришлось паузу добавить при передаче (самый минимум, чтобы буквально на единицы %% притормозить относительно номинальной скорости). FT2232 - без проблем. А эта вот дрянь преподнесла сюрприз.

[jcxz]

В моем случае машина была пустая. Но я просто подзабыл уже, только сейчас вспомнил - она дохла по передаче ! И пришлось паузу добавить при передаче (самый минимум, чтобы буквально на единицы %% притормозить относительно номинальной скорости). FT2232 - без проблем. А эта вот дрянь преподнесла сюрприз.

Много лет использую CP2102 - никаких проблем ни на каких скоростях до 921600 ни с какой плотностью потока. Как и с FTDI.
Проблемы обычно есть у разных терминалов - при плотном потоке у большинства терминалов из инета начинается потеря данных. Обусловлено это только кривостью рук их написателей. Нормально работает на любых скоростях например putty.
Вангую, что и у Вас причина именно в неумении работать с COM-портом под виндой (или с UART на МК). И CP2102 - не при чём.

Я понимаю, для современных высокопроизводительных машин это уже не так актуально. Но все же ...

Достаточно просто поднять приоритет thread-а, работающего с портом. И занятость машины не будет мешать.
Так что опять - причина только в кривости рук программиста.

[rx3apf]

Вангую, что и у Вас причина именно в неумении работать с COM-портом под виндой (или с UART на МК). И CP2102 - не при чём.
....
Так что опять - причина только в кривости рук программиста.

Дело было так - copy /b file com<n>

Всегда все работало (потому что пользовался FT2232) и PL2303. И вдруг - не работает. А адаптер-то на CP2102. Если копируемый файл где-то от 2 кило и выше - выпадают куски. Так что к кривым рукам - в MS или к драйверописателям из Silabs, моего-то тут ничего не было. То, что выходило с UART конвертора, я посмотрел - да, потеря данных. Пришлось вместо системной copy использовать свою утилиту.

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

Может быть, как-то зависит от конкретной системы...

Сообщение отредактировал rx3apf - Sep 23 2018, 11:10

[jcxz]

и PL2303.

А у меня были проблемы как раз с prolific. И не раз. Больше нигде не использую её.

Может быть, как-то зависит от конкретной системы...

Может стоило обновить дрова.

[rx3apf]

Может стоило обновить дрова.

Стояли свежие (2016). Можете попробовать повторить эксперимент самостоятельно (W7 x64, 115200). Хоть на бинарнике, хоть на текстовом, начиная с какого-то размера файла выпадают фрагменты. Строго на одних и тех же местах, с точностью до байта. Эффект воспроизводился как через "copy", так и через компонент axserial для vbs, с разными экземплярами USB-UART. Сделал в скрипте задержку из расчета 25 ms на 256-байтовый блок - все в норме (реально хватало и меньше, 25 для подстраховки, а 11% замедления было некритично).

[jcxz]

Стояли свежие (2016). Можете попробовать повторить эксперимент самостоятельно (W7 x64, 115200). Хоть на бинарнике, хоть на текстовом, начиная с какого-то размера файла выпадают фрагменты. Строго на одних и тех же местах, с точностью до байта. Эффект воспроизводился как через "copy", так и через компонент axserial для vbs, с разными экземплярами USB-UART.

У меня нет W7 (дома XP, на работе - W8). Да и думаю будет и под W7 нормально работать. Я использую очень много USB-UART. Часто - для логов (обычно на 921600) иногда по несколько шт. сразу. И ни разу не наблюдал никаких проблем с разными экземплярами своих CP2102 или FT232. А вот с PL2303 - наблюдал на нескольких экземплярах.
Возможно у Вас или сами модули кривые (где покупали? на али? я свои CP2102 покупал не на али), возможно там проблема с питанием. Или может проблема с питанием в том USB, куда втыкаете (проверяли напряжение, просадки? может запитать внешним источником?). Мои PL2303 которые глючат - они как раз с али.

[rx3apf]

Ну при чем здесь питание ? Данные ушли в драйвер, драйвер отдал по USB. Если не приостанавливать - теряются. Чуть приостановить (хоть в том же ритме 115200, но чтобы заведомо не чаще) - не теряются. Ненормальное поведение самого 2102 - увы, есть только с ali, проверить трудно. А, вообще-то на пути еще хаб есть, при случае без него проверю...

Будет желание и возможность - проверьте. Если протокол предусматривает квитирование (и наверняка блоки меньше, чем в моем случае), проблем, естественно, никогда не будет. Ситуация возникает, когда льется непрерывным потоком в темпе, заданном настройкой конвертора USB-UART, без какого-то внешнего управления потоком.

[jcxz]

Ну при чем здесь питание ?

Ну тогда вопросов больше не имею...
Питание вообще-то оно при всём.

Если протокол предусматривает квитирование (и наверняка блоки меньше, чем в моем случае), проблем, естественно, никогда не будет.

Прочитайте внимательнее, что я писал: "использую часто для логов". Т.е. - вывода отладочной текстовой информации. Никаких квитирований или управлений потоком естественно там быть не может.
И насчёт copy я не стал бы её принимать за мерило качества. Я не уверен что файловый вывод в COM-порты (да ещё не железные) под современными ОС эмулируется корректно.
Лучше испытывать на чём-нить типа putty или писать самому, через WinAPI.

[k155la3]

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

[rx3apf]

ило качества. Я не уверен что файловый вывод в COM-порты (да ещё не железные) под современными ОС эмулируется корректно.

Почему-то с другими адаптерами USB-UART никогда никаких проблем не возникало. И таки да, я проверил не только с "copy", сказал же уже.

Что до вывода логов - а почему, собственно, это исключает управление потоком, если источник поддерживает такое управление ? Чем лог отличается от любой другой передачи ? Вот только как-то я не очень представляю, чтобы лог лился непрерывным потоком на полной скорости по несколько килобайт.

Если в лог (на драйвер) выдать 3-4, то должна отработать буферизация на передающей стороне.

Должна (казалось бы). Но по факту - не работает. Наружу данные не вышли, до приемника не дошли. В том-то и "прелесть" ситуации...

[toweroff]

А не в том ли дело, что аппаратный UART на RPi3 скоммутирован на Bluetooth, а на ноги вытащен софтовый UART?
Можно при прочих равных попробовать перемаппировать AMA0 на пины и проверить результат
Меня однажды это спасло от странных и непериодичных глюков передачи

[jcxz]

Что до вывода логов - а почему, собственно, это исключает управление потоком, если источник поддерживает такое управление ?

Потому что источник лога - моя программа в устройстве. И мне известно что и как там реализовано.

Чем лог отличается от любой другой передачи ? Вот только как-то я не очень представляю, чтобы лог лился непрерывным потоком на полной скорости по несколько килобайт.

Так представьте. У меня через этот канал работает отладочная консоль. В ней у меня есть команды дампов разных массивов. И эти дампы - по несколько КБ. Потеря хотя-бы одного символа чётко видна - столбцы чисел сдвигаются.
Не понимаю - что Вы пытаетесь доказать? Я говорю что у меня с PL2303 были проблемы аналогичные первому посту (даже глазом видимые потери символов в логе, ну может реже только они были); с CP2102 таких проблем за все годы отладки не наблюдал. Вам виднее какие у меня были проблемы, а каких нет, что-ли?
У ТС-а ситуация подобная моим логам: он просто принимает текстовый поток данных.

[rx3apf]

Потому что источник лога - моя программа в устройстве. И мне известно что и как там реализовано.

А я привел пример ровно обратной ситуации. Когда поток генерирует PC, и этот поток до устройства не доходит, по причине CP2102 или ее драйвера.. Это два принципиально разных случая. Но то, что у ТС случай больше похож на Ваш - да, согласен.