Я этого и не говорил. Я сказал о нюансах использования прерываний по уровню в AVR. Мы же о AVR говорим? Или я ошибаюсь?



Вот и ладненько. Спасибо за инфу. Просто я юзаю модели Мег, которые были разработаны более 3-х лет назад. Там такого не было.

Как говоритцо, "Век живи - век учись"(с)

Мы говорим об особенностях работы прерывания по уровню при постоянно поданном запросе, с 8-го поста - о "первоначальном" предназначении прерываний по уровню, которое "первоначалось" через десятки лет после того, как сами эти прерывания были придуманы.
В принципе, всё вышесказанное справедливо и для i80c31.

"мухи времени любят стрелки" :-)
Думаю, гораздо больше трёх.
avreal поддерживает программирование atmega48-168 уже больше четырёх лет.
Ну а если об AVR вообще, то тини26, мега162 уже лет шесть существуют.

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

Я бы сказал так: Тогда и только тогда, когда процессор может сообщить устройству, что запрос обработан и этим заставить устройство снять запрос. Чаще всего это нужно, как уже писали, когда на один вход заведено несколько источников. Тогда запрос будет висеть до тех пор, пока процессор не обработает (и в процессе обработки не снимет) все запросы.

Недавно узнал, что оказывается прерывания процессора по сигналам на линиях INT можно сгенерировать и программно. Достаточно запрограммировать пины INTх на вывод и выставить на них '0' командой OUT

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

а энергосбережение тут точно не причём)))

Вот этот ответ самый близкий. Если в подпрограмме обработки прерываний сделан запрет на обработку прерываний более низкого уровня (неважно как сделан - аппаратно или программно), то фронт поступающий на запрос прерывания низкого уровня может быть пропущен. А вот уровень - нет.
Поэтому, для медленных систем, т.е в которых мало запросов и их пропуск не критичен, можно делать обработку по фронту, а для систем, где пропуск запроса критичен - только по уровню...
Но при этом, запрос по уровню может быть обслужен позже, чем по фронту из-за того, что он может быть задержен обработкой запросов более верхнего уровня.
Вот и вся разница. Такая система работает с первых интеловских контроллеров и до сих пор. Про DEC (Электроника 60) не пишу, там распределенный арбитр и пропустить прерывание в принципе невозможно....
Удачи!

ха если придёт несколько фронтов от одного устройства то и так потеряется несколько прерываний.

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

А у вас тут весело.Фронт,спад,уровень......Просто красота.А если взглянуть на процесс на осциллографе,а не в описании?Любому уровню ВСЕГДА предшествует перепад.Те говорить об срабатывании по низкому уровню и не вспомнить о предшествующему ему,уровню,срезу(спаду) сигнала неправильно. Кстати высказывание тов БОИНГа о переходе из спячки по НИЗКОМУ уровню не совсем справедливо,можно также сказать о пробуждении по срезу и будет тоже правильно.