Понижение приоритета прерывания "на лету"?, Выход из прерывания без выхода из него. Опции

[KnightIgor]

Добрый день!

Предположим, имеется прерывание высокого приоритета. ISR (процедура обработки прерывания), обслужив быстренько себя (например, установив/сбросив флаги), должна затем запустить некоторый процесс. Запуск процесса предполагает каждый раз некую инициализацию, которая длится долго (например, расчеты). Таким образом, если вызвать процедуру запуска процесса непосредственно из ISR, то это будет блокировать всю систему. Конечно, можно установить в ISR лишь некий флажок, проанализировать его в синхронном цикле программы и оттуда запустить процесс. Идея, однако, в том, чтобы еще внутри ISR как бы сделать вид, что ISR завершена, и спокойно вызвать процедуру:

Код

void xxx_IRQn(void) {

// быстрое и короткое действие самообслуживания
..
// понижение "приоритета" до уровня основной программы
..
// вызов длительного действия, которое может быть прервано другими ISR
  InitSomeProcess();

// выход из ISR
..
}

Для тех, кто имел дело с 51-ми процессорами, там был такой трюк: в ISR можно вызвать (call) инструкцию RETI, что приводило к "переводу" системы на уровень приоритета основной программы, после чего выполнять действия, которые могли уже быть прерваны иными ISR:

Код

void  xxx_Vector(void)   interrupt INTERRUPT_XXXX

// быстрое и короткое действие самообслуживания
..
// понижение "приоритета" до уровня основной программы
  call _RETI

// вызов длительного действия, которое может быть прервано другими ISR
  InitSomeProcess();

// выход из ISR
_RETI: RETI
}

Предполагаю, что где-то надо покрутиться с NVIC. Но не соображу пока, как.

P.S. Извините, если разжевываю вопрос как для "чайников": зачастую читаю тут вопросы и не могу врубиться, а что же спрашивают и куда хотят. Кому все сразу понятно, читайте через строку .

TIA

[AlexandrY]

Предположим, имеется прерывание высокого приоритета. ISR (процедура обработки прерывания), обслужив быстренько себя (например, установив/сбросив флаги), должна затем запустить некоторый процесс...

Это типичная схема вытеснения в RTOS. Работает идеально на всех современных архитектурах.

Оформляете свой процесс в виде задачи и ставите в его начале ожидание семафора.
В процедуре прерывания если нужно запустить процесс происходит восстановление не в контекст прерванной задачи, а в контекст задачи процесса, а именно в то место в ядре RTOS где задача вашего процесса остановилась в ожидания семафора.

[KnightIgor]

Это типичная схема вытеснения в RTOS. Работает идеально на всех современных архитектурах.

Оформляете свой процесс в виде задачи и ставите в его начале ожидание семафора.
В процедуре прерывания если нужно запустить процесс происходит восстановление не в контекст прерванной задачи, а в контекст задачи процесса, а именно в то место в ядре RTOS где задача вашего процесса остановилась в ожидания семафора.

А если я не использую RTOS? Меня механизм как таковой интересует.

[Aaron]

А если я не использую RTOS? Меня механизм как таковой интересует.

я использую protothreads - как раз "готовый механизм без использования RTOS" http://www.sics.se/~adam/pt/