У меня есть такой случай, при котором надо сбросить контекст прерывания и выйти в конкретную точку.
АЦП работает обычно в режиме free-running, один из каналов следит за внешним питающим напряжением (часто там аккумулятор). Непрерывный анализ этого напряжения производится в прерывании. Можно было бы отдельную высокоприоритетную задачу завести, но жаль времени на постоянное переключение контекста и место под стек, к тому же там есть ряд нюансов с критическими секциями. И вот когда это напряжение становится ниже порога и нет критической секции, то надо выключить всех потребителей и перевести изделие в режим микропотребления. При этом RTOS уже не нужна - работает специальная процедура - вот тут то и потребовалось сделать возврат из прерывания в особую точку. Еще вариант - критическая ошибка в прерывании, когда надо выдать аналог BSOD - тут тоже желательно выйти (для некоторых архитектур) из режима прерывания. Ну а вообще, да - осознанный возврат "налево" при штатной работе (особенно если еще есть RTOS) то как бы "не камильфо". Нужно только в критических случаях, RTOS после этого уже не живет, а изделие в целом выходит в останов/спячку.

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


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

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

Кстати, если уж на то пошло, именно в таком варианте (с одной конкретной «подпрограммой завершения», в стек заносится фиксированный адрес) на 51-ых это решалось короче:
Т.е. вместо занесения в DPTR константы и заталкивания её в стек (или через аккумулятор -- на байт длиннее, но не нужно DPTR трогать) -- одна команда acall.
reti есть что там, что там. Помнить про пушнутое и попать его -- тоже.

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

Пример: прерывание UART принимает пакет определенного формата (скажем, команду устройству, которая должна выполняться в фоновом режиме), которая должна быть обработана. Команда может выполняться долго, и обрабатываеть ее прямо в прерывании скажем так - не комильфо.

Некрасиво обрабатывать команды в прерывании. Обычно в прерывании реализуют приёмный буфер, а разбор и обработку команды - в главном цикле (это если без ОС) или в отдельном потоке (с ОС). А фокусы с модификацией адреса возврата и прочее - это излишняя экзотика.

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

В таком случае RTOS очень помогла бы. Ну а без RTOS напрашивается использование прерываний для обработки команд, причём приоритеты прерываний соответствуют приоритетам команд.

Это Вы основной цикл слишком медленным сделали. Даже без РТОС можно создать приоритеты для вызываемых подзадач, и ситуёвина улучшится в разы. Приоритеты как раз могут изменяться внутри прерывания.

Сообщение отредактировал _Pasha - May 18 2011, 05:35

ОСи нет, а главный цикл очень сложный, с вводами с клавиатуры и т.д., и когда дойдет очередь до обработки команды - хз. В 51х все работало на ура, и здесь будет , просто нигде не могу найти детального описания - что происходит при передаче управления обработчику прерывания и при выходе из него. Например, в поисании указано, что при передаче управления обработчику прерывания в стек автоматически помещается 8 регистров: R0-R3,LR,PC,xPSR. Смотрю в листингах:
При входе в обработчик SysTick:
64:M1504/lpc17xx_it.c **** void SysTick_Handler(void)
65:M1504/lpc17xx_it.c **** {
200 .loc 1 65 0
201 .cfi_startproc
202 @ args = 0, pretend = 0, frame = 0
203 @ frame_needed = 1, uses_anonymous_args = 0
204 @ link register save eliminated.
205 0000 80B4 push {r7}
206 .LCFI14:
207 .cfi_def_cfa_offset 4
208 .cfi_offset 7, -4
209 0002 00AF add r7, sp, #0
При выходе:
248 .loc 1 74 0
249 0068 BD46 mov sp, r7
250 006a 80BC pop {r7}
251 006c 7047 bx lr
252 .cfi_endproc

Нигде нет обработки этих самых 8 регистров в стеке. Они отрабатываюся автомачически самим контроллером или? Мне бы мануал детальный найти...

Вот это и есть корень проблемы. И костыли с подменой адреса возврата из прерывания не сильно помогут, IMHO.


А что же сподвигло уйти от 51-го?
Cortex тем и хорош, что с ним не нужны все эти уловки, чтобы выжать последние соки из хилого процессора. Для Cortex можно программировать на нормальном Си, ведь это нормальный 32-разрядный процессор с приличной производительностью. Переносить на него грязные хаки из 51-го выглядит неприличным.


Гугл пробовали?
cortex-m3 manual

Ну так и сразу костыли... Программерский трюк это не костыль . В любом боле-менее сносном программно-аппаратном комплексе защиты ПО таких "костылей" тьма-тьмущая, и без них вообще никак, так что-же?

Ну я не это предлагал обсудить...

Грязные? Хаки? Чем они грязные и почему хаки?

Пробовал. Хотелось бы найти хорошую диаграммку с детальным описанием, как в мануале Филипса для 51х контроллеров. А то что в гугле по Кортексам разобраться конечно можно, но проштудировав много-много разных мануалов. Просто вопрос времени. Ведь мог кто-то уже сталкиваться с подобной задачей и решить ее? Мог. Почему бы мне не спросить? Вроде для того и форум.

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

Я за советом и обратился Задача собственно в том и стоит, чтобы по определенному событию (получен пакет с командой) как-то переключится на обработчик этой команды (может, программное прерывание?), а уж потом из обработчика вернуться туда, откуда попали в прерывание. Вероятно, я не совсем точно сформулировал проблему, сорри...

//Формирование прерывания "PendSV_Handler"
*(volatile unsigned *)0xE000ED04 = 0x10000000;