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

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

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

Так насчет вашего первого контраргумента что C код не совпадает с верифицируемым, вы признаете что его придумали?

Нет, конечно.
Если бы действительно читали документ на который ссылаетесь, то знали бы что они сделали код для x86 и его даже не думали проверять.
Да и для ARM они не указали платформу на которой прогоняли код. Это все симуляция.
По ходу это кажется я вам объясняю, как там все устроено.

Увольте, ваша фантазия конечно интересная , но я уже прочитал ту статью и многое из ссылок.

Народ все это интересно, но может стоит обсуждать в отдельной теме? Так как к моей теме я не вижу отношения.

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


Ага, теперь сами признайтесь, я прав?

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

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

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

С ваши подходом можно и Windows 10 считать RTOS.
У меня она еще ни разу не зависала, и гарантированно за час откликается на любое событие.

Чем гарантирует время реакции? Своим честным словом?

Да вам везет, у меня винда хоть редко, да зависнет, или ФС слетит при некорректном завершении...

Это не зависания оси, это переход в сервисный режим.
Десктопная винда может себе это позволить, она ж работает под управлением пользователя.
А встроенная винда спокойно обошла бы этот момент.

Ну хотя бы доступ к ресурсам железа, не?

Для AlexandrY

И каким же образом она гарантирует реальное время? Неужели честным словом Билла Гейтса? - мне правда интересно.
Никогда с реальным временем не работал. А как другие гарантируют?


То что они приходят неизвестно когда и в не своё время. Хотя это можно отрегулировать выше стоящей системой. Как следствие состояние системы неизвестно и окромя как выставить собственный флаг в прерывание вы более ничего не можете. Затем вы должны выйти из прерывания. И если это ОС с вытесняющей многозадачностью, то она должна при первом возможном случае вернуться к обработке прерывания, но уже в определённом состоянии:
а) откладываем текущую и начинаем драйверную задачу.
б) дождаться APC и втиснуть прерывание.
с) синхронизироваться с основным циклом секвенсера.

а, б нарушают реальное время. c - приводит к снижению производительности всей системы.

Сообщение отредактировал Pavia - Nov 3 2017, 14:40

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

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


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

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

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

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

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

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

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

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

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

Это невозможно по логике. Подумайте еще раз над этой формулировкой. Время не резиновое.

Возможно.
Я даже объяснил как.
Прочитайте несколько раз, что я написал.
Не всегда и не всем с первого раза доходит