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

[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 или ее драйвера.. Это два принципиально разных случая. Но то, что у ТС случай больше похож на Ваш - да, согласен.