|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 20 Dec 2004 22:47:52
To : Ilya Anfimov
Subject : Re: драйвер
--------------------------------------------------------------------------------
Dec 20 20:20 04, Ilya Anfimov wrote to Zahar Kiselev:
IA> А вообще, ioctl must die. Всё лучше представлять в виде
IA> двунаправленного потока, с максимум одной OOB командой: reset.
А как, если не через IOCTL, устанавливать настройки карты? Просто писать их в
тот же файл устройства, откуда читаются данные? Технически возможно, но что-то
не приходилось слышать чтобы где-то так делалось...
IA> сетевизмы переориентироваться проще будет.
В данном случае сетевизмов не предполагается. Во всяком случае - передачи
исходных данных с карты - точно. Построенный график начальству на email послать
после завершения экспериментов - другое дело. Правда надо еще научить это
начальство смотреть графики, представленные не в виде бумаги.:)
>> порция данных может там остаться с момента предидущего чтения - ведь
>> карта "наполняет" буфер асинхронно по отношению к читающей программе...
IA> Сбрасывать по каждой команде.
Допустим команда чтения опустошит буфер от накопленных _готовых_ пакетов по N
байтов. Hо последний пакет может быть к этому моменту еще не готов(незаполнен до
конца). Убивать его нельзя, читать - тоже. Получается довольно сложная обработка
в драйвере. То есть фактически _символьное_ устройство придется заставить
выдавать данные _блоками_. Hасколько я знаю - что-то подобное делается в
драйверах карточек видеозахвата - там один пакет данных равен одному
(полу)кадру. Делать также?
>>
>> Если делать драйвер только под данное конкретное применение этой платы
>> - то можно конечно "прибить гвоздями" настройки и исходя из этого писать
>> работающую с драйвером программу.
IA> Hихрена не понял -- что ты собрался прибивать гвоздями?
Количество каналов например - и соответственно - размер пакета выдаваемых
данных. Hу-ка представь себе буфер в драйвере, под переменный размер пакета
данных, задаваемый через IOCTL? Кода для обработки получится столько, что быстро
работать оно точно не будет. Данные-то в буфер должны писаться по прерыванию от
платы. А неумеренно длинный обработчик прерывания - верный путь огрести повисы в
непредсказуемые моменты времени(от минут до часов). Проверено на собственной
шкуре еще лет десять назад.
Если сделать пакет всегда максимально возможным и просто игнорировать его пустой
хвост в userlevel-программе если не нужен - то это увеличивает загрузку машины
на бессмысленную перекачку нулей и лишает возможности производить измерения
быстрых процессов, используя меньшее количество каналов. У АЦП вообще-то время
преобразования 1.7мкс, так что если мерить одним каналом(без переключения
входного коммутатора) - можно сигнал килогерц в 200 оцифровать. Сейчас оно вроде
бы не надо, но вполне может потребоваться в будущем. Так что я сразу пытаюсь не
писать длинного кода там где он должен выполняться за ограниченное время, а
также не использовать циклического опроса(например бита готовности - если не
готов - делаем что-нибудь другое, а не ждем, потом снова проверяем).
Zahar(@spbdept.rbc.ru) Остров Большой Березовый: http://birch-island.spb.ru
--- Msged/LNX 6.1.1
* Origin: N:60.17'54" E:28.39'40" (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
