мне нужно написать программный комплекс, работающий в режиме реального времени под управлением ОС Linux (расширение ядра). Язык С++. помогите определиться с инструментарием разработки, программной платформой + ссылки на литературу

тема слишком общая, надо требования точнее сформулировать. 
http://www.ibm.com/developerworks/ru/libra...eal-time-linux/
http://citforum.ru/operating_systems/articles/linuxrt.shtml
поможет в формулировках

спасибо за ссылки. 
вот беру ядро версии 3.0 скачиваю, что мне к нему прикрутить нужно, чтобы в итоге я имел пользовательский интерфейс, посредством которого я установлю среду разработки и начну реализовывать свои алгоритмы? 
возможно ли применение готовых ОС (убунту и тп)?

Это сообщение отредактировал(а) boolean34 - 17.4.2012, 13:00

все проще
ставите дебиан  + http://packages.debian.org/sid/rtai

спасибо, посмотрю 

кто знает, у кого опыт подскажите пожалуйста: могу я быть уверенным, что затратив время на установку настройку и тд  ОС Debian с патчем для реального времени получу желаемое:
1) операционную систему с откликом на прерывание порядка десятка микросекунд;
2) удобную IDE под С++ и библиотеки для создания прикладного приложения с развитым графическим интерфейсом;
3) отсутсвие проблем с коммутацией COM портов (стандарты RS 422/485)
                                                                                                                                                                                                     ??

за это время уже можно было установить и самому понять 


RT не дает временных гарантий в общем случае, т.к. это зависит от параметров аппаратуры. RT система имеет бОльшие накладные расходы, что требует более производительной системы.


есть любом дистрибутиве; могут быть установлены отдельно поверх любого дистрибутива. понятие удобства относительно.


не очень понятно что подразумевается под проблемами коммутации

Давайте начнем с того что в системе где более 1 активного процесса - реалтайм понятие условное )
Скорее всего ТС имеет ввиду тайминг процесса под некую аппаратуру. То есть наш процесс должен успевать сделать что то в строго отведенный временной интервал.
Несколько лет назад в одной конторе мы занимались такой проблемой, был аппарат (станочек лазерной маркировки).
И там нужен был реалтайм по ряду причин, удешевление аппаратной части станка, использование памяти и cpu компьютера для управления станком итд.
В результате было реализовано на мсдос )))  через com и lpt порты передавались данные и команды.
 

Это сообщение отредактировал(а) 500mhz - 18.4.2012, 13:30

да да, мне от аппаратуры обработки сигнала приходит пакет с данными каждые 2(примерно) милисекунды. 

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

и как лучше построить структуру программы: один процесс-много потоков, либо много процессов, каждый из которых соответствует определенному функциональному модулю ??

вообще-то и в не RT ОС управление передается ожидающему ресурс процессу, если ресурс освободился. т.е. если система не будет загружена другими задачами, все будет и под обычной ОС примерно таким образом, как Вы ожидаете.
Видимо Вам подойдет мягкая RT-система, вроде той что Вам уже рекомендовали.


мы не знаем, что должна делать Ваша программа. лучшей абстрактной "структуры программы" не бывает. что кроме обработки сигнала она должна делать? а когда она обрабатывает сигнал, то должна успевать это делать быстрее, чем сигналы приходят ;-)

ну имеется в виду, что принять пакет с данными надо по-любому, а их последующая обработка может выполняться "не спеша"




имеется  в виду, что модуль, который отвечает за прием сделать отдельным процессом с приоритетом №1 (задача реального времени);
остальные модули( модуль отрисовки, модуль интерфейса, модуль вычислений) также запускаем в виде процессов, соотв. образом координируя их взаимодействие (обмен данными), но уже  с обычным приоритетом

либо:
все сделать в виде одного процесса (один exe-шник), а уже внутри него несколько потоков. ??


Это сообщение отредактировал(а) boolean34 - 19.4.2012, 11:45

если я все правильно понял, здесь две задачи: сбор данных и их обработка (визуализация)
имхо есть смысл разделить их на два приложения. хотя бы для того, что бы надежность сбора данных не зависела от всего остального.
т.к. предполагается, что обработка будет происходить не спеша, данные где-то нужно хранить. Видимо на диске (в БД). Скорость записи данных в среднем должна быть выше скорости поступления данных. Возможно несколько последовательных пакетов данных можно объединить в один, это позволит снизить нагрузку на подсистему сохранения. А последующая обработка типа визуализации может производиться независимо, уже читая сохраненные данные.

удобно рассмотреть это на модели учета сетевого трафика: есть небольшой, легкий процесс, который реагирует на каждый сетевой пакет. Он производит начальную классификацию и суммирует однотипные пакеты. периодически (например 1 раз в сек) данные сбрасываются в БД. подсистема (приложение) отображения отчетов обращается к БД.
подсистема отображения текущего трафика может обращаться к первому процессу (например, тоже каждую секунду). для этого первый процесс должен обеспечивать какую-то реализацию IPC, например использовать разделяемую память.

boolean34
В любой "мультитаскинг" ОС время делиться на всех так как она якобы многозадачная, в мсдос все проще,запустил я свой ехешник и он "захапал" все процессорное время ,естественно за исключением всяких там прерываний и их обработчиков , к примеру ну там таймер или драйвер русской раскладки. И то все это можно тупо отключить и "хапать" 99,9% тайминга.

Добавлено через 1 минуту и 27 секунд
И еще вопрос, обмен данными между РС и железякой как сделан? По сети или по всяким там сом портам?

baldina
хорошо, буду читать литературу




через RS 485 , либо похожие промышленные стандарты (232-ой, и тп)

в портах есть такое поняте как http://ru.wikipedia.org/wiki/16550_UART так что дофига что в вашем случае завязано на железо которое будет в РС