VslavX 0 17 мая, 2011 Опубликовано 17 мая, 2011 · Жалоба Ну, хоть бы пример привели, а то так не интересно. У меня есть такой случай, при котором надо сбросить контекст прерывания и выйти в конкретную точку. АЦП работает обычно в режиме free-running, один из каналов следит за внешним питающим напряжением (часто там аккумулятор). Непрерывный анализ этого напряжения производится в прерывании. Можно было бы отдельную высокоприоритетную задачу завести, но жаль времени на постоянное переключение контекста и место под стек, к тому же там есть ряд нюансов с критическими секциями. И вот когда это напряжение становится ниже порога и нет критической секции, то надо выключить всех потребителей и перевести изделие в режим микропотребления. При этом RTOS уже не нужна - работает специальная процедура - вот тут то и потребовалось сделать возврат из прерывания в особую точку. Еще вариант - критическая ошибка в прерывании, когда надо выдать аналог BSOD - тут тоже желательно выйти (для некоторых архитектур) из режима прерывания. Ну а вообще, да - осознанный возврат "налево" при штатной работе (особенно если еще есть RTOS) то как бы "не камильфо". Нужно только в критических случаях, RTOS после этого уже не живет, а изделие в целом выходит в останов/спячку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
paskal 1 17 мая, 2011 Опубликовано 17 мая, 2011 · Жалоба Что-то мне кажется, что от возникновения прерывания до начала работы реального обработчика это будет быстрее, чем занесение в стек дополнительного адреса возврата для «возврата» в некий процесс. Напомню что пример был по обработке сложного протокола с большим количеством вариантов. Переход по адресу хоть и требует дополнительных действий, но происходит СРАЗУ в нужное место. А альтернатива этому методу - долго лазить по дереву state_machine с помощью флагов и ветвлений. Что Вы тут описали, это одна из возможных реализаций state machine - давно известная и наглядная штука для ветвлящихся алгоритмов. Конечно известная. Речь не о стэйтмашине вообще, а о том что реализовать ее можно либо адресами переходов, либо набором флагов и переменных состояния с последующими ветвлениями по этим флагам. И первый способ и нагляднее и быстрее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 17 мая, 2011 Опубликовано 17 мая, 2011 · Жалоба Конечно известная. Речь не о стэйтмашине вообще, а о том что реализовать ее можно либо адресами переходов, либо набором флагов и переменных состояния с последующими ветвлениями по этим флагам. И первый способ и нагляднее и быстрее. Дело в том, что вызов функции - это тоже "переход по адресу":) И вместо "адреса перехода" вы можете хранить в переменной "адрес функции", соответствующей текущему состоянию. О чём вам и написал ReAl. Разница же между "вызовом функции"(он же "переход по адресу") и "подменой адреса возврата из прерывания", о которой спрашивал топикстартер, заключается в том, что во втором случае перед переходом по адресу происходит окончание прерывания. Вопрос в том, нужно ли это топикстартеру, и что ему это даст. В 8051 это давало разрешение прерываний (о чём написал я). А в кортексах - не даёт ничего. (Вернее, кое что конечно меняется, но не так радикально). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 17 мая, 2011 Опубликовано 17 мая, 2011 · Жалоба ; сохраняем регистр прерываний push IE ; запрещаем прерывания clr EA ; берем требуемый адрес mov DPTR,#PROCESS ; подсовываем в стек push DPH push DPL ; и выходим куда нужно reti Кстати, если уж на то пошло, именно в таком варианте (с одной конкретной «подпрограммой завершения», в стек заносится фиксированный адрес) на 51-ых это решалось короче: tf0_isr: _push <PSW, ACC, AR0> ... breq @@PROCESS; ну к примеру так решили, что надо проджолжать на низком приоритете _pop <AR0, ACC, PSW> @@reti: ; в очередной раз спасибо VslavX за утилтику «локальных меток» reti @@PROCESS: acall @@reti ; а вот тут и начинается код того PROCESS -- тут уже уровень прерывания очищен ; выполнение продолжается на уровне приоритета основной программы ... ... _pop <AR0, ACC, PSW> ret Т.е. вместо занесения в DPTR константы и заталкивания её в стек (или через аккумулятор -- на байт длиннее, но не нужно DPTR трогать) -- одна команда acall. reti есть что там, что там. Помнить про пушнутое и попать его -- тоже. При этом RTOS уже не нужна - работает специальная процедура - вот тут то и потребовалось сделать возврат из прерывания в особую точку.Знакомо, хотя и с «суперциклом», а не с нормальной ОС. Один из тех исключительных случаев, когда это действительно нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krom 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Ну, хоть бы пример привели, а то так не интересно. Пример: прерывание UART принимает пакет определенного формата (скажем, команду устройству, которая должна выполняться в фоновом режиме), которая должна быть обработана. Команда может выполняться долго, и обрабатываеть ее прямо в прерывании скажем так - не комильфо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Пример: прерывание UART принимает пакет определенного формата (скажем, команду устройству, которая должна выполняться в фоновом режиме), которая должна быть обработана. Команда может выполняться долго, и обрабатываеть ее прямо в прерывании скажем так - не комильфо. Некрасиво обрабатывать команды в прерывании. Обычно в прерывании реализуют приёмный буфер, а разбор и обработку команды - в главном цикле (это если без ОС) или в отдельном потоке (с ОС). А фокусы с модификацией адреса возврата и прочее - это излишняя экзотика. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krom 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба практически полностью эквивалентен варианту "в конце прерывания вызвать нужную функцию". В моем варианте это не подходит. Команды могут выполняться подолгу, до нескольких секунд, а прерывание UART должно жить и отвечать мастеру, что в случае выполнения обработки этой команды в прерывании невозможно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Команды могут выполняться подолгу, до нескольких секунд, а прерывание UART должно жить и отвечать мастеру, что в случае выполнения обработки этой команды в прерывании невозможно. В таком случае RTOS очень помогла бы. Ну а без RTOS напрашивается использование прерываний для обработки команд, причём приоритеты прерываний соответствуют приоритетам команд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 18 мая, 2011 Опубликовано 18 мая, 2011 (изменено) · Жалоба Пример: прерывание UART принимает пакет определенного формата (скажем, команду устройству, которая должна выполняться в фоновом режиме), которая должна быть обработана. Команда может выполняться долго, и обрабатываеть ее прямо в прерывании скажем так - не комильфо. Это Вы основной цикл слишком медленным сделали. Даже без РТОС можно создать приоритеты для вызываемых подзадач, и ситуёвина улучшится в разы. Приоритеты как раз могут изменяться внутри прерывания. Изменено 18 мая, 2011 пользователем _Pasha Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krom 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Некрасиво обрабатывать команды в прерывании. Обычно в прерывании реализуют приёмный буфер, а разбор и обработку команды - в главном цикле (это если без ОС) или в отдельном потоке (с ОС). А фокусы с модификацией адреса возврата и прочее - это излишняя экзотика. ОСи нет, а главный цикл очень сложный, с вводами с клавиатуры и т.д., и когда дойдет очередь до обработки команды - хз. В 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 регистров в стеке. Они отрабатываюся автомачически самим контроллером или? Мне бы мануал детальный найти... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба а главный цикл очень сложный, с вводами с клавиатуры и т.д., и когда дойдет очередь до обработки команды - хз Вот это и есть корень проблемы. И костыли с подменой адреса возврата из прерывания не сильно помогут, IMHO. В 51х все работало на ура, и здесь будет ;) А что же сподвигло уйти от 51-го? Cortex тем и хорош, что с ним не нужны все эти уловки, чтобы выжать последние соки из хилого процессора. Для Cortex можно программировать на нормальном Си, ведь это нормальный 32-разрядный процессор с приличной производительностью. Переносить на него грязные хаки из 51-го выглядит неприличным. Мне бы мануал детальный найти... Гугл пробовали? cortex-m3 manual Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krom 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба И костыли с подменой адреса Ну так и сразу костыли... Программерский трюк это не костыль ;). В любом боле-менее сносном программно-аппаратном комплексе защиты ПО таких "костылей" тьма-тьмущая, и без них вообще никак, так что-же? А что же сподвигло уйти от 51-го? Ну я не это предлагал обсудить... Переносить на него грязные хаки из 51-го выглядит неприличным. Грязные? Хаки? Чем они грязные и почему хаки? Гугл пробовали? Пробовал. Хотелось бы найти хорошую диаграммку с детальным описанием, как в мануале Филипса для 51х контроллеров. А то что в гугле по Кортексам разобраться конечно можно, но проштудировав много-много разных мануалов. Просто вопрос времени. Ведь мог кто-то уже сталкиваться с подобной задачей и решить ее? Мог. Почему бы мне не спросить? Вроде для того и форум. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shnuric 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Переключаться на другую задачю всегда надо через PendSV_Handler, так как прерывания могут быть вложеные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krom 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Переключаться на другую задачю всегда надо через PendSV_Handler, так как прерывания могут быть вложеные. Я за советом и обратился :) Задача собственно в том и стоит, чтобы по определенному событию (получен пакет с командой) как-то переключится на обработчик этой команды (может, программное прерывание?), а уж потом из обработчика вернуться туда, откуда попали в прерывание. Вероятно, я не совсем точно сформулировал проблему, сорри... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shnuric 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба //Формирование прерывания "PendSV_Handler" *(volatile unsigned *)0xE000ED04 = 0x10000000; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться