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, старался писать код так, чтобы экономить такты. А потом понял, что моё время бесценно, а процессорное стоит копейки.

[mantech]

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

В таком режиме о энергосбережении можно забыть навсегда. В АВРках или простеньких АРМ, на частоте до 100МГц - это наверно и нафиг не нужно, но на частотах 500+ это очень заметно получается.
На счет труда программиста - для себя не вижу никакой трудности использовать прерывания, нежели изврат с поллингом, но тут дело вкуса, конечно...