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

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

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

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


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

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

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

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

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

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

Какие Ваши годы. У Вас ещё всё впереди.
"О сколько нам открытий чудных..."
Трудностей нет пока задачи относительно простенькие и проц мощный. И устройство не "mission critical"
Только потом не говорите, что я Вас не предупреждал

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

Своя ОС, проц мощный, работа в режиме 24\7, полет нормальный...

Спасибо, предупрежден

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

Moderator: Уважаемые, настоятельно призываю вернуть дискуссию в конструктивное русло. Иначе буду наказывать.

Не очень понял, перефразируйте? Обработчик пакетов CAN читает пакет из приемного буфера(или почтового ящика, если так более понятно) приемника CAN, как только тот оказывается там. Других буферов нет.

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

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

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