Здравствуйте,
У меня такой вопрос. Я разрабатываю программно-аппаратный комплекс и столкнулся с проблемой: нужно каждые (минимум) 30-50 мс записывать данные на устройство и считывать его тоже с такой же дискретностью. То есть нужно, чтобы мой вычислительный поток получал управление каждые 30-50 мс, но это должно быть гарантированным.
Системы - Windows XP/2000/Vista.

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

И ещё: приоритет REALTIME для потока - не поможет?

Спасибо.

Ну раз "аппаратный", то, как минимум, прерывания еще никто не отменял. Да и мультимедийные таймера тоже

Так там проблема как раз в том, что из аппаратной части - карта сбора данных (то есть не собственная), поэтому реальное время нужно реализовывать на стороне обрабатывающего ПК (а он работает под ХР)...

Не собственная, это хорошо, только "собственные" приходилось видеть сделанные через... "не собственные", они для людей делаются, посему чего-нибудь типа прерываний, DMA, ..., как правило присутствуют. Учите матчасть. Даже если это вдруг действительно огрызок счастья, то 30-50ms это совершенно не время для Windows и в части обработки событий от собственных таймеров.

Копайте в сторону мультимедийного таймера. (кажись, библиотека mmsystem.dll)
Было дело - наткнулся на "реальное время" в XP. Через мультимедийный таймер получалось включаться каждые 2 мс, но периодически, когда другой процесс записывал что-то на HDD или гнал поток данных по сети, в моём приложении реальное время сыпалось. Задержки получались миллисекунд по 20...

Вообще XP и т.п. не обеспечивают реального времени, если не использовать расширения реального времени.

Смотрите в сторону RTOS. Оч. рекомендую посмотреть на Windows CE

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

Если ничего нет - проще сделать правильную плату сбора данных.


Для потока user mode - не поможет. Во всяком случае, драйвер должен тоже об этом позаботится.



А попробуйте в "эту область" въехать самостоятельно. Литература и примеры работающих драйверов доступны, за пару месяцев непрерывной работы при наличии пары компютеров и представления об архитектуре операционной системы (и согласии "играть по правилам" которые обязательны при написании kernel-mode программ) можете сделать устраивающее Вас решение (если есть документация на плату с описанием портов и правил работы с ними). И если разработчики предусмотрели прерывания.

Что за плата-то?

Спасибо, ребят. Ща сам покопаю.
Плата - дешевая ISA - ACL-8112DG и иже с ней...
Спасибо!

Вообще-то все упирается в то, какие временные интервалы и с какой точностью их надо обеспечивать...
Если 30-50 мс то вполне возможно:
do
{
sleep(30)
.............(обработка)
}
while(1)
поток в TimeCritical....
Период будет болтаться - 35-40 мс (учитывайте время обраьртки). По опыту знаю - Sleeep(Api32) дает погрешность 1-2 мс+ переключение контекста....(зависит от количества приложений, быстродействия...)
Если надо обеспечивать более короткие или более точно временные интервалы, то прерывания. Как правильно Вам подсказывают. В плате это должно быть.

Процедуры для работы с аппаратурой и синхронизации по времени выполняйте в отдельном потоке с приоритетом REALTIME. Под XP может оеспечить интервал 50-100 микросекунд и лучше. Материал есть на Specosoft и на WASM в "секретах WIN32" . Все на дельфи. Очень занятные статьи.
С УСБ в реальном времени из-за буферизации не получится, а вот для встаиваемых плат или для ЛПТ никаких проблем.

Естестественно, что эти приемы имеют реальное воплощение в экспериментальных установках безо всяких лишних дров и СИ.

Ни о каких деньгах на WASMе не говорят. Свободный сайт для свободных людей. Желаю удачи.

Windows не RealTime система, так что гарантировать не получится.
Поможет, (не забудьте и процессу поставить REALTIME), но гарантию все равно не даст.
Кроме того - 30-50мс для User Mode это слишком мало.

Смотрите в сторону Device Driver'а (и DPC в нем), но и это не даст 100% гарантию

Независимо от операционной системы в любом писюке есть часы доступные через порты. А их можно заставить генерить меандр вплоть до 1/8192 секунды.
Вам хватит и 1/32. Конечно в современном чипсете этого вывода давно нет, но включить прерывания по нему можно и запихнуть весь свой вычислительный поток в обработчик.

Независимо от порта, Windows не даст к нему прямого доступа. Кроме того, Windows может вообще откачать всю вашу программу по своему усмотрению.
Про прикладное приложение Windows можете сразу забыть

Пилите гири. Почитайте тщательнее статьи WASM.ru. Там как раз для инженеров и научных сотрудников, а не для бухгалтеров.

Если нужно поллить - на большинстве современных компов нормально работают мультимедийные таймеры.

http://msdn.microsoft.com/en-us/library/ms712713(VS.85).aspx

Нить должна быть с приоритетом реального времени, только следует учитываать, что такие нити при ошибках программиста очень хорошо подвешивают GUI, поэтому отладка на них требует аккуратности.

Это вы к чему? Чтение WASM.ru сделает из Windows систему реального времени?

Винды позволяют реализовать так называемый "soft realtime".

Угу, с некоторой натяжкой даже на User Level'е. Вопрос в том, хватит ли топикстартеру этого 'Soft'?

Однажды провели на FREE PASCAL лабораторную работу: разгоняли таймер по адресу $40 в реальном и защищенном режие (под DOS у этого паскаля есть аналогичные setintvec процедурки для защищенного режима).
В реальном режиме отрабатывалось 200 тыс. прерываний в секунду, а в защищенном балалайка захлебнулась на 30 тыс.
Или FREE PASCAL хиловат, или это от особенностей защищенного режима. А ОС сегодняшнего дня работают в защищенном режиме. Едва ли они обеспечат заметный выигрыш по сравнению с XP. Они все громоздкие. А которые не громоздкие - пусть посоревнуются с DOS 6.22, которая все еще работает во встраивамых системах

Это зависит от того, какой смысл он вкладывает в термин "гарантированные"? Может быть ему действительно нужна жесткая логика с тройным резервированием оборудования.



На AVR можно получить порядка миллиона - и что? Современные писюки рассчитаны для перемалывания больших потоков данных, а не на прерывания раз в микросекунду. Сброс кэшей может быть очень дорогой операцией, плюс на PCI/PCIe реальны задержки до нескольких микросекунд, через несколько мостов, так что чтение регистра таргета - дорогое удовольствие. Но когда речь идет про цикл 30 миллисекунд - тут несколько иное рассуждение. Гарантировать все же нельзя, но обеспечить выдерживаине времени с большой вероятностью возможно.