Под скоростью реакции я имел ввиду переход событие-задача. Фактически вызов системного сервиса (семафора, mbox, que) из прерывания и получение этого события в задаче.


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


Кто знает - тот знает.
Цена здесь, некий набор действий, выполненый портом ОС до передачи управления на вектор. Да, там есть некоторые накладные расходы.
Кстати в какой-то степени они зависят от архитектуры процессора. В АРМ приходится перекидывать контекст между стеками, что есть накладные расходы. Когда я делал порт для Fujitsu с его 32-банками регистров, то накладные расходы по переключению контекста были минимальны.


Если необходимо действительно быстрое прерывание, то я его тоже делаю на FIQ, поскольку у меня оно не идет через осевую обертку.
Кроме этого, FIQ прерывает IRQ, что позволяет сделать вход в обработчик с мимимальными задержками и джиттером (если это прерывание периодическое). В этом случае из FIQ, действительно только 1 раз из многих, возникает необходимость вызова сервиса ОС. Для этого в NXP я использовал Software Interrupt в VIC, которое уже идет через IRQ и соответственно может использовать сервисы ОС.
Но это действительно нужно только в некоторых случаях. Во многих случаях это скорость ради скорости.
Напротив, я могу привести ряд примеров, когда мне требовалось поднимать задачу периодически и достаточно часто (раз в 500 мкс, причем на Fujitsu, который ~5 раз медленне NXP на 60МГц при выполнении кода ОС). При этом делать таймер ОС с таким периодом совершенно нецелесообразно.

PS: Спорить о том, какой подход лучше, я не хочу. Понимая, как они оба работают, вижу и достоинства и недостатки и того и другого.
Автором топика был задан конкретный вопрос, и касательно uCOS. Я на него ответил. Да, если использовать тот порт, который они предлагают, то нужно перенаправлять вектор сначала на осевой обработчик. Если этого не сделать, то в прерываниях нельзя будет пользоваться сервисами ОС. Тогда (для uCOS) прерывания получатся оторванными от оси и передача событий из прерываний в задачи значительно усложняется, фактически сводясь в опросу флагов (как в системе foreground-background). Причем делать этого я смысла в большинстве случаев не вижу. Получается, что это скорость ради скорости.
Второй вариант - переписать порт uCOS. Можно сделать порт так, чтобы обработчик прерываний мог вызываться без пролога оси.
В общем я для Fujitsu именно так и делал. Если в пользовательском прерывании хотелось вызвать сервис ОС, то нужно было сначала вызвать функцию информирования ОСи о том, что вызовы идут из прерываний. В результате можно было некоторые прерывания обрабатывать, не пользуя сервисы ОС, и как следствие - по выходу не производя попыток переключения контекста.

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

Ну есть еще абстрактное понятие красоты

Посмею предположить, что и задачу часто регулярно поднимаемую делать было не очень-то целесообразно красиво . Хотя умом понимаю, что ресурсов все больше и больше и пусть себе работает, как может.

Та задача своими вычислениями занимала ~200 мкс из 500, а в некоторой ветви, которая выполнялась раз в несколько сотен итерраций - до 800 мкс (при этом джиттер, который она вызывала не имел значения).
То есть делать ее в прерывании - блокировать систему на недопустимое время.
Разделить алгоритм на 2 части - быструю для IRQ и медленную для задачи было не тривиально, явное усложнение системы. Да и смысла я в этом не увидел. Ну ест задача 40% процессорного времени, остальные - еще 30%. Еще резерв оставался.
Но это уже я совсем отошел от топика.