Проблема кодключения к 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, без какого-то внешнего управления потоком.