Требуется система сбора данных в комп. Необходимо с частотой дискретизации до 2500гц получать аналоговые данные с ~60 дифференциальных каналов. Точности 12 бит вполне достаточно.
Есть куча решений в виде плат PCI/PCIex, но смущает размер буфера в 1-4к. Будут ли такие карточки обеспечивать непрерывный сбор данных под windows?
Пока нашел приличные платы от NI и Advantech, но хотелось бы подешевле.

Если PCI master - при правильно написанных драйверах будут. Если режима master нет, то таже при правильно написанных драйверах можно придумать ситуацию, приводящую к потере данных.

При правильно написанных и при отсутствии в системе неправильно написанных - сложно придумать такую ситуацию.
Это ведь нужно, чтобы DPC находилось в очереди несколько миллисекунд.
Ну а задержка больше 10 микросекунд на транзакцию - это очень глубокая PCI шина.

1.5 мс всего. Каналов то 60. А родной драйвер windows для com порта умудряется терять байты (очень иногда, но имеет место быть), уже на скорости 115200.

1/(60*2500*2/4)=13 микросекунд.

А если считывать сразу 128-битными родными для процессора типами, то еще в 4 раза больше.

У родной микросхемы компорта буфер всего 16 байт. Там реально меньше миллисекунды на обработку прерывания. Тоже в принципе достаточно, но первые драйвера от MS были сами очень кривыми. Посмотрите на примеры в старых DDK. Майкрософты не зря новую модель драйверов придумывали, так как правильно написать WDM драйвер с нуля довольно сложно..

Я считал, за какое время 4 Кбайтный буфер переполнится. Это то же время, за которое заполняется 16 байтный буфер com порта. А он в XP иногда теряет байты. Так что ситуации, когда не обслуживается прерывание в течении 1.5 мс точно есть.

1/(2500*60*2/4096) = 13 мс Это порядок разницы.
Причины необслуживания прерывания в течение более чем миллисекунды могут быть самыми разными. Например, ошибки в самом драйвере. Например, невовремя лочит новые буфера в памяти.

Да, прошу прощения, обсчитался в уме. Это, кончено, резко снижает вероятность потери данных. Но тем не менее, если нужна надежность, я бы не стал закладываться и на 13 мс - именно из-за возможного наличия кривизны в других драйверах. По моему опыту, ошибка "переполнение буфера" исчезает полностью, если его хватает больше, чем на 100, а лучше 500 мс. Если меньше 100 мс, то при эксплуатации разными людьми на разных компьютерах иногда кто-то нарывается на переполнение.

Мастер с буфером 4К от этого всё равно не спасет. Инициирует обмен мастера всё равно ЦП, указав место в памяти, куда именно складировать данные.

Ну так при разумном подходе ему можно назначить мегабайтный, например, буфер. Еще лучше, если кольцевой.

Кольцевидность буфера не имет отношения к вероятности потери данных.

Возможность назначения мегабайтного буфера зависит от способностей аппаратного мастера. В любом случае, даже если аппаратный мастер позволяет использовать очередь пересылок, инициируемых по событию на плате без вмешательства ЦП, это существенно усложнит его настройку по сравнению с классическим описанным в учебниках для драйверописателей использованием DMA.

Косвенно имеет, так как не надо реинициализировать DMA по заполнению буфера.

Ну мегабайт - это по нынешним временам совсем не много. Правильное написание драйвера с точки зрения потери данных требует усилий, тут да.

Не имеет. Потому что из циклического буфера нужно считывать куда-то. Если не считать вовремя - данные будут потеряны. Правильное решение - цепочка буферов, передаваемых драйверу из пользовательского кода асинхронными IO вызовами. Очередной буфер локируется в памяти и добавляется в конец списка DMA. После заполнения буфера происходит прерывание и IO обмен с этим буфером комплитится.



IMHO идея явно противоречит KISS

Если начинать куда-то копировать по прерыванию при половинном заполнении, то запас получается нормальный. При Вашем предложении все равно возникает момент простоя DMA между выставлением прерывания и перезапуском DMA в новый буфер. Если этот процесс задержать, произойдет потеря данных. Ну или нужен более сложный алгоритм DMA с двумя или больше буферами, что есть эквивалент работы с кольцом.

А что такое KISS ?

Если DMA не поддерживает списки обменов, то всё равно размер обмена до прерывания без потери ограничен 4 килобайтами. ЦП должен успеть инициировать обмен для каждого 4-килобайтного буфера (или же 2-килобайтного полубуфера) заново. Если поддерживает - то всё равно, кольцевой там буфер или пинг-понг, или список буферов. С другой стороны, список буферов - это традиционно правильное решение, которое к тому же позволяет избежать лишних копирований данных в памяти. Данные в конце концов должен получить из драйвера пользовательский код.



http://en.wikipedia.org/wiki/KISS_principle

А откуда ограничение на 4 Кбайта ? В PLX, например, 16 мегабайт за раз можно передать. А кольцевой буфер легче реализуется вместо списков, если, например, логика DMA делается руками. Может, Вы какую-то конкретную реализацию контроллера имеете в виду ?

Ограничение на пересылку в 4 килобайта следует из размера памяти на плате.
Руками проще делается пинг-понг, чем полноценный кольцевой буфер. Но и для него обычно стартовый адрес очередного свободного буфера легко прописывается ЦП при обработке прерывания, превращая пинг-понг в список из двух буферов.

Так память на плате для DMA обычно вообще прозрачна - это FIFO на случай приостановки DMA. DMA шпарит со скоростью поступающих данных, длина ограничивается только физической длиной счетчика контроллера. Зачем же копить 4К, а потом спешно их выпихивать в шину ? Для реализации кольцевого DMA вообще кроме счетчика ничего не нужно, для двухбуферной схемы нужны доп. регистры. В серийных контроллерах, конечно, используются очереди DMA, поскольку это позволяет минимизировать пересылку данных. Но для низкосокоростной платы сбора данных можно и кольцо сделать для упрощения драйвера.

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

Допустим, кроме счетчика еще нужны пороги для генерации прерываний и контроль переполнений, чтобы знать, что данные запороты, в случае чего. И регистр адреса начала буфера - тоже. Нет большой разницы, один или два.




Вы знаете простой способ отдать пользователю указатель на кусок памяти в буфере, не аллокированного ранее самим пользователем?

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

Не знаю. Я сам программизмом под Windows стараюсь поменьше вообще не заниматься. Хотя вот последние пару месяцев пришлось разбираться - умер программист, программа большая, писалась и дописывалась около 8 лет, надо хотя бы разобрать все до состояния, когда можно поручить вновь взятому человеку.

Что, одно прерывание на весь буфер?
Не очень надежный контроль переполнения. При длительных задержках (а если переполнение произойдет - наверняка задержка будет длительной) переполнение таким образом детектируется ненадежно. Если я Вас правильно понял.

"Запустил один раз - и забыл" - так не бывает, так как всё равно есть поток запросов к драйверу от пользовательского кода.



Соболезную.
Желаю Вам всё же в программе успешно разобраться в конце концов.
Если там применены какие-то нестандартные приемы по передаче информации из драйвера в пользовательскпий код - это может оказаться непросто.

Ну можно в счетчик несколько лишних разрядов + сбрасываемый чтением залипающий старший разряд для 100% обнаружения переполнения сделать. Это всего пяток триггеров. Обычно при таком переполнении это уже все лишнее.

Запустил - имелся ввиду процесс DMA. Пользователю дальше только надо будет указатели отдавать / в буфер копировать.

В любом случае думаю, что на исходный вопрос человек ответ получил.

А мне кажется, что как раз нет.
Человек не спрашивал про возможность реализации, он спрашивал, про существующие платы.

Вроде мы тут уже с разных сторон рассмотрели, что 1 -4 К буфера не есть принципиальное ограничение, что его смущало.

Тем не менее, ответа на вопрос, что там на самом деле творится на этих существующих платах, нет.

Ну и названий же их тоже нет. Так что ответить невозможно. Так что предлагаю взять паузу до появления дополнительных вопросов или данных.

Как-то тема углубилась в написание драйверов )
Карты, например такие:
http://www.advantech.ru/products/PCI-1747U/mod_GF-HXGX.aspx
http://www.advantech.ru/products/PCI-1713U/mod_1-2MLGYK.aspx
http://sine.ni.com/nips/cds/view/p/lang/en/nid/14134
Буфер, кстати обычно указывается в кличестве семплов, а не байт.

Я тоже так считаю, но производители почему-то придерживаются иного мнения.

Судя по описаниям, все подходят. NI получше смотрится, но, думаю, и стоит с отрывом от остальных.