Коллизии прерываний

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

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

К чему нужно быть готовым и стоит ли заморачиваться разведением событий по времени?

 

http://roboforum.ru/wiki/AVR:Прерывания/Приоритетность

 

Из форума я понял, что прерывания по таймерам имеют высший приоритет и, при желании можно разрешать прерывание из прерывания. Лишь бы они не использовали одинаковые ресурсы при этом. Что же, выход, конечно, но только при крайней необходимости.

 

Понятия приоритета прерывания как и вложенных прерываний в AVR не существует, оно руками создается искусственно.

 

Вообще интересно, как отработает AVR, если ситуацию создать искусственно. Объявить обработчики INT0,1 и одновременно триггернуть обе ноги, просто связав из вместе. По идее сначала должны установиться оба флага прерывания, одно из них вызваться (какое?), а вот как при выходе из обработчика будут сниматься флаги... и что будет, если флаги прерываний оставить не снятыми...

 

Вообще в офф.доке всё чётко и ясно написано -- прерывания обрабатываются в порядке приоритета. Приоритет каждого прерывания можно узнать из таблицы в соответствующем разделе. Для ATmega328P самым приоритетным является прерывание RESET, далее INT0 и т.д.. Самый низкий приоритет у прерывния SPM READY.

В соответствии с приоритетом сначала вызовется обработчик прерывания INT0, а потом INT1.

Флаги снимаются перед вызовом обработчика прерывания. Оставить флаги не снятыми не получиться -- их можно только заново установить. Но опять же после выхода из прерывания контроллер обязательно выполняет хотя бы одну инструкцию "основного кода", а потом снова вызывает обработчики прерываний, если были установлены соответствующие им флаги.

Это некорректное утверждение -- т.к. вложенные прерывания существуют. Вот только в отличие от других архитектур (тех же x86 и AMD64) при вызове обработчика прерывания происходит глобальное маскирование прерываний. Поэтому нужно явно указывать на возможность возникновения вложенных прерываний путём размаскирования. В x86, наоборот, в обработчиках прерываний нужно явно глобально маскировать прерывания, что бы запретить вложенные прерывания.

 

Ткните пальцем где именно. По диагонали читал - не увидел.

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

 

Странно слышать такое от опытного специалиста, ну да ладно мы все "не без греха".
Документация на ATmega328P.
Раздел "7.7 Reset and Interrupt Handling":

 

Ничего странного, даташиты в голове не держу. Раздел 7.7 второпях пропустил, все накручивал мимо круги по описаниям регистров в разделах 12 и 13, которые собственно и относятся к прерываниям, там искал как "pending interrupts" реализованы. Вот, что самое главное из 12 и 13 вынесли куда-то там в 7.x, это еще догадаться нужно.

 

И все же. Одновременно вызываются два прерывания по таймеру. Сработают оба, сработает одно (которое?), не сработает никто?

 

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

 

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

 

Да, именно поэтому и "можно, но не нужно".

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

 

В итоге, если ничего руками не править и не разрешать прерывания из прерываний принудительно, будут ли они выполняться автоматически по очереди?

 

Да, похоже, что именно так и будет. Можно даже проверить... и очень просто.

 

Будут, вот только очередь с некоторыми особенностями. Когда происходит событие, которое должно обработаться обработчиком прерывания (например, пин изменил своё состояние или пришёл символ по USART), устанавливается соответствующий флаг. Этот флаг говорит о том, что, как только появиться возможность, нужно запустить соответствующий обработчик прерывания. Если до запуска обработчика прерывания произойдёт ещё одно или несколько таких же событий, то флаг прерывания как был поднят, так и останется поднятым. И не смотря на то, что одно и то же событие произошло несколько раз, обработчик прерывания будет вызван только один раз. Т.е., если по каким-то причинам прерывания будут запрещены, можно пропустить одно или несколько событий, скажем так, одного и того же типа.
Если же события были разными (для каждого есть свой флаг), то, когда появится возможность вызвать обработчик прерывания, вызовется обработчик для прерывания с наиболее высоким приоритетом. После выхода из обработчика прерывания, будет выполнена одна инструкция "основной программы". Затем, если можно будет обрабатывать прерывания, будет вызван следующий по приоритету обработчик прерывания, потом опять одна инструкция "программы" и т.д., пока не обработаются все поднятые флаги прерываний.

 

Про флаги интересно. В данный момент интересуют прерывания по таймеру, к меня их несколько, не будут ли толкаться жопами мешая друг другу? Делаю по возможности минимально, но все же.

Например как?

 

В обработчиках дергаете ноги, смотрите осциллографом.

 

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