спасибо всем большое! пойду разбираться и делать

2boolean34: эх, давно ж не брал я в руки шашку!  В своё время съел стадо собак именно на реальном времени в GNU/Linux. Помогу чем припомню 

Итак, для начала краткое лирическое отступление. Следует сразу же сказать, что получить по-настоящему жёсткое реальное время с применением GNU/Linux на платформе х86 возможным не представляется. Поэтому если задача стоит именно такая, лучше сразу приступить к рассмотрению платных проприетарных решений. Мне, как соратнику Столлмана, больно и обидно говорить такое, но против фактов не попрёшь - из свободного и/или бесплатного ПО выбирать нечего. Продолжим.


Сразу же проведём черту относительно того, что разрабатывается - модуль ядра или прикладная программа? Ибо разница принципиальная!


Опять же, смотря что разрабатывается. Для прикладной программы, работающей в режиме мягкого псевдо-реального времени, можно обойтись малой кровью, взяв стандартные RT-патчи и предельно "заточив" ядро под железо. Как именно - см. ниже. Если предполагается модуль ядра, то стоит присмотреться к RTAI - это набор из патчей ядра и библиотек прикладного уровня. Прелесть RTAI в том, что в неё входит набор драйверов реального времени для стандартных девайсов, например для RS-232 и некоторых сетевых карт. Драйвер пишется с использованием интерфейсов, предоставляемых RTAI. Ещё есть xenomai, но про него ничего толкового сказать не могу, ибо не юзал.


Да, возможно. Как показывает практика, лучше всего использовать дистрибутивы, предоставляющих минимальный набор ПО - меньше придётся прилагать усилий, чтобы выпилить лишнее и создать из них ОС реального времени. Лично я собирал машинки в основном на базе Slackware.


Исходя из практического опыта, получить такое время отклика при заданных условиях (GNU/Linux, x86) не реально. В силу причин как аппаратных, так и программных. К примеру, один только лишь RS-232 даёт время отклика порядка 5 мкс - и это из режима реального времени работы процессора и с запретом прерываний, т.е. когда программа выполняется полностью монопольно.


Можно выбирать что нравится, но разработка должна вестись, разумеется, на отдельной машине. На машине с ОС РВ не должно быть ничего лишнего (см. ниже).


С ними проблем не возникает, даже с самыми дешёвыми контроллерами.


Зависит от настроек - если всё сделать правильно, то программа берёт процессор в практически монопольное использование.


Очень сильно зависит от задачи. В любом случае не стоит забывать, что самыми тормозными местами становятся контроллеры ввода/вывода - сколько бы ни было ядер, потоков и процессов, единственная сетевая карта или контроллер RS-485 всё равно не смогут разделиться чтобы хватило на всех. Поэтому расклад примерно такой. Предположим, что у нас резервированная система, работающая по Ethernet, сиречь две сетевых карты в системе, по одной на канал. В таком случае можно либо запустить два экземпляра программы, отдав каждому по карте - если взаимодействия между каналами не предполагается. Если же требуется переключаться с канала на канал, лучше запустить один экземпляр программы и уже в нём - два потока, по одному на каждую сетевую карту.

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

Источник первый - аппаратное обеспечение. Архитектура х86 - худшая вещь, какую только можно придумать для РВ! Ибо в ней есть такие великолепнейшие грабли, как SMM, накорню зарубающий саму суть реального времени. Вкраце: что бы ни было запущено на машине, она в любой момент может на некоторое время "уснуть" по возбуждению SMI, и ни одна запущенная программа (включая ядро) этого даже не заметит. Выпилить SMM полностью или замаскировать SMI нельзя, можно только сильно заточить железо, отключив всё, потенциально генерирующее SMI. Список будет достаточно обширным:
- все системы управления питанием: ACPI, динамическое управление частотой процессора, управление кулерами и т.п.;
- все виды многоядерности (hyper-threading и пр);
- все неиспользуемые устройства;
- USB;
Далее, другой крайне неприятный баг - нестабильность системного таймера, т.е. нестабильность хода времени. Причём конкретное значение нелинейно и меняется от машины к машине. Чтобы обеспечить действительно надёжный ход времени, требуется:
- использовать железо, поддерживающее HPET (и, естественно, не забыть включить его поддержку в ядре);
- корректировать время по внешнему сигналу, подаваемому с генератора;
Например, подаём на один из сигнальных входов RS-232 прямоугольный сигнал частотой 10 Гц. В программе отлавливаем изменение состояния сигнала и соответственно подтягиваем ход времени внутри программы, которое считается RT-таймером. И не следует забывать, что внешние сигналы тоже могут пропадать. Следовательно, нужно грамотно проектировать алгоритм расчёта времени.

Источник второй - ПО. GNU/Linux изначально планировался как система для десктопов, для обычных людей, и достиг в этом немалых успехов. Однако для РВ он подходит слабо. Поэтому чтобы получить сколь-нибудь приемлемый результат, требуется:
- сразу же забыть о любой графике, даже о framebuffer: можно лепить гномокеды и кедогномы сколько угодно и куда угодно, но только не на машину РВ;
- убрать абсолютно все фоновые процессы кроме критически необходимых: именно поэтому я брал за основу Slackware, т.к. не в её привычках тащить с собой гору ненужного барахла и втихаря запускать чего вздумается в любых количествах, что обожают делать все т.н. user-friendly дистры;
- сразу же забыть о свопинге: в системах РВ свопинг не должен использоваться ни при каких условиях, никогда и нигде. свопинг следует выпилить из ядра и принудительно запретить из запускаемой программы;
- включить в ядре: вытесняющую многозадачность РВ (решается RT-патчами или RTAI), планировщик ввода/вывода поставить по-умолчанию на FIFO, установить системный таймер на максимальную частоту (1000 Гц или выше);
- выпилить из ядра абсолютно всё железо, которое отсутствует на данной конкретной машине или отключено в соответствии с приведёнными выше рекомендациями по настройке железа;
- выпилить из ядра абсолютно все не нужные и не используемые подсистемы - к примеру, SMP, гору файловых систем, фаервол и т.д. и т.п.;
- драйверы устройств в виде модулей ядра можно оставить только если важен порядок их инициализации - к примеру, сначала запускается контроллер RS-232, потом первая сетевая карта, потом вторая. для всех остальных нужных устройств драйверы лучше встроить внутрь ядра;

В целом, политика настройки железа, ПО и ядра должна быть следующая - отключить, запретить и по возможности выпилить абсолютно всё лишнее. Никаких "заделов на будущее", "если вдруг чего" и т.п.! Один раз установленный и отстроенный дистрибутив можно спокойно клонировать с машины на машину, по необходимости добавляя или удаляя нужные мелочи. Однако ядро всегда должно затачиваться под конкретную машину, конкретное железо, которое на ней установлено.

Получилось несколько сумбурно и, естественно, не в полном объёме. Однако, надеюсь, не без пользы 

Это сообщение отредактировал(а) rsm - 21.4.2012, 03:41

спасибо  большое за ценные советы! 

А еше есть RTOS QNX )))

Есть, и неплохо работает. Но у неё есть две очень злокозненные особенности:
а) QNX соответствует POSIX только частично: простой перенос исходников либо не компилится вообще, либо компилится прекрасно, но работает совсем иначе;
б) разработка под QNX это как жизнь в Австралии: практически все системные вызовы асинхронны, с точностью до наоборот относительно GNU/Linux;
Обе особенности вполне логичны, закономерны и объяснимы, если вспомнить, что QNX это ОС действительно РВ. Однако к ним требуется привыкнуть, всецело проникнуться ими и начать проектировать программы по иным принципам.