2boolean34: эх, давно ж не брал я в руки шашку!  В своё время съел стадо собак именно на реальном времени в GNU/Linux. Помогу чем припомню 
Итак, для начала краткое лирическое отступление. Следует сразу же сказать, что получить по-настоящему жёсткое реальное время с применением GNU/Linux на платформе х86 возможным не представляется. Поэтому если задача стоит именно такая, лучше сразу приступить к рассмотрению платных проприетарных решений. Мне, как соратнику Столлмана, больно и обидно говорить такое, но против фактов не попрёшь - из свободного и/или бесплатного ПО выбирать нечего. Продолжим.
Цитата(boolean34 @ 17.4.2012, 10:15  ) | | работающий в режиме реального времени под управлением ОС Linux (расширение ядра) |
Сразу же проведём черту относительно того, что разрабатывается - модуль ядра или прикладная программа? Ибо разница принципиальная!
| Цитата(boolean34 @ 17.4.2012, 14:59 ) | | беру ядро версии 3.0 скачиваю, что мне к нему прикрутить нужно, чтобы в итоге я имел пользовательский интерфейс |
Опять же, смотря что разрабатывается. Для прикладной программы, работающей в режиме мягкого псевдо-реального времени, можно обойтись малой кровью, взяв стандартные http://www.kernel.org/pub/linux/kernel/projects/rt/ и предельно "заточив" ядро под железо. Как именно - см. ниже. Если предполагается модуль ядра, то стоит присмотреться к RTAI - это набор из патчей ядра и библиотек прикладного уровня. Прелесть RTAI в том, что в неё входит набор драйверов реального времени для стандартных девайсов, например для RS-232 и некоторых сетевых карт. Драйвер пишется с использованием интерфейсов, предоставляемых RTAI. Ещё есть xenomai, но про него ничего толкового сказать не могу, ибо не юзал.
| Цитата(boolean34 @ 17.4.2012, 14:59 ) | | возможно ли применение готовых ОС |
Да, возможно. Как показывает практика, лучше всего использовать дистрибутивы, предоставляющих минимальный набор ПО - меньше придётся прилагать усилий, чтобы выпилить лишнее и создать из них ОС реального времени. Лично я собирал машинки в основном на базе Slackware.
| Цитата(boolean34 @ 18.4.2012, 12:11 ) | | операционную систему с откликом на прерывание порядка десятка микросекунд |
Исходя из практического опыта, получить такое время отклика при заданных условиях (GNU/Linux, x86) не реально. В силу причин как аппаратных, так и программных. К примеру, один только лишь RS-232 даёт время отклика порядка 5 мкс - и это из режима реального времени работы процессора и с запретом прерываний, т.е. когда программа выполняется полностью монопольно.
| Цитата(boolean34 @ 18.4.2012, 12:11 ) | | удобную IDE под С++ и библиотеки для создания прикладного приложения с развитым графическим интерфейсом |
Можно выбирать что нравится, но разработка должна вестись, разумеется, на отдельной машине. На машине с ОС РВ не должно быть ничего лишнего (см. ниже).
| Цитата(boolean34 @ 18.4.2012, 12:11 ) | | отсутсвие проблем с коммутацией COM портов (стандарты RS 422/485) |
С ними проблем не возникает, даже с самыми дешёвыми контроллерами.
| Цитата(boolean34 @ 19.4.2012, 10:51 ) | | хочется более-менее строго оценить вероятность, что если поток в программе, который отвечает за прием, получит команду принимать, то все "обычные" дела отходят в сторону и выполняется критичная задача. ?? |
Зависит от настроек - если всё сделать правильно, то программа берёт процессор в практически монопольное использование.
| Цитата(boolean34 @ 19.4.2012, 10:51 ) | | как лучше построить структуру программы: один процесс-много потоков, либо много процессов, каждый из которых соответствует определенному функциональному модулю ?? |
Очень сильно зависит от задачи. В любом случае не стоит забывать, что самыми тормозными местами становятся контроллеры ввода/вывода - сколько бы ни было ядер, потоков и процессов, единственная сетевая карта или контроллер RS-485 всё равно не смогут разделиться чтобы хватило на всех. Поэтому расклад примерно такой. Предположим, что у нас резервированная система, работающая по Ethernet, сиречь две сетевых карты в системе, по одной на канал. В таком случае можно либо запустить два экземпляра программы, отдав каждому по карте - если взаимодействия между каналами не предполагается. Если же требуется переключаться с канала на канал, лучше запустить один экземпляр программы и уже в нём - два потока, по одному на каждую сетевую карту.
А теперь в общем и целом. Дальнейший текст будет наполнен любовью и обожанием к х86 и режиму РВ, выпившему немало крови и укоротившему жизнь на многие месяцы  Все возникающие проблемы делятся на две категории по источнику их возникновения.
Источник первый - аппаратное обеспечение. Архитектура х86 - худшая вещь, какую только можно придумать для РВ! Ибо в ней есть такие великолепнейшие грабли, как http://en.wikipedia.org/wiki/System_Management_Mode, накорню зарубающий саму суть реального времени. Вкраце: что бы ни было запущено на машине, она в любой момент может на некоторое время "уснуть" по возбуждению SMI, и ни одна запущенная программа (включая ядро) этого даже не заметит. Выпилить SMM полностью или замаскировать SMI нельзя, можно только сильно заточить железо, отключив всё, потенциально генерирующее SMI. Список будет достаточно обширным:
- все системы управления питанием: ACPI, динамическое управление частотой процессора, управление кулерами и т.п.;
- все виды многоядерности (hyper-threading и пр);
- все неиспользуемые устройства;
- USB;
Далее, другой крайне неприятный баг - нестабильность системного таймера, т.е. нестабильность хода времени. Причём конкретное значение нелинейно и меняется от машины к машине. Чтобы обеспечить действительно надёжный ход времени, требуется:
- использовать железо, поддерживающее HPET (и, естественно, не забыть включить его поддержку в ядре);
- корректировать время по внешнему сигналу, подаваемому с генератора;
Например, подаём на один из сигнальных входов RS-232 прямоугольный сигнал частотой 10 Гц. В программе отлавливаем изменение состояния сигнала и соответственно подтягиваем ход времени внутри программы, которое считается RT-таймером. И не следует забывать, что внешние сигналы тоже могут пропадать. Следовательно, нужно грамотно проектировать алгоритм расчёта времени.
Источник второй - ПО. GNU/Linux изначально планировался как система для десктопов, для обычных людей, и достиг в этом немалых успехов. Однако для РВ он подходит слабо. Поэтому чтобы получить сколь-нибудь приемлемый результат, требуется:
- сразу же забыть о любой графике, даже о framebuffer: можно лепить гномокеды и кедогномы сколько угодно и куда угодно, но только не на машину РВ;
- убрать абсолютно все фоновые процессы кроме критически необходимых: именно поэтому я брал за основу Slackware, т.к. не в её привычках тащить с собой гору ненужного барахла и втихаря запускать чего вздумается в любых количествах, что обожают делать все т.н. user-friendly дистры;
- сразу же забыть о свопинге: в системах РВ свопинг не должен использоваться ни при каких условиях, никогда и нигде. свопинг следует выпилить из ядра и принудительно запретить из запускаемой программы;
- включить в ядре: вытесняющую многозадачность РВ (решается RT-патчами или RTAI), планировщик ввода/вывода поставить по-умолчанию на FIFO, установить системный таймер на максимальную частоту (1000 Гц или выше);
- выпилить из ядра абсолютно всё железо, которое отсутствует на данной конкретной машине или отключено в соответствии с приведёнными выше рекомендациями по настройке железа;
- выпилить из ядра абсолютно все не нужные и не используемые подсистемы - к примеру, http://en.wikipedia.org/wiki/Symmetric_multiprocessing, гору файловых систем, фаервол и т.д. и т.п.;
- драйверы устройств в виде модулей ядра можно оставить только если важен порядок их инициализации - к примеру, сначала запускается контроллер RS-232, потом первая сетевая карта, потом вторая. для всех остальных нужных устройств драйверы лучше встроить внутрь ядра;
В целом, политика настройки железа, ПО и ядра должна быть следующая - отключить, запретить и по возможности выпилить абсолютно всё лишнее. Никаких "заделов на будущее", "если вдруг чего" и т.п.! Один раз установленный и отстроенный дистрибутив можно спокойно клонировать с машины на машину, по необходимости добавляя или удаляя нужные мелочи. Однако ядро всегда должно затачиваться под конкретную машину, конкретное железо, которое на ней установлено.
Получилось несколько сумбурно и, естественно, не в полном объёме. Однако, надеюсь, не без пользы |
