Какой смысл иметь прерывания, основанные на уровне?

8

Где бы я ни искал практическую реализацию основанного на уровне прерывания, я находил только одно предложение, которое давали люди, то есть отключать прерывание, как только оно входит в ISR, чтобы оно не продолжало запускаться обратно.

Еще одна вещь, которую я прочитал, заключается в том, что она используется для создания цикла, т. Е. До тех пор, пока существует прерывание, служит ISR, но этого можно достичь с помощью цикла whileили do while.

И преимущества, которые может обеспечить прерывание по границе уровня, могут заключаться в роскоши выполнения одной инструкции основной программы между обслуживанием ISR и задержкой. Я полагаю.

Так есть ли что-то, чего мне не хватает, когда дело доходит до понимания прерывания границы уровня?

Отличным ответом было бы показать мне какое-то практическое использование основанных на уровне прерываний.

MaNyYaCk
источник
... Другая вещь, которую я прочитал, заключается в том, что она используется для создания цикла, то есть, пока существует прерывание, служит ISR, но этого можно достичь с помощью цикла while или do while ... Факт может быть достигнуто одним способом, не означает, что мы должны исключить все другие способы сделать то же самое.
Евгений Ш.
@EugeneSh. Без сомнения об этом, но должно быть какое-то твердое преимущество, чтобы сделать то же самое другим способом. Не так ли? Мне больше интересно знать это «преимущество». Я просто хочу знать, какая разница в цикле с помощью операторов цикла и основанного на уровне прерывания? Если зацикливание - единственная цель, достигнутая с его помощью.
MaNyYaCk
2
Что делать, если у вас есть несколько прерываний в одной строке? Например, каждый триггер ISR обрабатывает один пакет данных, но устройство имеет несколько в очереди? В случае прерывания, инициируемого фронтом, контроллеру прерываний необходимо знать, когда обрабатывается предыдущее прерывание и когда пора отправлять следующее прерывание. Также для случаев использования, когда множественное прерывание устанавливается, когда хост все еще обрабатывает предыдущее, без запуска уровня трудно поставить их в очередь и расставить приоритеты.
user3528438

Ответы:

10

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

При использовании прерываний, основанных на уровне, обработчик прерываний может просто по очереди спрашивать каждый возможный источник прерывания «Нужно ли вам внимание» и обслуживать его, если так. Как только это будет сделано, обработчик может вернуться. Если источник прерывания, который был опрошен в начале последовательности, решает, что ему необходимо уделить внимание во время обслуживания более позднего источника, процессор заметит, что вывод IRQ все еще активен, и повторно запустит обработчик прерывания, таким образом позволяя поздно прибывающему прерыванию обслуживаться

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

Для вывода ввода / вывода может быть полезно иметь некоторую логику захвата края, которая, когда приходит край, устанавливает защелку и выводит индикацию «нужда в обслуживании», пока программное обеспечение не очистит ее. Такая вещь может появиться на самом переднем крае как чувствительное к краю прерывание. Однако в любой точке нисходящего потока лучше иметь требование по логике прерывания, чтобы прерывание обслуживалось всегда, когда какая-либо точка восходящего потока не удовлетворена.

Supercat
источник
Я хотел бы извиниться, что занял так много времени. Но вопрос, который я задал, был очень специфичен для внешних прерываний контроллера, и мне потребовалось определенное время, чтобы понять все ответы, которые пришли, учитывая процессор с контроллером прерываний. Спасибо за предоставление этого ценного ответа.
MaNyYaCk
6

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

Давайте рассмотрим типичный пример ...

Сигнал: "Case_Over_Tength" становится низким, когда температура окружающей среды в коробке слишком высокая для нормальной работы.

Очевидно, что этот сигнал может быть слабым в любое время, либо потому, что мы выделяем слишком много тепла, либо потому, что коробка установлена ​​в горячем месте.

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

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

Действительно, возможно, с преобладанием процессоров в спящем режиме прерывания, основанные на уровне, стали более полезными.

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

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

Trevor_G
источник
2

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

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

Инициируемые уровнем прерывания остаются включенными, пока ЦП не подтвердит источник. Так что есть прочная основа полного рукопожатия. Процессор может отфильтровывать шум из сигнала прерывания практически любым способом, он просто увеличивает время отклика на прерывание. Если приложение требует и учитывает хорошо отфильтрованные сигналы, запуск уровня может быть адаптирован.

Сначала я увидел прерывания, инициируемые фронтом, используемые для NMI на процессорах, таких как Z80 и 6502, в то время как маскируемые прерывания использовали уровень, срабатывающий. NMI использовали краевой триггер просто для того, чтобы помешать застрявшему штырю или заклинившему приводному контуру сохранить ЦП от повторного входа в NMI ISR навсегда. НМИ должен проявить активность, чтобы получить еще один.

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

TonyM
источник
1
Я бы не сказал, что Z80 и 6502 использовали прерывания, инициируемые фронтом, чтобы избежать проблем с «застрявшими» контактами. Вместо этого, я бы сказал, что они должны иметь возможность маскировать любые виды прерываний после начала обслуживания, а для NMI это выполняется с помощью специальной защелки «маска NMI», которая устанавливается при обслуживании NMI и очищается, когда Вывод NMI освобожден.
суперкат
@supercat, вы описали, как вы видите это, но не как Z80 / 6502 работает. Уровень NMI мог бы быть на уровне, аналогичном INT / IRQ с источником прерывания, удаленным с помощью подтверждения прерывания hw или sw. Работает отлично. Как вы думаете, что заставило их проектировать NMI как триггерный и INT / IRQ как уровень, что вы видите в качестве выгоды?
TonyM
Термин «инициируемый фронтом» используется для описания входов, которые помещают схему обнаружения фронта перед синхронизатором, так что сигнал, который приходит и уходит все в течение одного цикла, будет обработан, но я также видел, что он использовался для описания входов которые фиксируют сигнал на каждом тактовом сигнале и ищут сигнал, который отсутствует в одном или нескольких циклах, а затем присутствует в течение одного или нескольких циклов. Если NMI должен был быть подтвержден программным обеспечением, отказ признать первое прерывание будет эффективно маскировать все последующие.
суперкат
@supercat, это не так, как работает Z80 / 6502, и только они были темой моего примера, который вы задали вопрос. Если вы после дискуссии по NMI, инициируемым гранями, перейдите в чат, чтобы избежать расширенного обмена комментариями. Не уверен, что я могу добавить, хотя. Спасибо.
TonyM
Я не смотрел на детали того, как работает Z80, но согласно спецификации 6502 NMI выбирается один раз на каждые часы phi2. В листе данных ничего не говорится о времени выборки / удержания, но из того, что я читал в другом месте, импульсы NMI, которые отсутствуют по крайней мере в трех последовательных выборках, не всегда будут обрабатываться.
суперкат
1

Поддержка на основе уровня ISR Ack / Nak, которая полезна, когда у вас много источников.

Если у вас много ISR и много рангов приоритетов как в SW, так и во внешнем HW с ранжированными приоритетами.

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

Таким образом, оба края и уровня имеют преимущества в разных архитектурах.

Чтобы не пропустить Edge IRQ, его необходимо включить, а затем протестировать сразу после окончания ISR.

Некоторые уровни IRQ могут длиться дольше, чем ISR, и обнаруживаются, если ожидается.

Тони Стюарт Sunnyskyguy EE75
источник
1

Именно тогда, когда используется «партийная линия» вместе с открытым стоком или открытым коллектором, когда режим работы на уровне имеет больше смысла.

В этом случае каждая «сторона» на линии активирует свой вывод, когда им нужна «служба». Когда программное обеспечение для обработки прерываний отключается и опрашивает (а затем обрабатывает) каждое устройство по очереди, эти устройства освобождают свое удержание и становятся неактивными. В конце концов, прерываний (уровня) больше не осталось, сама линия прерываний становится неактивной, а программная обработка прерываний снова становится "неподвижной".

Йонк
источник
1
это имеет значение. Что делать, если хост получает другой фронт на другой линии, когда он уже обрабатывает прерывание? несколько вариантов: 1) игнорировать входящее прерывание; 2) поставить его в очередь на оборудовании; 3) прервать текущий обработчик прерываний и обработать новый, либо обработать его полностью, либо поставить его в очередь на потом. С помощью триггера уровня вы просто оставляете его там, и он все равно останется для вас, чтобы обработать его после завершения текущего ISR.
user3528438
@ user3528438 Я отвечаю на вопрос «почему уровень». Так что я просто уберу эту часть и избегу споров.
Йонк
1
Даже при использовании выделенных прерываний я бы предположил, что инициируемые фронтом прерывания лучше только в том случае, если кто-то может быть заинтересован в реагировании на событие, которое могло прийти и исчезнуть к тому времени, когда его можно обслуживать, и даже там, используя фиксацию событий Устройство для управления чувствительным к уровню прерыванием может быть столь же полезным, как и использование чувствительного к фронту прерывания. Инициируемое ребром прерывание может сохранить инструкцию, которая в противном случае потребовалась бы для очистки защелки, но это, как правило, не имеет значительных затрат или экономии.
суперкат
@supercat Я перефокусировал свой ответ, чтобы прямо ответить на названный вопрос, чтобы избежать участия в какой-то длинной, грязной главе и стихе. Гораздо проще (Да, я использую всевозможные методы прерывания с ... 1974 года ... поэтому, я думаю, я видел все причины, я думаю. Я просто не хочу обсуждать их сегодня.)
Джон