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

[syoma]

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

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

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

[syoma]

Если же прерывания не фрагменты задач, а нечто другое, то какой принцип планирования применить к обработчикам прерываний.

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

[AlexandrY]

Тут есть несколько подводных камней. Если чтение из буфера и обновление переменных сделать высокоприоритетной задачей или сразу в прерывании от CAN, то может случиться так, что это произойдет во время выполнения задачи, которая использует эти переменные.

Тут вы сделали себе логичекую ловушку.
Если вы утверждаете, что обработчик пакетов CAN работает у вас в реальном времени, то вам не надо ничего читать в прерывании. В прерывании только взводите флаг наличия пакета.
Читаете пакет и выполняет действия связанные с ним в единой задаче активизирующейся по флагу. Нет необходимости в промежуточной буферизации.
Буферизация, а лучше ковееризация - верный признак отсутствия реального времени.
Обработчик CAN следовательно не работает у вас в реальном времени.
Итого имеем ситуацию - есть ISR который не задача, и есть задача которая не realtime.