Точно равна нулю только глупость человеческая, даже заточенные под RT железки ломаются. Linux, в подходе Xenomai, вообще ни на что не влияет - он может даже зависнуть или находится в tripple-fault (oops) состоянии - RT как работало так и будет продолжать работать, проверено не раз. Если хочется гарантий "5 девяток" - делается резервирование. т.е. ставится 2-3 устройства как принято везде в авиа и военке.

На чем проверено? Примеры рабочих железяк можно?

В контексте данной темы был поднят вопрос о совместимости real-time и Линукса. Это как раз и пример.

Нет, это не пример.
Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов.
И с временем реакции не больше 2 мкс.
Сейчас такой стандарт для жесткого риалтайма в ARM Cortex

А кто вам сказал, что если используется Линукс, то все надо делать только программно? На любой системе такой подход иррационален. Я как раз и говорю о том, что надо делать систему так, чтобы все железо работало одновременно. В таком случае система становится очень эффективной. Моя цель создать устройство, а не осматривать окружающих сверху вниз с ощущением собственной крутизны. Мастерство это когда на слабой системе удается сделать крутое устройство, а не кайфовать, что супер навороченная система работает достаточно быстро, чтобы можчно было меньше думать при написании программы.

Что успеет ARM Cortex на 32МГц за 2мкС? Тем более с RTOS.
Всё что нужно выполнять в реальном времени, выполнять нужно в прерываниях. А медленные задачи в процессах. Тем более в RTOS бывают приоритеты процессов.
Главное чтобы RTOS быстро переключала задачи и подолгу не держала процессор с запретом прерываний.

А я так понял, что как раз о своей крутизне вы и хотите поговорить.
Но где доказательства крутизны?
Ok, я приму ее как факт, но покажите мне realtime под линуксом с 2 мкс ответом сделанный вашими руками.
В слабой системе вы сделаете слабый realtime- это закон.


Про то тут и идет речь.
Насколько укоротить прерывания и как практически назначать приоритеты задачам и прерываниям в RTOS с более чем десятком задач, многие из которых вы даже не знаете.
Еще учесть что в Cortex не так много уровней приоритетов прерываний.
Младшие Cortex-ы не рассматриваем. Берем i.MX RT для примера.

В том-то и дело, что в моей системе рациональней весь real-time делать программно, так как в этом случае достаточно одного микроконтроллера с нужным набором периферии, что упрощает дизайн железа. Также в будущем будет легко возможно обновление прошивок с добавлением новых возможностей без модификации железа.
Также для меня я считаю мастерством, если устройство будет сделано быстро и в срок и отвечать нужным требованиям. И при этом будет разработано с использованием наличествующих программистов определенной квалификации, без привлечения крутых системщиков или знатоков RTOS. И если при этом устройство потребует мощного МК - не вижу никаких проблем с этим. Так что мастерство бывает разным.

Возьмите Beaglebone там есть PRU. Это сопроцессор для аппликаций реального времени.
Когда я говорю о железе, то подразумевается то, что уже стоит на процессоре. Там ведь куча всяких периферийных устройств внутри. Для звука, видео, графики, интерфейсы разнообразные, таймеры, ШИМ, АЦП и т.д.. Я про это железо говорил.

Странный выбор. Зачем вспоминать это довольно устаревшее решение.
Есть же i.MX 6SoloX с полной поддержкой uC/OS и всеми фичами RT

Не знаю, какие там фичи есть, но раньше в серии imx6 был более-менее рабочий platform sdk, теперь и его куда-то заныкали, везде пишут линукс-онли...

Сообщение отредактировал mantech - Nov 14 2017, 13:35

А мне нравится. И буду вспоминать. Кстати они разного класса Beaglebone Cortex A8, imx6 Cortex A9.
Мне техасовская документация больше нравится. Пытался как-то осилить как конфигурировать GPIO imx53 - ниасилил. А вот в AM3715 легко пошел.
Вы пробовали читать фрискейловскую мутотень?

GPIO у фриски - это отдельная мутотень, из цикла "найди тут логику", согласен



Решил использовать фриску (МХ6) только потому, что в нем был LVDS и недорогая плата отечественной сборки, бона уж больно кусачая была...

любое x86 железо не на интел чипсете )

фото платы - x86 мамка. время реакции на что ? прерывание ? готового ответа системы по ТЗ ?

Тупые interrupt latency/scheduling latency величиной в 2 мкс - это какой-то отстой в наши дни, для x86 Linux уже давно пробита планка в 1мкс для RT apps на стоковом ядре. А Xenomai еще быстрее.
Но вопрос не в том как быстро среагировать на прерывание, получить данные, распарсить, посчитать и отослать в сеть. Вопрос в том как быстро это можно сделать пока не сделали конкуренты. И начем уже не важно. А вариант на uCOS/FreeRTOS будет делаться годами, обрастая Linux'ом все равно, так как голая железяка никому нафиг не нужна.

Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал:

http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865

сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns

Какие микросекунды ? Забудьте...