jupiterВполне похоже на рабочее решение для нашего случая. Надо будет занаться изучением технологлии написания драйверов.

что то вы очень быстро оценили

AbstractionПод "системой реального времени" могут пониматься в том числе очень жёсткие требования .......


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

jupiter которое должно упровлять оборудованием в реальном времени, получать данные, сохранять их, отображать в удобном виде. В общем, классика.


Начните с частоты шины управления оборудованием.
прикиньте сможете ли вы обеспечить гарантированную сихронную или асинхронную ( выберете нужную)
реакцию вашего ПО на события в шине.

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

AbstractionДохтаРпропущено...


Начните с частоты шины управления оборудованием.
прикиньте сможете ли вы обеспечить гарантированную сихронную или асинхронную ( выберете нужную)
реакцию вашего ПО на события в шине.

В предыдущем примере система просто пропускала события в шине,
потому как опрос датчиков происходил не по событиям на шине ,
а тогда когда этого хотела программа на НЕТ.
Архитектор аутсорсеров посчитал ,
что запас по тактовй частоте в 50 раз между шиной датчиков системной шины компьютера
достаточен , что бы незаморачиваться с синхронизацией событий в ПО и в шине управления датчиками .Насколько я понимаю, там "реальное время" в том смысле, что GUI отображает состояние дел на устройстве с неразличимой для человека задержкой. Если понимаю неверно, всё может стать намного интереснее, вплоть до вывода о непригодности не только .NET, но и MS Windows, а то и процессора Intel.


Гуй если и при делах то коственно ,
ничего лишнего он вроде не отображать не должен.
А если отражает , то вобще тормоз будет.
РТ управление шиной должно происходить по маршруту
ПиСиАй- Процессор - Память- Процессор - ПиСиАй-Накопитель
Или ПиСиАй - ДМА - память -ДМА - накопитель.

Все что при этом будут ганяться по каналу ДМА-ПиСиАй -видеокарта
потенциально может стать тормозом реалтайма ,
даже невинное тягание мышей по экрану.
Какую временную непредсказуемость может внести
гарбарж коллектор я даже боюсь себе представить.

Я бы делал систему из 2 частей, одна машина только на реалтайме
на каком нубудь КуЭниКсе или РТЛ , с минимальным количестов устройств на шинах.
другая под чем угодно с гуем.

Для супер быстрой реакции ВэиКсВоркс ,
там ИМХО самую быструю реакцию можно получить,
но там многозадачность невытесняющая
и результат зависит от прямизны рук больше чем где бы то нибыло.