Здравствуйте, хотелось бы использовать обработку векторных прерываний IRQ без использования средств uC/OS на STR911. Поэтому хотел спросить у коллег, как лучше оформить обработчики IRQ, с тем, чтобы прерывания обрабатывались в фоновом режиме и использовались средства ОС (флаги событий и др.). Буду благодарен за ссылки или решения из личного опыта.

Когда я юзал uCOS, на многих процах, то всегда делал один и тотже финт.
Чтобы из чистых прерываний (без сохранения контекста задач) вызывать сервисы RTOS я организовывал программный вызов одного промежуточного прерывания которое уже было в контексте RTOS и оно обслуживало только запросы от чистых прерываний.
Промежуточное прерывание в свою очередь выставляло флаги, семафоры, очереди сообщений и все прочее без блокировки.
Хардварным источником промежуточного прерывания могло быть что угодно, он выбирался из тех что не используются в системе и блокировался чтобы не сбивать описанный процесс.

uCOS в этом смысле простая ось. А есть оси где прерывания в контексте RTOS еще деляться на легкие и тяжелые, там цепочка прерываний удлиняется еще на одну стадию.

Вопрос не совсем понятен.
Чтобы пользоваться сервисами ОС из прерываний на ARM7, то необходимо заходить в прерывания
через точку входа, описанную в порте ОС. Таким образом, независимо от того, хотите вы пользовать сервисы ОС из прерываний или нет, по окончанию обработки прерываний ОС попробует сделать
перепланирование.
Если вы будете заходить в IRQ самостоятельно, минуя точку входа ОС, тогда вы не сможете пользовать ни сервисы ОС из прерывания, ни (что более критично) завести системный таймер для тиков операционки.
Если вы хотите иметь прерывания, которые работают вне зависимости от критических секций ОС, то делайте их на FIQ. В этом случае порт оси надо будет чуть подправить в части функции входа в критическую секцию, чтобы в ней не запрещать FIQ. Пользовать сервисы ОС в этом случае из прерываний FIQ будет нельзя. Но, из FIQ можно будет сделать программное прерывание в контроллере прерывание, определенное как IRQ, в котором уже искользовать сервисы ОС. Во всяком случае в LPC я это делал без каких-либо проблем. Но тут зависит уже от контроллера прерываний STR, позволит ли он сделать такой финт.
А вообще, лучше вы опишите, зачем вам это нужно, потому что мне кажется, проблема может иметь другие, более элегантные пути решения.

При обработке потока с АЦП в сканере важно делать обработку немедленно чтобы не вносить задержек, которые могут внести ошибку при дальнейшем частотном анализе. Если обслуживать IRQ средствами uC/OS, то, как я понял, возможны различные задержки на обслуживание IRQ. Т.е. если бы время на обслуживание IRQ было бы всегда строго гарантированное, то это время возможно учитывать при дальнейших расчетах, а так как это время может меняться (в зависимости от того в каком состоянии находится ОС), вот и хотелось бы исключить это время. Делать обработку IRQ без вмешательства ОС, и по готовности массива для обработки, установить флаг, по которому ОС запускает задачи: расчетную, вывод на дисплей, архивирование, связь.
Спасиба AlexandrY и Andy Mozzhevilov за отличныю идею с ипользованием промежуточного программного прерывания.

Насколько я понимаю, в таких системах все же прерывания от АЦП не запускаются программно, а тактируются аппаратным таймером, если речь идет о встроенной периферии (АЦП).
Тогда как бы нет особой разницы в том, каков джиттер на вход в прерывание, поскольку частота дискретизации определяется именно аппаратно таймером. Главное требование, чтобы критическая секция ОС не оказалаль настолько долгой, что в результате произойдет потеря прерывания от АЦП.
Но с другой стороны, если прерывания идут относительно быстро, но при их обработке в большинстве случаев сервисы ОС не используются, тогда накладные расходы на вход и выход в осевой обработчик могут оказаться достаточно большими. В этом случае можно посадить прерывания АЦП на FIQ и понеслась душа в рай. А когда возникнет наконец необходимось вызвать сервисы ОС, то сделать это посредством вызова промежуточного прерывания.

Я уже давно не смотрел, что там в uCOS, но довольно часто возможен промежуточный вариант, когда, например, из совершенно банального обработчика вызывается препланировщик, или посылается сообщение, только переключение контекста не производится. Контекст будет переключен по окончанию текущей задачи или таймеру. Меня это достаточно часто устраивает, особенно с сообщениями. "Трюк" описанный AlexandrY тоже использую давно и успешно, особенно для FIQ.