DMA and(or) Stream

[RU]

Здравствуйте!
Вы работали с DMA?
Вы писали потоковые драйвера?
Вы знаете как принимать от устройств большие объемы оцифрованной информации?

может... поможете разобраться как это делается?
С уважением RU.
Спасибо.

[Ochkarik]

велкам)

[RU]

ОК нет вопросов,
вопрос какой  RTFM читать?
А главное что делать если все делается с нуля, и этих M нету,
а возникает нужда в правильной организации работы с памятью и тд без тормозов. ?!
С Уважением RU

[dimm]

Может сразу задачу распишете, что за устройства предполагается использовать, откуда/куда данные будут гонятся, какой поток данных ожидается?

Я использовал DMA и передачу данных, но с готовыми платами DSP и ADC, там уже стояли фабричные PCI matchmaker-контроллеры.

[RU]

Здравствуйте! Извините за долгий перерыв.
Устройства на основе PCI карты,
поток данных {внешняя среда}-->[PCI]-->|Driver|-->{приложение Win}
скорость порядка ..150..200 МБит/с
С Уважением RU

[Ochkarik]

вариантов несколько. в обоих случаях, стоит выделить памяти, мегобайт под 16/32/64
писать из PCI по busmaster dma. - если все на кеш выровнять, ресурсы ЦП не расходуются.
далее вариантов несколько...
либо генерить прерывания на каждый записанный блок (желательно частотой не выше 50Гц, вобще машинка будет держать до нескольких кГц но ценой 50%загруженности проца).
либо по прерываниям еще и размер блока в I/O отдавать.
минусы -
   если скорость потока меняется в широких пределах, то время задержки будет соответственно гулять. кроме того железо сложнее.

так что рекомендую второй вариант.
заводите DPC по таймеру, герц на 20, счетчик  записанных платой данных(циклический) отдаете через I/O PCI платы. по каждому DPC вычисляете разницу (равна новым записанным данным) и т.д....
плюсы - система имеет одинаковую задержку (определяется частотой DPC) при любой скорости передачи. ISR не нужно вообще.
минусы -
   минимальное ожидание так же определяется частотой DPC. но с учетом переключений контекстов и пр, в любом случае время ожидания меньще нескольких мс не будет...
да, еще минус, если контроллер свой - там немножко с циклическим счетчиком подумать придется. особенно для случаев когда PCI транзакцию обрывает на середине.

самое простое- фиксированный размер блока по ISR.
лучшее по DPC и счетчику через I/O.
если действительно очень-очень критичны задержки нотификации драйвера о новых данных тогда ISR со счетчиком, но тогда надо помнить чтобы частота ISR не более 100-500Гц была)
мы пока отлаживались мне как-то 5кГц прерываний подсунули - это жесть просто)))

ну а в приложение просто отмапировать память со счетчиком)

да, сейчас памяти много ставят... проблем с выделением непрерывных 32/64МБ быть не должно... но если будут - советую выделять их при запуске винды по PNP старту и отпускать по PnP ремуву.

PS да, еще может конечно не хватить непрерывной памяти на 64/128МБ... тогда можно попробовать его уменьшить но сделать двойную буферизацию в второй буфер размером побольше... просто первый буфер чтоб железо не усложнять непрерывным в физ памяти должен быть, а второй - как угодно, с ним проще.
а памяти столько надо... потому что иногда есть пиковые нагрузки на проц в течении секунды-двух-трех примерно(окошко передвинул, прогу запустил), соответственно чтобы не терять данные, надо буферизацию увелчичивать..

прмерно так все обстоит.

PPS да, в любом случае рекомендую минимальный блок данных не менее 1/2/4к. лучше по 4) и железу проще, и вам, да и эффективность выше. movsd лучше работает.

[RU]

БОЛЬШОЕ Спасибо,
теперь стоит вопрос как прикрутить Stream и фильтры?

PS  Главный вопрос всеже где достать сопутствующую литературу и статьи.
PPS Неужели все знания предаются из уст в уста???

С Уважением RU.

[Ochkarik]

эээ... какие еще фильтры?
и что значит прикрутить Stream?
не знаю... все мои - из собственного опыта) ну процентов на 95...
литература... по драйверам тут на сайте кой чего выложено... по этому поводу веток уже много открывали, не хочется повторятся)
по железу... ну это все таки софтверный больше форум) мои знания о железе - весьма поверхностны, но весьма обширно))))

[RU]

Здравствуйте
"прикрутить" - использовать возможности
KStream, фильтров DirectShow итп для последующей обработки данных.

В ходе решения вопроса по поводу DMA возник еще один вопрос. Каким образом можно скидывать накопленные данные оптимальным путем учитывая скорость накопления?

С Уважением RU

[Ochkarik]

про KStream и DirectShow увы - ничего не знаю)
"скидывать накопленные данные оптимальным путем учитывая скорость накопления" - зависит от задачи? от обработки? от того, куда они дальше уходят?
про "учитывая скорость накопления" - не понял что имелось в виду... накопления - где?

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

[RU]

Здравствуйте!
Задачи:
1. Накопление данных (память, файл); !!!
и т.д.

Обработка:
1. Фильтр;
2. Статистика;
и т.д.

И конечная остановка сущего на PC, это файл, или утиль кому как нравится

-- при больших скоростях есть риск потерять часть данных, что не есть хорошо. Необходимо накопить требуемый обьем данных в памяти, если ее нехватает то сбросить данные в файл (проекция?).

--при каких условиях операции с DMA будут съедать CPU ресурсы?

С Уважением RU

[Ochkarik]

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