Система сбора данных, 60 дифференциальных каналов, дискретизация 500-2500гц Опции

[Клим]

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

[DS]

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

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

[Oldring]

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

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

[DS]

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

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

[Oldring]

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

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

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

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

[DS]

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

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

[Oldring]

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

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

[DS]

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

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

[Oldring]

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

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

[DS]

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

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

[Oldring]

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

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

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

[DS]

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

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

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

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

[Oldring]

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

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

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

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

[DS]

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

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

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

А что такое KISS ?

[Oldring]

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

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

А что такое KISS ?

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

[DS]

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

[Oldring]

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

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

[DS]

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

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

[Oldring]

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

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

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

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

[DS]

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

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

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

[Oldring]

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

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

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

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

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

[DS]

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

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

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

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

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

[Oldring]

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

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

[DS]

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

[Oldring]

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

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

[DS]

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

[Клим]

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

Как-то тема углубилась в написание драйверов )
Карты, например такие:
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
Буфер, кстати обычно указывается в кличестве семплов, а не байт.

Ну мегабайт - это по нынешним временам совсем не много.

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

[DS]

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