Программное обеспечение для последовательной связи без ограничения скорости
Я бы использовал командную строку ядра (доступна в / proc / cmdline).
Если PXE и локальный жесткий диск (grub, lilo, extlinux) уже не отличаются, то сервер PXE может добавить дополнительный параметр, который никогда не присутствует при загрузке с локального жесткого диска. Кроме того, загрузчик с жесткого диска может ввести параметр, который не будет присутствовать при загрузке съемного носителя.
Конечно, это не сработает, если вы пытаетесь обнаружить преднамеренный неавторизованный метод загрузки, потому что злоумышленник просто добавит соответствующие параметры загрузки или просто изменит initrd.
В Linux Documentation Project есть раздел, посвященный последовательной связи, раздел 12 посвящен проблеме, с которой вы столкнулись. В основном это говорит о том, что 115,2k (иногда 230,4k )— это обычные настройки максимальной скорости в битах в секунду, но далее описывается работа -в -раунде, просто устанавливая максимальную скорость, и если ваш оборудование поддерживает выше, вы получите более высокую скорость. Все это кажется немного архаичным и скучным.
Теперь есть варианты более быстрого последовательного оборудования, например, RS485, I2C, SPI и даже I2S,... но они обычно выделены для аппаратного обеспечения и взаимодействуют на небольших расстояниях. (Кроме RS485 ).
Мне интересно, вы делаете это неправильно (используя usb ). Вот интересное обсуждение взаимодействия Raspberry Pi с Arduino .
Отредактируйте после того, как я выпил кофе и прочитал ваши отличные комментарии ниже.
@mosvy Дур! Да, вы абсолютно правы, LDP описывает настройку внутреннего UART и ничего не говорит о внешних последовательных -> usb-адаптерах.
@stiebrs, жаль, что я не включил RS485 в этот список, это не короткое расстояние. Но скорость и расстояние обратно пропорциональны. Re ftdi виртуальные порты,да, я также был удивлен тем, что эти константы скорости не изменились за последние 20 лет с тех пор, как я посмотрел на них, но вторая ссылка, которую я дал, обнаружила, что это не скорость передачи данных как таковая, которая привела к сбою Debian / Ubuntu, а скорее скорость доставки. Также они использовали свою собственную программу на C, которая не полагалась на стандартную утилиту. Приятно слышать, что вы решили эту проблему с помощью программы python.