Real-time и не-real-time - в одном флаконе или раздельно? Опции

[syoma]

Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос.
С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через CAN, SPI и RS485. Это основная функция системы.
С другой стороны есть куча других интерфейсов - SD card, Ethernet, USB и прочих, которые служат для вспомогательных функций - записи логов, параметрирования, обновления ПО, удаленного доступа через WEB и bluetooth, терминалки и т.д.

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

Как думаете это нормальный подход сегодня?

[Студент заборстр...]

А какие проблемы-то? (я к вопросу темы)
Фоновый поток не реалтайм, а приоритетные потоки - реалтайм.
Тут нет никакой проблемы.
А проблема в том, чтобы при наличии вытесняющей многозадачности низкоприоритетным потокам тоже гарантировать пусть и бОльшее, чем высокоприоритетным потокам, но ГАРАНТИРОВАННОЕ время реакции.

Это проблема хоть и сложней, но вполне решаема.
Я в разработанной мной RTOS её решил

[mantech]

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

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

[Студент заборстр...]

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

Если поток прерываний слишком большой, он "забьёт" более низкоприоритетные, но все равно реал-таймовые задачи.

Я пошёл по пути гарантированного тайм-слота для задач с приоритетами класса 2

С ваши подходом можно и Windows 10 считать RTOS.

С цитированием по внимательней будьте.
Я так понял, это Вы к вот этому:

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

Если ртось УСПЕВАЕТ ВОВРЕМЯ среагировать и обработать евент за ДЕТЕРМИНИРОВАННОЕ время и это время устраивает заказчика, значит это ртось. Даже если время реакции сотни милисекунд

К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

А не к тому, что процитировали

Изучив десятки RTOS, теорию их построения и перепробовав различные варианты построения RTOS я в конце концов вообще я отказался от использования прерываний.
Посколько с ними трудно динамически менять приоритет прерываний как тебе заблагорассудится и жесткий реалтайм для всех потоков трудно реализовать.
Точнее у меня работал только одно прерывание. Таймерное.
Все остальные прерывания работали по механизму поллинга их флагов.
Да получился большой оверхед. В том смысле, что процессор почти 70% времени проводил в таймерном прерывании.

Ну и что?
Проблему решил просто: взял проц с более высокой (на 500% выше чем нужно для моих задач) тактовой. И что? сейчас процессоры стоят дешевле грязи. А вот софт к ним стоит огого. Поэтому лучше купить проц подороже, но сэкономить на софте

Зато реализация RTOS получилась очень простой, красивой и надёжной. И жесткий реалтайм получился ГАРАНТИРОВАННЫМ при вытесняющей многозадачности

Более того.
У меня не только была реализована вытесняющая многозадачность. Но и отсутствие зависания даже самых низкоприоритетных потоков.
Посколько классу низкоприоритетных потоков все равно гарантировался тайм-слот

Проблема дедлоков тоже была решена за счет выбора архитектуры построения RTOS

Таким образом у моей RTOS был только один "минус": 70% времени процессора занимал микродиспетчер, находившийся в таймерном прерывании. Т.е. на диспетчеризацию уходило 70% процессорного времени, а на выполнение "полезной работы" - всего 30%. Но с этим можно смириться. Выбрав более мощный проц

Сообщение отредактировал Студент заборстроительного - Nov 3 2017, 15:24

[mantech]

Если поток прерываний слишком большой, он "забьёт" более низкоприоритетные, но все равно реал-таймовые задачи.

Я пошёл по пути гарантированного тайм-слота для задач с приоритетами класса 2

Сразу вижу противоречие. Т.е. если возьмем один и тот же процессор, и если у него не хватает быстродействия для обработки прерываний, и он забьет остальные прерывания, то это означает одно - неправильный выбор быстродействия проца, т.к. в этом случае ваша ОС просто пропустит это событие, находясь в другой задаче или в блоке переключения контекста.

[Студент заборстр...]

Сразу вижу противоречие. Т.е. если возьмем один и тот же процессор, и если у него не хватает быстродействия для обработки прерываний, и он забьет остальные прерывания, то это означает одно - неправильный выбор быстродействия проца, т.к. в этом случае ваша ОС просто пропустит это событие, находясь в другой задаче или в блоке переключения контекста.

Поэтому я и пошёл по пути запрета всех прерываний кроме таймерного.
А другие прерывания опрашивал по механизму поллинга.
Я же писал: у меня проц больше 70% времени сидит в обработчике таймерного прерывания, а на "полезную работу" доступно менее 30% процессорного времени.

Кто-то скажет: это же не рационально, глупо, криво и т.п.
А я скажу: процессорное время стоит на ПОРЯДКИ дешевле, чем труд программиста.
И это мизерная цена за простоту и прозрачность кода и обеспечение жесткой реалтаймовости при вытесняющей многозадачности и многопоточности

хотя он, возможно, не самый эффективный по загрузке процессора - до 70%

Да плевать на загрузку процессора. Он же железный, вот и пусть пашет.
Труд программиста стоит на порядки дороже чем процессорные такты.
Я когда-то болел болезнью: экономить каждый такт CPU, старался писать код так, чтобы экономить такты. А потом понял, что моё время бесценно, а процессорное стоит копейки.

[Tarbal]

Поэтому я и пошёл по пути запрета всех прерываний кроме таймерного.
А другие прерывания опрашивал по механизму поллинга.
Я же писал: у меня проц больше 70% времени сидит в обработчике таймерного прерывания, а на "полезную работу" доступно менее 30% процессорного времени.

Кто-то скажет: это же не рационально, глупо, криво и т.п.
А я скажу: процессорное время стоит на ПОРЯДКИ дешевле, чем труд программиста.
И это мизерная цена за простоту и прозрачность кода и обеспечение жесткой реалтаймовости при вытесняющей многозадачности и многопоточности


Да плевать на загрузку процессора. Он же железный, вот и пусть пашет.
Труд программиста стоит на порядки дороже чем процессорные такты.
Я когда-то болел болезнью: экономить каждый такт CPU, старался писать код так, чтобы экономить такты. А потом понял, что моё время бесценно, а процессорное стоит копейки.

Фигасе!. Что за такое таймерное прерывание?
В двух словах как работает preemptive real-time операционная система. Ядро получает возможность переключить задачу при системном вызове и после обработки прерывания.
Прерывания читают из железа (и пишут в железо) и разрешает семафор достаточно высокоприоритетной задаче, которая как бы является продолжением прерывание, поскольку при выходе из прерывания обработка будет переключена на нее если исполнялясь низкоприоритетная задача, но прерывания уже не будет.
Еще раз. Бежала какая-то низкоприоритетная задача, когда возникло условие для прерывания. Скажем приняли пакет данных в регистры приемника. В прерывании эти регистры копируются в буфер, буфер ставится в очередь буферов и отпускается семафор обработчика принятого буфера. Все. Выходим из прерывания. Эта работа достаточно короткая и в прерывании больше продолжать не надо. Отпущеный семафор меняет условия для ядра и из прерывания вы выходите не в ту задачу, что исполнялясь, а в ту, которая ждала семафора, поскольку ей нечего было обрабатывать. Фактически вы продолжаете обрабатывать прием, но уже не в прерывании.
Закон. Прерывания надо предельно минимизировать. Обработчик таймера, который считает время, вообще должен инкрементировать счетчик и выйти. Ну еще пару таких же простых операций если очень нужно. И все.

Поллинг самое нехорошее решение для реал тайма.
Если писать правильно, то все будет эффективно и с маленькими затратами. Я пару лет назад пытался описать принципы написания програм реального времени, но отчего-то публика начала возмущаться моей нескромностью и топик в котором я начал описывать технику написания програм реального времени перенесли в тему общение. Как мне объяснили, что раз меня не спрашивают, то и нефиг соваться. Так что если вам интересно -- создайте тему. Скажем "Как писать программы реального времени?", а люди будут вам отвечать. Вот тогда у вас будет пища для принятия решений.

[AlexandrY]

Еще раз. Бежала какая-то низкоприоритетная задача, когда возникло условие для прерывания. Скажем приняли пакет данных в регистры приемника. В прерывании эти регистры копируются в буфер, буфер ставится в очередь буферов и отпускается семафор обработчика принятого буфера. Все. Выходим из прерывания. Эта работа достаточно короткая и в прерывании больше продолжать не надо. Отпущеный семафор меняет условия для ядра и из прерывания вы выходите не в ту задачу, что исполнялясь, а в ту, которая ждала семафора, поскольку ей нечего было обрабатывать. Фактически вы продолжаете обрабатывать прием, но уже не в прерывании.

Так обработчики прерываний надо рассматривать как фрагменты задач если придерживаться концепции Rate-Monotonic Scheduling ?
Я вот это не понял.
Если смотреть на них, как на фрагменты задач, то тогда ваш подход прямо нарушает принцип монолитности.
Если же прерывания не фрагменты задач, а нечто другое, то какой принцип планирования применить к обработчикам прерываний.
И не будет ли он конфликтовать с Rate-Monotonic Scheduling?
Исходим из того что обработчики прерываний в высоконагруженной встраиваемой системе исчисляются десятками и занимают больше половины процессорного времени.