Хочу такое запрограммировать - программный одновибратор 100 мсек.
Начало.
Внешние прерывания запрещаем в регистре GICR.
Разрешаем прерывания от таймеров.
Разрешаем прерывания глобально.
Задержка 100 мсек.
Разрешаем внешние прерывания.
Если за эти 100 мсек внешие события были, то флаги int0 и int1 должны присутствовать и добавляем в теле прерывания к переменной единичку.
Запрещаем внешние прерывания.
Выполняем несколько комманд основной программы с проверкой различных условий.
Переходим на начало.

Так как в даташите написано, что флаг постоянно сбрасывается если прерывание по уровню, а я не хочу мгновенно это событие обрабатывать, то вот и не знаю будет ли этот алгоритм работать.
Где еще прочитать или ставить эксперименты?

Инициализируете нужное прерывание по фронту (или спаду, как надо). После очередного разрешения внешнего прерывания анализируете вручную вход INTx. Если он в нужной полярности - запоминаете где-нибудь. Всё это можно делать прямо из прерывания по таймеру - два раза подряд на включение и выключение анализа входов внешних прерываний. GICR по-моему лучше вообще не трогать. Лучше в этом регистре сразу выключить оба прерывания, а их настроить на нужный фронт. А потом только анализировать вручную вход INTx и его "захваченный" флаг прерывания. Сам так не делал, но думаю это сработает. Загрузка процессора - минимальная.

Забыл ещё кое-что. Перед "ручным" анализом входа INTx нужно сбрасывать флаг INTFx. А через 100 мс его только считывать и можно не сбрасывать.

Конечно не установить. А сбрасывать записью 1 - это чтобы при сбросе сбросить только нужные флаги.

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

Сам бит прерывания программно не установить. Тем не менее (из даташита на mega48, в остальных аналогично):

Тут немного о другом написано. Написано что для софтовых прерываний нужно сконфигурить нужный вход прерывания как выход и установив на нём нужный сигнал вызвать прерывание. К битам INTFx это отношение не имеет. А жаль. Лучше бы софтовые прерывания вызывать менее извратно, например как в LPC-армах.

«А жаль. Лучше бы софтовые прерывания вызывать менее извратно, например как в LPC-армах.»

А зачем? Разве трудно в прогу всавить rcall Int_SubRoutine?

Ну, вот и приехали!!! Как раз все наоборот. Тут же ясно все написано. Внешние прерывания могут возникать и тогда, когда порты ВВ установлены на вывод. Но если прерывания возникли, то соответствующие флаги INTFx будут устанавливаться. Посмотрите схему конфигурации портов в DS внимательней.
Изменяя в программе значения на выходных портах (1->0 или 0->) Вы сможете вызывать прерывания в нужный момент времени. Но, еще раз повторюсь, external interrupts возникают при изменении значения на входе пина, независимо от того, как сконфигурирован порт, на ввод или на вывод.

even if переводится как "даже если", а вовсе не как "нужно".
Смысл от этого меняется кардинально.
Что же касается софтовых прерываний, то их в AVR нет вообще если никак не трогать периферию.
Согласен, что в некоторых ARM (да и других контроллерах) этот вопрос решён лучше.


При обычном вызове процедуры прерывания, т. е. собственно через прерывание, а не через call, прерывания запрещаются.
Этого нет при вызове через call. Запрещать прерывания придётся вручную до вызова.

Ну все тут прямо знатоки аглицкого как я погляжу. Только за смыслом беседы так же дотошно почему-то не следят. Смысл от "даже если" к "нужно" смещается очень легко. Нужно всего лишь прочитать все предложения в обратном порядке. Начиная с софтверных прерываний (о которых и шла речь) и доходя до того как их организовать.

Вопрос-то был всего-лишь в том, как аппаратно реализованы биты INTFx и можно ли их "вручную" установить для вызова софт-прерывания. Ну и кроме этого, какие ещё механизмы влияют на изменение этих флагов. Хотя главный вопрос - вопрос автора, как ему сделать то что нужно.

Как по мне, то любая неочевидная логика работы устройства, отличающаяся от if ... then ..., затрудняет даже собственное понимание после недели отвлечения на другой проект. Маскирование прерывания, чтобы не обработать прерывание от помех - это заботливо поставленные в собственном сарае грабли. Так можно делать, пока проект помещается на страницу текста и в голову. У меня в среднем проекте 15-20 файлов.
Вывод. Прерывания не маскировать, но при обработке его предусмотреть очевидный механизм анализа.

Я не вижу проблем в Вашем алгоритме, но боюсь что не совсем понимаю его. Вы лучше опишите что хотите сделать, а мы предложим Вам варианты.

Можно в прерывании смотреть фронт а можно, например каждый раз менять фронт и по разному обрабатывать. Можно отложить обработку прерывания, только надо учесть, что при запрете прерывания флаг выставится только один раз. Остальные будут потеряны. Лучше, как предлагает, Dog Pawlowa прерывания обрабатывать всегда. А если Вы не хочете увеличивать объём вычислений в прерывании, то в прерывании только сохранять очередь. А обрабатывать эту очередь в голове.