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

[syoma]

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

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

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

[syoma]

Вы допустили возможность прихода нового пакета пока не обработан предыдцщий.

Не, не. Естественно, подразумевается, что пакет будет обработан до того, как придет следующий. Там всего лишь надо вытащить данные из CAN-пакета и положить их в память - работы с гулькин нос.

[AlexandrY]

Не, не. Естественно, подразумевается, что пакет будет обработан до того, как придет следующий. Там всего лишь надо вытащить данные из CAN-пакета и положить их в память - работы с гулькин нос.

Тогда нарушаете принцип RMS. Задача должна быть монолитна. А у вас часть задачи в прерывании, часть в потоке. А между ними может вклиниться другая задача или прерывание.
Да что уж там, признайтесь, никакой вы RMS не используете, правда? Так просто, слышали звон.

[syoma]

Тогда нарушаете принцип RMS. Задача должна быть монолитна. А у вас часть задачи в прерывании, часть в потоке. А между ними может вклиниться другая задача или прерывание.
Да что уж там, признайтесь, никакой вы RMS не используете, правда? Так просто, слышали звон.

Я собираюсь использовать RMS. Если так хочется сделать задачу монолитной, то можно спокойно собирать все CAN-пакеты в буфер, а затем обработать их скопом в самой приоритетной задаче, не нарушая принципов RMS.
Но это все сводится к тому, как привести асинхронные задачи (такие как обработка CAN-пакетов) к синхронным - т.е. задачам в RMS. У вас есть другие решения данной проблемы?

[Tarbal]

Я собираюсь использовать RMS. Если так хочется сделать задачу монолитной, то можно спокойно собирать все CAN-пакеты в буфер, а затем обработать их скопом в самой приоритетной задаче, не нарушая принципов RMS.
Но это все сводится к тому, как привести асинхронные задачи (такие как обработка CAN-пакетов) к синхронным - т.е. задачам в RMS. У вас есть другие решения данной проблемы?

Занимаюсь задачами реального времени не один десяток лет, но никогда не слышал о необходимости делать задачи монолитными. "Откуда мол и что это за географические новости"?

Гугл тоже не в курсе:
https://www.google.ca/search?dcr=0&q=Re...427&bih=836

[AlexandrY]

Занимаюсь задачами реального времени не один десяток лет, но никогда не слышал о необходимости делать задачи монолитными. "Откуда мол и что это за географические новости"?

Гугл тоже не в курсе:
https://www.google.ca/search?dcr=0&q=Re...427&bih=836

Ссылка в тему, спасибо.
К вопросу о монолитности задач. Это вытекает из принципа анализа RMS.
А главная вещь в том анализе - дидлайн.
Значит нет никакого смысла разбивать задачу на два этапа - сначала взять быстро ее данные, потом медленно данные обрабатывать.
Это все равно что поставить себе целью фальшивый дидлайн, а на самом деле иметь гораздо более отдаленный дидлайн. Обман самого себя.
Такие финты в анализе RMS учтены быть не могут.

По вашей ссылке я вышел на более интересную статью - Rate Monotonic vs. EDF: Judgment Day
Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

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

Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

Подход очень зависит от того, ГДЕ будет использоваться RTOS.
Одно дело в управлении кофемолкой, то там можно гнаться за красотой реализации, использовать какие-то новомодные концепции тащась от собственной крутости.
Вообще по разному можно выпендриваться.

А когда у тебя что-то серьёзное и от того, что у тебя случится дедлок или задача "чуть чуть не успеет" погибнут люди или угробится оборудование стоимостью в миллионы баксов, то вся эта блажь "красиво/не красиво" быстро уходит и остаются простые как гробовая доска железобетонные методы обеспечения надёжности.

Я тоже в своё время игрался с разными концепциями, соблазнившись их красотой, когда писал RTOS "для себя". Чисто из научного интереса.

Но когда задачи стали серьёзными ("жёсткий реалтайм" и никаких дедлоков и "не успела я" иначе будет большой бадабум), то в конце концов пришёл к описанной мной выше реализации