[jcxz 207]

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

Ну тогда вопросов больше не имею... :laughing:

Питание вообще-то оно при всём.

 

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

Прочитайте внимательнее, что я писал: "использую часто для логов". Т.е. - вывода отладочной текстовой информации. Никаких квитирований или управлений потоком естественно там быть не может.

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

Лучше испытывать на чём-нить типа putty или писать самому, через WinAPI.

[k155la3 26]

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

[rx3apf 0]

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

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

 

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

 

 

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

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

 

[toweroff 1]

А не в том ли дело, что аппаратный UART на RPi3 скоммутирован на Bluetooth, а на ноги вытащен софтовый UART?

Можно при прочих равных попробовать перемаппировать AMA0 на пины и проверить результат

Меня однажды это спасло от странных и непериодичных глюков передачи

[jcxz 207]

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

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

 

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

Так представьте. У меня через этот канал работает отладочная консоль. В ней у меня есть команды дампов разных массивов. И эти дампы - по несколько КБ. Потеря хотя-бы одного символа чётко видна - столбцы чисел сдвигаются.

Не понимаю - что Вы пытаетесь доказать? Я говорю что у меня с PL2303 были проблемы аналогичные первому посту (даже глазом видимые потери символов в логе, ну может реже только они были); с CP2102 таких проблем за все годы отладки не наблюдал. Вам виднее какие у меня были проблемы, а каких нет, что-ли?

У ТС-а ситуация подобная моим логам: он просто принимает текстовый поток данных.

[rx3apf 0]

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

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