Драйвер для 6 UART на PCI шине, как быстрее поднять? Опции

[Hoodwin]

Имеется плата PCI, где на ПЛИС сделаны 6 UART с драйверами RS-232. Написана PCI функция, которая управляет шестью UART 16550A, тоже самописными. Все это более менее проверялось раньше по отдельности, но теперь вот есть желание запустить порты из-под линукс. Особенность платы в том, что она позволяет делать резервирование RS-232, то есть кроме самого UART 16550 каждый порт имеет логику, которая управляет выключением микросхемы соответствующего драйвера RS-232. Эта логика имеет определенные настройки, которые определяют правила отключения драйвера в зависимости от состояния внешних сигналов.

Все UART представляют собой стандартные 8 регистров, которые расширены нулями до 32-битных слов и размещены в одном BAR по смежным адресам.

Собственно интересует наиболее простой путь подружить линукс со всеми 6 портами. Пока представляются следующие способы:
1) Писать с нуля PCI драйвер ос своими PID, VID.
2) Подсмотреть готовые конфигурации UART в исходниках драйверов линукс, и изменить PID, VID своего устройства в соответствии с подходящим профилем из поддержаных.
3) Написать свой минидрайвер, который будет находить устройство на шине PCI и регистрировать его UART'ы как serial8250 platfrom_device. После чего его и линукс сам подхватит.

Если делать свой драйвер (модуль), то можно в нем зарегистрировать атрибуты портов, чтобы можно было настраивать правила его резервирования. Не уверен, можно ли это сделать, если пытаться подстроиться под существующий драйвер для шины PCI.

[Hoodwin]

sasamy

Ну, вот раньше в CheckIT были тесты ком-портов, которые проверяли правильность работы UART-а. Например:
1) Правильность логики установки статусов внешних сигналов
2) Правильность работы механизмов RTS-CTS
3) правильность работы флагов прерываний на передачу, прием данных и таймаут приема,
4) Правильную работу регистров MSR, LSR.
5) Правильную работу контроля четности.
6) Отсутствие пропадания прерываний при скоростном обмене.
7) Точность бодового генератора.

Короче говоря, интересен некий формальный тест, выдающий на выходе да или нет. И если нет, то какая именно проверка не прошла. Причем не нужно много кнопок давить, запустил программу с именем терминала и все, тест пошел.

К сожалению, я не смог найти внятного описания как правильно работать с FIFO в через драйвер 8250. Точнее, как управлять его настройками. Судя по коду, драйвер сам принимает решение об использовании FIFO, исходя из типа UART. Ну например, для стандртного UART 16550A выбирается FIFO threasholds 8 и все. Ни разу не видел, как через stty это скорректировать. И даже просто как посмотреть, то что есть по факту, не особо описано. В QNX и то куда более внятно было расписано.

[sasamy]

Ну, вот раньше в CheckIT были тесты ком-портов, которые проверяли правильность работы UART-а. Например:

Таких тестов скорей всего не найдете - если только у производителей многопортовых плат на сайтах рыть

7) Точность бодового генератора.

и типа можно верить этим измерениям ? лучше измерить осцилом - посылать в порт число 0x55 и смотреть частоту.

драйвер сам принимает решение об использовании FIFO, исходя из типа UART.

зачем пользовательским программам управлять размерами аппаратного FIFO - чтобы отключить, указываете тип уарта без FIFO (16450) в setserial.

Сообщение отредактировал sasamy - Nov 26 2013, 20:07

[Hoodwin]

Таких тестов скорей всего не найдете - если только у производителей многопортовых плат на сайтах рыть

Жаль, я думал, в линуксе подобные вещи есть.

и типа можно верить этим измерениям ? лучше измерить осцилом - посылать в порт число 0x55 и смотреть частоту.

Не вижу принципиальной разницы, чем мерить. Точность и стабильность бодового генератора не зависят от делителя, поэтому для измерений можно взять скорость ну хоть 9600. Но зато на такой скорости можно обеспечить выдачу подряд большого количества байт без зазоров, и измерив время передачи можно вполне точно измерить время одного бода. Осциллограф сам по себе довольно неточно меряет частоту, даже для периодического сигнала типа тактовой частоты он может выдавать значения с разбросом около 1%, если не больше.

зачем пользовательским программам управлять размерами аппаратного FIFO - чтобы отключить, указываете тип уарта без FIFO (16450) в setserial.

Ну вот, например, у нас был один проект, где протокол был так устроен, что передавались посылки по два байта, с периодом в 20-30 байтовых интервалов. В протоколе не было никаких признаков первого байта, за исключением того, что он первый после паузы. И вот когда сели делать через /dev/ser* (дело было под QNX), то выяснилось, что никак нельзя гарантировать синхронизацию по первым байтам. Тогда включили FIFO с порогом 4, и стали ловить прерывания по таймауту данных. С помощью этого прерывания синхронизацию удалось восстановить. Таким образом, аппаратные особенности UART вполне могут играть ключевую роль при программировании решения. Конечно, можно сказать, что берите и пишите для такого случая специальный драйвер. Можно было бы согласиться, однако в случае многопортового устройства появляется нюанс. Как поределить какой порт к какому драйверу приписывать. Обычно все порты автотматически цепляются каким-то одним драйвером.

[Tarbal]

Как поределить какой порт к какому драйверу приписывать. Обычно все порты автотматически цепляются каким-то одним драйвером.

Драйвер будет один, но устройства разные. Драйвер всегда знает с каким устройством он работает в данный момент.