Выход из прерывания в требуемую точку Опции

[Krom]

Контроллер LPC1768. Задача: в определенный момент выйти из прерывания (UART) в требуемую точку, а уж оттуда потом продолжить выполнения с места, где возникло прерывание. Никаких ОС не используется.
В контроллерах семейства 8051 это делалось элементарно:
; сохраняем регистр прерываний
push IE
; запрещаем прерывания
clr EA
; берем требуемый адрес
mov DPTR,#PROCESS
; подсовываем в стек
push DPH
push DPL
; и выходим куда нужно
reti
А вот как сделать нечто подобное в Cortex M3? Как корректно передать управление нужному процессу из обработчика прерывания, да так, чтобы ничего не испортить,а затем уже из того процесса корректно вернуться в нужное место?

[kovigor]

Как корректно передать управление нужному процессу из обработчика прерывания, да так, чтобы ничего не испортить,а затем уже из того процесса корректно вернуться в нужное место?

В правильно спроектированном ПО необходимости в таких действиях обычно не возникает. Продумайте структуру вашего проекта еще раз ...

Сообщение отредактировал kovigor - May 17 2011, 15:18

[paskal]

В правильно спроектированном ПО необходимости в таких действиях обычно не возникает. Продумайте структуру вашего проекта еще раз ...

Зря вы так. Есть масса задач где прыжок по определенному адресу при обработке прерывания наиболее оптимальный вариант.

[aaarrr]

Зря вы так. Есть масса задач где прыжок по определенному адресу при обработке прерывания наиболее оптимальный вариант.

Ну, хоть бы пример привели, а то так не интересно.

[paskal]

Ну, хоть бы пример привели, а то так не интересно.

Могу и пример, но только с тем же 51-м.
Вот тот же UART.
У нас есть сложный протокол по RS-485 где сидит много устройств. Протокол примерно такой.
1-й байт - номер устройства. Если номер наш, то обрабатываем дальше, иначе игнорируем всю посылку.
2-й байт номер протокола тут идут варианты. В зависимости от протокола мы либо принимаем, либо передаем, и количество байт разное. Но реакция должна быть мгновенной, т.е. обрабатывать мы должны на лету, это задано в ТЗ.

Если всю эту хрень делать без прерываний по ожиданию приема/передачи, программа получается простой. Принимаем-сравниваем-переходим на нужную метку.

Примерно так
MOV A,SBUF
M1: CJNE A,#1, M2
;обработка протокола 1
JMP BEGIN
M2: CJNE A,#2, M3
;обработка протокола 2
JMP BEGIN
.... и.т.д.


Но так нельзя - программа только и делает что висит-ждет очередной байт.
А вот по прерываниям простота заканчивается. По любому приему происходит переход на один и тот же адрес обработчика и дальше надо заводить кучу дополнительных флагов чтоб помнить текущую фазу протокола, и оборачивается это кучей запутанных ветвлений.
Вот здесь положение спасает переход по определенному адресу. После обработки очередного байта, мы заносим в переменную адрес следующего обработчика и при следующем прерывании прыгаем сразу в эту точку.
При таком методе программа получается намного проще, а реакция на обработку быстрее.
Поэтому лично я давно делаю обработку UARTа именно так.

Другой более простой случай. Надо дождаться на пине например 1, и тут же среагировать на это. Если в лоб ждать то будет так:

WAIT: JNB P1.0,WAIT
; обработка события

Но тогда цикл может висеть бесконечно долго, нужен выход по таймауту. Обычный метод - ввести в цикл счетчик, его инкрементировать, сравнивать и добавить дополнительный переход. Но цикл многократно удлинится, а с ним и время реакции.
Выход - оставить цикл без счетчика, а ввести таймерное прерывание с возвратом на TIMEOUT:

WAIT: JNB P1.0,WAIT
; обработка события
TIMEOUT:
; идем дальше

Здесь немного другой случай, адресный переход идет не на обработку прерывания, а после возврата, но суть та же.

А еще таким методом можно организовать многозадачность повесив на таймер такой обработчик, чтоб он запоминал адрес предыдущего вызова, а возвращал на адрес следующей, и так перебирал все задачи по кругу.

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

Вовсе нет. Во-первых в 51-х можно сделать вложенное прерывание. Во-вторых как я описал выше, вложенность тут ни при чем

[ReAl]

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

Код

// Компиляторо-зависимые атрибуты/прагмы опускаем
void (*real_handler)() = initial_handler; //
void interrupt_handler()
{
    real_handler(); // внутри всех обработчиков при необходимости перезаносится переменная real_handler
}

Что-то мне кажется, что от возникновения прерывания до начала работы реального обработчика это будет быстрее, чем занесение в стек дополнительного адреса возврата для «возврата» в некий процесс.
Быстрее этого будет только перемещение таблицы векторов в ОЗУ и замена вектора в той таблице.

[paskal]

Что-то мне кажется, что от возникновения прерывания до начала работы реального обработчика это будет быстрее, чем занесение в стек дополнительного адреса возврата для «возврата» в некий процесс.

Напомню что пример был по обработке сложного протокола с большим количеством вариантов. Переход по адресу хоть и требует дополнительных действий, но происходит СРАЗУ в нужное место. А альтернатива этому методу - долго лазить по дереву state_machine с помощью флагов и ветвлений.

Что Вы тут описали, это одна из возможных реализаций state machine - давно известная и наглядная штука для ветвлящихся алгоритмов.

Конечно известная. Речь не о стэйтмашине вообще, а о том что реализовать ее можно либо адресами переходов, либо набором флагов и переменных состояния с последующими ветвлениями по этим флагам. И первый способ и нагляднее и быстрее.

[AHTOXA]

Конечно известная. Речь не о стэйтмашине вообще, а о том что реализовать ее можно либо адресами переходов, либо набором флагов и переменных состояния с последующими ветвлениями по этим флагам. И первый способ и нагляднее и быстрее.

Дело в том, что вызов функции - это тоже "переход по адресу":) И вместо "адреса перехода" вы можете хранить в переменной "адрес функции", соответствующей текущему состоянию. О чём вам и написал ReAl.
Разница же между "вызовом функции"(он же "переход по адресу") и "подменой адреса возврата из прерывания", о которой спрашивал топикстартер, заключается в том, что во втором случае перед переходом по адресу происходит окончание прерывания. Вопрос в том, нужно ли это топикстартеру, и что ему это даст. В 8051 это давало разрешение прерываний (о чём написал я). А в кортексах - не даёт ничего. (Вернее, кое что конечно меняется, но не так радикально).