Несоответствие скорости последовательной передачи
Обработка этого как чистого текста -проблема обработки (т. е. игнорирование того факта, что имена файлов Unix могут содержать символы новой строки, что является причиной того, что вы обычно не храните пути в текстовых файлах, если не знаете, что они в порядке ), мы можем удалить что-либо после последнего символа /в каждой строке и получить уникальные результаты через
$ sed 's,/[^/]*$,,' 1.txt | sort -u
/lib/i386-linux-gnu
/usr/bin
Выражение seds,/[^/]*$,,(, которое также может быть записано s/\/[^/]*$//), удалит все, что соответствует /[^/]*$, т. е. косая черта, за которой следует любое количество не-символов косой черты (до конца строки. строка ).
sort -uв конце сортирует результат, сохраняя только уникальные записи. Если данные уже отсортированы, вместо этого вы можете использовать uniq.
Таким образом, можно предположить, что по какой-то причине ядро имеет неправильное представление о базовых часах, работающих на этой карте. Последовательные порты — это простые устройства, и я не удивлюсь, если у системы не будет стандартного способа узнать это с карты. По крайней мере, в некоторых контекстах конфигурируемая часть представляет собой делитель , применяемый к базовым часам, и для его получения требуется знать фактические базовые часы.
(На этой карте есть перемычки для установки максимальной скорости, так что, возможно, она каким-то образом сообщает эту настройку драйверу, который ее поддерживает.)
Во всяком случае, у setserialесть опция baud_base, и я предполагаю, что ее использование может помочь решить проблему вручную:
setserial /dev/ttyS1 baud_base 115200