Обработка 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 и понеслась душа в рай. А когда возникнет наконец необходимось вызвать сервисы ОС, то сделать это посредством вызова промежуточного прерывания.

[zltigo]

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

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