Форум arduino.ua

Olej, вижу ты не успокоишься никак. А теперь к этим 100001 шт. причисляй ка уже и себя.
Объясню как нельзя проще: 4 порта прерываний, по описанию,  ОДИНАКОВЫЕ.
Пишу тестовый скетч для всех разом и для каждого в отдельности. В attachinterrupt ставлю по очереди RISING, затем FALLING. Подаю на каждый порт, по очереди, одинаковое кол-во импульсов - 100. Порты 18, 19, 20  прерываются именно 100 раз, а 21-й 70 раз.
Теперь понятно, наконец?
Ставлю всем HIGH, все 4 теперь прерываются 100 раз.
А по описанию свойств портов, они одинаковые.

1.2.1. Asynchronous Sensing in ATmega2560
From Table 1-2 External Interrupts Sense Configuration interrupts INT3:0 are registered asynchronously. Pulses on INT3:0 pins wider than the minimum pulse width (typically 50ns for ATmega2560) will generate an interrupt. Shorter pulses are not guaranteed to generate an interrupt.

источник: INT0-INT3 ; вектор: 2-5; порт: PD0-PD3. По даташиту они одинаковые.

По даташиту про хай, правда нету упоминаний. Надо бы CHANGE опробовать.

Так это ж не природа, это ж творение рук человеческих. Мегу, я имею ввиду. А тут чудес хватает. В своих Errata-х обычно производители свои косяки описывают. Но я ж писал, некогда было ерраты на 2560 искать. Нашел решение сам и гут.

При чем тут вектора и фьюзы?

Эт точно, в голове. 

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

Nefreemen, да, как я вижу все действительно плохо. Как говорится - "слышал звон, да не знаю где он". Дальнейшую дискуссию в этой теме считаю просто нецелесообразной, когда пишут такие знатоки МК. Тема называется "Прерывания Mega2560". А уж с бутлодырем кристалл или без него - значения не имеет. Где бы вектора на обработку ни находились, они не меняют технических свойств входов прерываний. И фьюзы их тоже не изменят.

А что? Фьюзы уже за прерывания отвечают? ПисАл на чистый кристалл. Без загрузчика. Потому, что загрузчик перехватывает сигнал, например, по UARTу, чтобы прочухать, что к нему ломятся по поводу  прошивания. Ну и хрен его знает, что он еще может перехватывать. Но этот вопрос уже отвалился.  Да и по фиг, где и в какой секции находится переход по прерыванию. Ардуина IDE не оперирует адресами прерываний в чистом виде. Если прерывание возникло, оно запишется в регистре прерываний, т.е. там установится флаг этого прерывания  и встанет в очередь обработки. И как только мы закончим обработку текущего прерывания, по выходу из обработчика мы попадаем на обработку следующего прерывания, поскольку по команде RETI, какая стоит на выходе из прерывания, автоматом разрешаются все прерывания. А под идентичностью я понимаю характер прерываний лоу, хай, перепады. Кстати, вот кусочек статьи, по прерываниям в AVR:
   "Также любое прерывание имеет свой флаг прерывания. Этот флаг устанавливается в "1" в момент, когда должно произойти прерывание, даже если прерывания глобально запрещены и соответствующая программа обработки прерывания не вызывается. Можно, например, внутри какого-нибудь обработчика прерывания по этому флагу проверять было ли какое-либо прерывание или нет. Флаги внешних прерываний являются 7-м и 6-м битом регистра GIFR. Флаги прерываний сбрасываются записью в них "1"." 7-м и 6-м это про Атмегу 8.

Именно.

Передаю бесценный опыт суточного поиска решения проблемы:
хреново я пробовал другие режимы интерраптов на этих ногах. Значит так: 18,19,20 в любом режиме считают одинаково. А вот 21-я правильно считает только LOW или HIGH. Перевел я и другие ноги в режим HIGH и, блин, песня! Проект можно считать сданным!
21-я нога хреново отрабатывает и FALLING и RISING. Я то сначала думал, что Ардуинов бутлодырь подсирает как-нить.
Залил HEX в чистый кристалл, без бутлодыря, таже хрень, ну и докопался, в итоге, что к чему. Уря-я-я-а!