Я думаю что несколько непрофессионально разрабатывать платы ЦАП/АЦП и поставлять их с драйверами под DOS и Windows. Конечно поковырять Windows каждый дурак может, но верхом наивности будет использование этой ОС для сбора данных и надежного управления. По моему на сегодняшний день альтернативы QNX в качестве ОС  для лабораторных измерений просто не существует. Ведь это Real Time OS! В моей лаборатории стоят только QNX и Linux, и я не вижу причин ставить Windows. Системы надежны и просты в обращении, нужно только привыкнуть. Вы только представьте систему для эндохирургии под управлением виндов! Да это же кошмар для пациента если вдруг окошки синий экран выкинут прямо во время операции. Так что большая просьба: больше драйверов хороших и разных!

Вообще-то под наши новые PCI платы (L-7xx) мы драйверы под Linus поставляем. Более того, часть наших клиентов ими даже пользуется

А как же RTX от VenturCom?

Я бы так сразу не говорил, что написание драйвера под НТ - задача для дураков.

Другое дело, что чистая NT(без RTX), как и чистый Linux(не rtlinux) не являются real-time systems. Их архитектура принципиально не позволяет решать подобные задачи.

На мой взгляд, Lcard не ставит своей целью написание програмного обеспечения для истино real-time систем таких как QNX или, например, OS-9 - слишком мало таких покупателей.

Их основной рынок  - владельцы PC под управлением WinX, частично Linux. Я думаю, что они не пользуют платы Lcard на верхних границах их рабочих параметров. А для других применений Видны неплохи, и с этим можно согласиться.

Проблемы с Lcard возникают когда вы хотите построить real-time систему сбора И обработки данных, которая критична к потерям данных(пропускам отсчетов)

Метод проверки DMA countera в цикле не выдерживает критики. Это может быть и подойдет для системы сбора данных. Но для системы, которая должна еще их и обрабатывать такой подход неприемлем. И это тянется со времен ДОС.

Но Lcard не ориентируется на такие задачи.
Ищите другого производителя или пишите ПО(драйвера) сами. Так как у меня продукция Lcard уже была, то я выбрал второй путь.

1. Проверка DMA counter не обязательна, для всех плат в lbios есть возможность генерировать прерывание по факту ввода по ПДП определенного числа отсчетов. Это сделано именно для облегчения real-time обработки.
2. Для PCI плат идеология  real-time заложена изначально. Основная проблема под Windows - это проблема real-time управления, когда надо не только регистрировать данные без потерь, но и управлять - вот тут все прелести Windows делают решение этой задачи практичнески невыполнимой.
3. Насчет QNX и OS-9 истинная правда - реальный процент обращений с вопросами о поддержке QNX и OS-9 практически отсутствует.

Скажите, где можно поподробнее почитать о WinNT+RTX, rtlinux и т.д.

www.rtlinux.org - about rflinux
www.vci.com - about RTX
See www.qnx.com for info about www.qnx.com

Уважаемый Vlad.
Я хотел бы уточнить вопрос о DMAcounter

В библиотеке lbiosdrv.asm для ДОС функция get_buffer_half занималась этим опросом.
Она упорно читала DMAcounter.

При использовании драйвера ldevisa.sys синхронизация производится в потоке который отслеживает заполнение буфера (значения Sync).

Sync, по всей видимости инициализируется драйвером, который пользует HalReadDmaCounter.
В результате загрузка процессора - 100% при исполнении test.exe из примеров
Если будут другие потоки, то система будет делить время соответствующим образом. Но в этом случае у нас все шансы пропустить нужное нам значение DMAcounter, а то и вообще половину буфера

Конечно NT не real-time система, об этом даже речи нет.

Скажите, пожалуйста, действительно ли, например, на Athlone 650 под NT4 с 128kb dma_buffer (L305 с одноканальным вводом на 300кГц) невозможно поймать прерывание о заполнении половины этого буфера, обработать его (скопировать данные в другой буфер) и заняться другими делами (обработкой полученных данных)?

Если невозможно, то (мне) не стоит терять время на написание драйвера, а сразу заняться работой под RTX (я все же надеюсь, что это не так)

-----------------------------------
Исправления к предыдущему сообщению:
See www.qnx.com for info about QNX

Значит так.
В драйвере под нт данные собираются по прерыванию.
При этом возможны два способа чтения данных с платы:
1 чтение данных с платы в обработчике прерывания
2 копирование данных и буфера пдп в обработчике прерывания
Пользователь имееет дело с программным буфером и программным
счетчиком. Читать каунтер приходится из-за того
что сообщение которое можно послать из DPC идет слишком
медленно и на высоких скоростях сбор становится невозможным.
На низких скоростях можно пореже читать каунтер установив Sleep.
По поводу производительности и времени реакции прерываний
есть хороший документ на сайте www.numega.com White Papers
Windows 95 Interrupt Latency - под нт ситуация приблизительно такая же - я проверял.

+ то что показывает загрузку в нт 100% это неправда - врет он.

Есть ли ограничения на размер памяти выделяемой функцией RequestBuffer?

В ПО нет.

Мы давно используем L-1221 в QNX4.
Для этого перенесли из ассемблера в С некот. функции для этой платы...

Ну и как там драйвера пишутся, тяжко или нет?
Сколько времени вы затратили на написание драйвера? Писали ли софтень для ADSP или пользовали готовое. И, если не секрет, какие функции портировали(из лбиос.асм как я понимаю)

Буду премного благодарен если Вы ответите.

В QNX не обязательно писать драйвер как компонент ОС. Т.к. в QNX все задачи общаются через сообщения - мы написали свою прикладную задачу, которая ведет обслуживание L-Card платы и отвечает на запросы - сообщения. Это что-то вроде сервера, отвечающего клиентам, по протоколу, известному и клиентам, и серверу.

Длительность написания как всегда зависит от квалификации и от решаемой задачи...

Спасибо

Между прочим, хотя OS/2 и не позиционируется как real-time ОС жесткого времени, ее ипользование в качестве real-time "мягкого времени" вполне даже ничего,
хотя что такое "мягкий риалтайм" в OS/2 стоит несколько пояснить на примерах.
Хотя стоит заметить, что возлагать функции жесткого риалтама на PC есть иделогически неправильно.
Жесткое время должны отрабатывать или механика ;-) или жесткая логика, или контроллеры типа L780.
Компьютер должен складывать или выдавать данные контроллерам и общаться с пользователем или другим компьютером.

В OS/2 вполне реально выполнение таких задач, как управление приводами/клапанами, технологическими комплексами и т.п.
Начиная с таких дурных, но показательных вещей, как управление шаговыми дригателями с LPT порта посредством выдачи двух меандров  с частотой до 2000Гц (выше двигатель не работал ;-)  При этом никаких драйверов не использовалось, миллисекундный таймер не использовался, задачи в фоне и GUI продолжали работать, хотя и подтормаживали слегка.

Я работаю в ОС QNX уже более 3х лет
и с точки зрения управляющей ОС для
конкретной задачи удобнее мало что встречал.
Задача обрабртка радиолокационноий информации
в реальном времени, частоты на входе платы
АЦП до 10 МГЦ с помощью FPGA производится частичная обработка и в компьютер.
а там отрисовка сигналов в графике.

Рискуя вызвать в народных массах негодующие крики и обвинения в глупости и бахвальстве, все же скажу что с применением изделий L-Card(мастдай! извините-не удержался) у нас в лаборатории создана система которая в  реальном времени пишет информацию по 64 каналам с частотой ~3кГц (по каждому каналу!), контролирует параметры вводимых сигналов и может параллельно отображать несколько графиков на экране. все это работает на P166/16 под Win95|98 и если одновременно не пытаешься играть в QUAKE то все идет неплохо.

гм...
Вот наши последние достижения:
на TTL выходы подается некий цифровой 2D сигнал, 16 бит плюс 2 бита стробы,
L780 занимается аппроксимацией Брозенхейма с задержкой на точку порядка 2.3 микросекунды, из которых 0.5 - это длительность строба...все это на Си...ну еще и АЦП работает...
Так что OS/2 практически может заниматься чем угодно - хоть графики рисовать, хоть картинки... есть мысли приделать риалтаймовую анимацию процесса в OpenGL/'е ;-)

SY,
EK

Скажите, где можно почитать про написание драйверов к АЦП под Linux.

А Вы уже знаете, как пишутся драйвера для других устройств под Линукс? Если - да, то вопрос странен, если - нет, начинать нужно с общей идеологии линуксовских драйверов и готовой поддержки со стороны ядра.

Кроме этого, на сервере L-Card уже есть примеры драйверов под Линукс. Правда, не всегда они работают, но в качестве образца кое-что использовать можно.

По DC++ или EMule поищи книгу
linux.device.drivers-3.0

при беглом осмотре остался доволен тем как рассматривают написание драйверов под kernel 2.6 а точнее 2.6.10