Обработка IRQ без использования средств uC/OS Опции

[Vladimir_T]

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

[Vladimir_T]

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

[Andy Mozzhevilov]

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

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