Разрешить прерывание, но нет ISR

Я хотел бы знать, что происходит, если прерывание включено (например: Арбитраж потерянное прерывание в модуле CAN LPC1778 NXP), но ISR не был определен для прерывания.

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

Любые решения о том, что может произойти, могут действительно помочь мне.

Спасибо.

Обновить:

Я включил прерывание CAN на моем uC, но не определил ISR. Когда я выполнил внутренний тест обратной петли, код вошел в бесконечный цикл. Вот код разборки бесконечного цикла, выполняемого на LPC1778:

B       .
ENDP

Так что, если вы используете прерывания, используйте ISR.

microcontroller interrupts can AlphaGoku
источник

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

brhans

Вы говорите, что флаг прерывания Bus Arbitration Lost будет установлен, даже если я не включу «interrupt on Bus Arbitration потерянный» (хотя нет регистра состояния, который мог бы указывать потерянный арбитраж шины, кроме регистра состояния прерывания)?

AlphaGoku

Да. В каждом MCU, с которым я работал, флаги прерываний устанавливаются всякий раз, когда возникает условие, которое должно их устанавливать. Включение прерывания заставляет MCU передавать вектор обработчику, когда установлен соответствующий флаг, и отключение прерывания заставляет его игнорировать флаг, а не вектор обработчику, даже если флаг установлен . Отключение / прерывание прерывания влияет только на поведение обработчика перехода к прерыванию, а не на поведение установки флага.

brhans

Вау. Это то, чего я не знал. Большое спасибо. Таким образом, каждый драйвер должен также периодически проверять регистры состояния прерываний и сбрасывать их, даже если прерывания не были включены :)

AlphaGoku

@AkshayImmanuelD, только если это имеет значение. Если прерывание всегда отключено и ничто иное не заботится о флаге, то установить его или сбросить не имеет значения.

Хоббс

Ответы:

Если ISR не определен, местоположение для команды перехода в векторе прерывания будет либо нулевым, либо это может быть переход к подпрограмме исключения, либо переход к началу программы, либо он может содержать «возврат из прерывание "(например, RTI).

Ниже приведена разборка таблицы прерываний для процессора ATMega 16, показывающая три неиспользуемых прерывания, отнесенных к подпрограмме, которая обрабатывает такие случаи (она может просто войти в бесконечный цикл), и один допустимый вектор.

  28:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>
  2c:   0c 94 5c 00     jmp 0xb8    ; 0xb8 <__vector_11>   // <-- ISR
  30:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>
  34:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>

Какой из описанных ранее методов обработки отсутствующего ISR будет зависеть как от архитектуры микроконтроллера, так и от компилятора. В случае RTI или эквивалентной инструкции, она немедленно вернется к заявке. Однако, если прерывание инициируется по уровню, а не по фронту, то это, вероятно, приведет к повторному запуску прерывания, поэтому вы попадете в бесконечный цикл.

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

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

Но в любом случае плохая практика - иметь прерывания в системе и не определять ISR. Не делай этого.

tcrosley
источник

.... или это может быть неопределенным.

Ваутер ван Оойен,

@WoutervanOoijen это то, что я имел в виду, когда вектор прерывания равен нулю.

tcrosley

Регистры состояния не могут указывать на несколько ошибок, подобных той, о которой я упоминал выше. Но такие ошибки имеют прерывание. Поэтому я подумал о том, чтобы разрешить прерывание, чтобы просто идентифицировать ошибку и не использовать какой-либо ISR. При моделировании LPC1778 с использованием Keil я не получил никаких исключений, поэтому я полагаю, что ОК должен использовать RTI, как вы упомянули

AlphaGoku

Что-то, о чем нужно знать - если вы включите прерывание, но ваш обработчик не снимает флажок (или нет обработчика, а поведение по умолчанию - простой возврат), то вы, скорее всего, обнаружите, что ваш MCU закончится навсегда застрял в цикле прерывания.

brhans

Прерывания PIO на ATSAM3X8E могут запускаться по фронту, но однажды заданное условие прерывания не будет очищено до тех пор, пока вы не прочитаете ISR (регистр состояния прерывания) в обработчике прерываний, что приведет к упомянутому циклу @brhans.

Саймон Райт

Это зависит от вашего MCU, компилятора и остального кода.

Из моего опыта:

AVR - по умолчанию, если вы не укажете ISR, вектор прерывания во флэш-памяти будет 0x0000, что означает, что ваше приложение будет перезагружаться при каждом возникновении этого прерывания.

Если вам действительно нужно прерывание, но не нужен обработчик (например, используйте режим АЦП с низким уровнем шума и используйте прерывание только для пробуждения MCU), вам следует использовать макрос EMPTY_INTERRUPT
NXP Kinetis (ARM) - все векторы по умолчанию указывают на обработчик по умолчанию, имеющий точку останова, процессор просто остановится и сообщит об этом вашему отладчику.

фило
источник