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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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