|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 21 Dec 2004 01:29:02
To : Zahar Kiselev
Subject : Re: драйвер
--------------------------------------------------------------------------------
2004-12-20, Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> пишет:
> Hello Ilya!
>
> Dec 20 20:20 04, Ilya Anfimov wrote to Zahar Kiselev:
>
> IA> А вообще, ioctl must die. Всё лучше представлять в виде
> IA> двунаправленного потока, с максимум одной OOB командой: reset.
> А как, если не через IOCTL, устанавливать настройки карты? Просто писать их в
> тот же файл устройства, откуда читаются данные? Технически возможно, но что-то
Да. Или не в тот же -- создать себе поддерево в /dev. Или создать
второй файл /dev/карта-ctl
> не приходилось слышать чтобы где-то так делалось...
plan9 рулит :-).
>
> IA> сетевизмы переориентироваться проще будет.
> В данном случае сетевизмов не предполагается. Во всяком случае - передачи
Это не значит, что их не будет. Ты дрова пишешь или где?
Кстати, не только сетевизмы. Порты на другие ОС, большинство языков
высокого уровня -- с протоклом из двунаправленного потока проблем
особо не возникнет. С ioctl будешь писать обвязки разной
степени кривости.
> исходных данных с карты - точно. Построенный график начальству на email
> послать после завершения экспериментов - другое дело. Правда надо еще научить
> это начальство смотреть графики, представленные не в виде бумаги.:) порция
> данных может там остаться с момента предидущего чтения - ведь карта
> "наполняет" буфер асинхронно по отношению к читающей программе... Сбрасывать
> по каждой команде. Допустим команда чтения опустошит буфер от накопленных
> _готовых_ пакетов по N
По каждой управляющей команде. То есть читаешь честный кольцевой буфер,
о размерах пакетов при обычном чтении пусть читатели заботятся -- ты
отдаёшь всё, что сможешь, в следующий раз отдаёшь со следующего байта
(не числа, не пакета, а именно байта). Единственное исключение -- имеет
смысл при перполнении, если тебе не надо что-то иное, пропускать
что-то кратное законченному пакету данных.
При получении команды (ну там, АЦП как-то перестроить, формат выдачи
поменять) -- сбрасываешь свои буфера, при следующем чтении всё
начинается заново.
Если сбрасывать по любой команде неприемлемо -- либо раздели команды
на те, которые сбрасывают и те, которые не сбрасывают, либо организуй
схему преобразования буфера от старого варианта к новому. btw если данные
в буфере всегда в одном формате, определённом характеристиками
железки -- тебе придётся преобразовать только
указатель текущей позиции.
> байтов. Hо последний пакет может быть к этому моменту еще не готов(незаполнен
> до конца). Убивать его нельзя, читать - тоже. Получается довольно сложная
> обработка в драйвере. То есть фактически _символьное_ устройство придется
> заставить выдавать данные _блоками_. Hасколько я знаю - что-то подобное
> делается в драйверах карточек видеозахвата - там один пакет данных равен
> одному (полу)кадру. Делать также?
Да. По-любому также. Такое делается в большинстве символьных
устройств, в тех же raw hdd.
>
> >>
> >> Если делать драйвер только под данное конкретное применение этой платы
> >> - то можно конечно "прибить гвоздями" настройки и исходя из этого писать
> >> работающую с драйвером программу.
> IA> Hихрена не понял -- что ты собрался прибивать гвоздями?
> Количество каналов например - и соответственно - размер пакета выдаваемых
> данных. Hу-ка представь себе буфер в драйвере, под переменный размер пакета
> данных, задаваемый через IOCTL? Кода для обработки получится столько, что
Представил. И что такого? один kfree/kmalloc по ioctl. Думаешь,
for (i=0; i<32; i++) {
if (requested[i]) {
outw(cmd, CMD_GETVAL);
outw(out, i);
*buf++ = inw(inp);
outw(cmd, CMD_GETERR);
outw(out, i);
adc_error[i] |= inw(inp);
};
outw(cmd, CMD_ADVANCE);
};
Сожрёт ли это у тебя нехреново тактов по сравнению с
чем-то функционально эквивалентным, прибитым гвоздями?
Кстати, про вариант единого буфера и конвертации по read я уже
предлагал. В случае с DMA -- единственный вменяемый вариант.
> быстро работать оно точно не будет. Данные-то в буфер должны писаться по
> прерыванию от платы. А неумеренно длинный обработчик прерывания - верный путь
> огрести повисы в непредсказуемые моменты времени(от минут до часов). Проверено
> на собственной шкуре еще лет десять назад.
Какой, нафиг, длинный? Я этот абзац прочёл после того, как
написал тот скелет. Что ты там гвоздями собрался? Собственно,
даже конвертация чисел внутри прерывания во что-нибудь другое
погоды не сделает. Один switch и один преобразователь.
> Если сделать пакет всегда максимально возможным и просто игнорировать его
> пустой хвост в userlevel-программе если не нужен - то это увеличивает загрузку
> машины на бессмысленную перекачку нулей и лишает возможности производить
> измерения быстрых процессов, используя меньшее количество каналов. У АЦП
> вообще-то время преобразования 1.7мкс, так что если мерить одним каналом(без
> переключения входного коммутатора) - можно сигнал килогерц в 200 оцифровать.
200 килогерц, по два байта на канал -- это поток в 400kb/sec.
Как ты думаешь, сколько раз может пропустить через себя этот
поток даже весьма хилый сегоднышний поц?
hint: P200 иногда позволял смотреть видео DivX. Если
предположить, что картинка там 400x400x20cps, то это 4.5Mb/sec.
При этом оно успевало где-то два раза скопироваться, причём один
из них -- в видюху. Да, там MMX и всё такое, но там ещё
какая-никакая математика в процессе.
> Сейчас оно вроде бы не надо, но вполне может потребоваться в будущем. Так что
> я сразу пытаюсь не писать длинного кода там где он должен выполняться
> за ограниченное время, а также не использовать циклического опроса(например
> бита готовности - если не готов - делаем что-нибудь другое, а не ждем, потом
> снова проверяем). Zahar(@spbdept.rbc.ru) Остров Большой Березовый:
> http://birch-island.spb.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
