(извините много мусора)он попрерыванию совпадения регистра А счетчика 5 (на меге 2560), дергает ногу 12 (строка 28), к этой же ноге привязано прерывание pcint, которое дергает соответсвенно ногу 8 (строка 48).
На логик аналайзер имеем такую картину:
На эпюрах видно что фронт на выводе 8 отстает от фронта на выводе 12 на 3,2 мксек, т.е. обработка прерывания занимает 3 мксек, хочется ее уменьшить да вот как не знаю
Если в прерывании только дернуть бит, то прочитайте про ISR_NAKED, можно уменьшить (наверное) до 1 мксек. Но чтобы задержка была гарантированна, все остальные прерывания должны быть запрещены. Или уверенность, что импульс не придет во время обработки другого прерывания.
Если надо просто дернуть ногой в ответ на импульс, то можно настроить таймер на внешние тактирование, и тогда можно настроить, чтобы он он аппаратно дергал ногу, а потом программно обрабатывать доп условия.
Если есть запас микросхем - тригеров, то может проще сделать на внешнем мригере.
Ну в общем глобальная задача была устроить задержки на несколько микросекунд с помощью таймера типа загрузка числа в регистр сравнения, по совпадению -прерывание и выполнение кода, меньше 8 микросекунд не получалось, давай копать - если обработка прерываний занимает 4-3 мксек дело-швак, дергать ногой по таймеру не выход-нужно выполнять другие инструкции. А скейч (с) написал ради эксперимента проверить задержки
Чего тут еще подробнее-то?
Когда ожидаешь что должно придти событие, загоняешь программу в бесконечный цикл опроса пина, и когда на нем правильный уровень выполняешь свою работу.
Это сэкономит время на переходе в прерывание.
Я не умею “…найди то - не знаю что…” обдумывать несуществующую идею !
Конкретизируйте вопрос … Даже на новом форуме уже были решения вопросов с импульсами силами только таймеров - то есть происходит настройка таймера(ов) и он(и) уже сам(и) работает без отвлечения МК от других задач …
У вас таймер в CTC режиме может сам переключать выводы OCnA,OCnB:
“…For generating a waveform output in CTC mode, the OCnA output can be set to toggle its logical level on each
compare match by setting the Compare Output mode bits to toggle mode (COMnA1:0 = 1). The OCnA value will
not be visible on the port pin unless the data direction for the pin is set to output (DDR_OCnA = 1)…”
То есть от одного прерывания можно отказаться совсем, но выводы придётся поменять !
Я вчера ещё тему видел. ТС - коллега, что его гонять?
Алексей, напиши, что именно должно произойти при изменении сигнального пина, того что ты прераванием слушаешь.
Я тебе точно скажу, какие задержки реакций получатся на 16 МГц AVR
В общем я предполагал ( возможно наивно), что задержки при обработке прерываний приблизительно одинаковые что PCINT, что по совпадению таймера, поэтому этот скейч(с) и написал что бы оценить задержку в общем дрыгание ногой это не самоцель, а сигнал на анализатор что бы видеть реакцию. Переформулируя общий вопрос темы: Это я где-то накоячил с прерываниями или это ограничение самой системы ?