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


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

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


Не может.

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

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

Спасибо, aaarrr!

Использую minicom


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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



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

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

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


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

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