Проблема кодключения к 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

[rx3apf]

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

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

[jcxz]

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

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

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

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

[rx3apf]

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

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

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

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

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

[jcxz]

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

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

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

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

[rx3apf]

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

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