Хочется программно инициировать прерывание, Но не INT0/INT1, как бы погламурнее Опции

[Rst7]

Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?

Самый простой способ - использовать INT0, например, и сконфигурировать прерывание по изменению состояния ноги (нога на вывод), в результате - достаточно шевельнуть ножкой (изменив ее, скажем OUT'ом в PINx) и флаг прерывания установится; соответственно, когда будет разрешено прерывание INT0 - оно и произойдет. Но, к сожалению, INT0 и INT1 заняты, надо изобретать что-то другое.

Вот мысль появилась использовать прерывание от компаратора, причем следующим образом:

Компаратор штатно выключен (он не нужен в проекте), для установки флага прерывания от него использовать последовательность

Код

ACSR=(1<<ACD)|(1<<ACIS1)|(1<<ACIS0); //Comparator Interrupt on Rising Output Edge.
ACSR=(1<<ACD)|(1<<ACIS1); //Comparator Interrupt on Falling Output Edge.

Т.е. переключить туда-сюда "по фронту/по спаду". На идею натолкнула фраза

When changing the ACIS1/ACIS0 bits, the Analog Comparator Interrupt must be disabled by clearing its Interrupt Enable bit in the ACSR Register. Otherwise an interrupt can occur when the bits are changed.

в даташите.

К сожалению, сейчас негде попробовать этот чит. Посему пара вопросов:

1. Может кто делал такое и уже знает результат?
2. Может у кого есть под рукой макеточка, проверить бы?
3. А может кто гламурнее способ знает?

[SasaVitebsk]

2 GM - ты немного задачу не осознал.

Например я делаю 100 прерываний от таймера, а вот после сотого мне надо выполнить хороший кусок работы. За это время придёт 4 прерывания от таймера. Короче надо в прерывании от таймера, по какому-то событию вызвать другое прерывание. Прямой вызов - не проходит, надо чтобы из того вернулась и вошла в новое.

Короче не умею я объяснять. Пусть кто другой попробует.

[defunct]

Например я делаю 100 прерываний от таймера, а вот после сотого мне надо выполнить хороший кусок работы. За это время придёт 4 прерывания от таймера.

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

[galjoen]

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

Не. В основном цикле не пойдёт. Вдруг там уже что-то выполняется, тогда туда и вернёмся. Кроме того написано, что нужно быстро - каждый такт на счету. Т.е. видимо нужно сделать что-то более приоритетное чем основной цикл, но менее приоритетное, чем прерывания (некоторые). Например рассчёт CRC блока, который в флешку записать надо. В таких случаях приходится и с возможностью рекурсии бороться, и со стеком колдовать, и смотреть кого это мы прервали то. Только на асме такое делается (я делал). А тут видимо на C, используя прерывания, такое же хотят сделать.

[defunct]

Не. В основном цикле не пойдёт. Вдруг там уже что-то выполняется, тогда туда и вернёмся. Кроме того написано, что нужно быстро - каждый такт на счету.

Смотря как построен основной цикл.
У меня в основном цикле выполняется диспетчер задач, точнее даже диспетчер функций-обработчиков событий. Т.к. задачи выполняются бесконечно, а функции - конечно и быстро. Функции делятся по приоритетам. Приоритет драйверов периферии (диспетчер крутит их постоянно) и пользовательские приоритеты. Работает все это как часы. Никаких проблем с сохранением контекстов, никаких накладных расходов на отдельные стеки задач.
В прерываниях устаналивается готовность соотв. функций. В основном цикле - производится запуск обработчика события.
Насчет каждый такт на счету - не верю, не может каждый такт быть на счету для чего-то настолько длительного, что ест аж 4 периода таймера и в то же время настолько редкого, что происходит раз в 100 периодов таймера. Нестукуется с таким событием понятие каждый такт на счету.

[singlskv]

Насчет каждый такт на счету - не верю, не может каждый такт быть на счету для чего-то настолько длительного, что ест аж 4 периода таймера и в то же время настолько редкого, что происходит раз в 100 периодов таймера. Нестукуется с таким событием понятие каждый такт на счету.

Ну и почему же это не стыкуется ?
допустим хочу:
- передачу по SPI на максимальной скорости(кб этак 250-500 в сек) но при этом чтобы
джиттер был минимален и предсказуем
- опрос кнопок(типа процесс в 100 раз более медленный)
- запись в EEPROM когда надо(тоже не быстро).
- итд итп

ну и кто мешает это все совместить ?

Кстати, я очень обижен на атмел в том, что битики force output compare у таймеров не вызывают соответствующее прерывание output compare :-(

А Вы ими пробовали вобще пользоваться ? (битиками)
я нет, поэтому и интересно...
но кстати таймером тож можно чего-нить такое намутить, тока топикстартер не сознается какие
узлы кроме комаратора у него еще не задействованны...

[defunct]

Ну и почему же это не стыкуется ?

Несктыкуется это событие (длиной в 4 периода таймера) с надобностью обработки в прерывании.

допустим хочу:
- передачу по SPI на максимальной скорости(кб этак 250-500 в сек) но при этом чтобы
джиттер был минимален и предсказуем
- опрос кнопок(типа процесс в 100 раз более медленный)
- запись в EEPROM когда надо(тоже не быстро).
- итд итп

ну и кто мешает это все совместить ?

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

[galjoen]

Несктыкуется это событие (длиной в 4 периода таймера) с надобностью обработки в прерывании.

Тут прерывание ТОЛЬКО для того, чтоб приоритет этого события поднять, а основной цикл отдать кому то другому (на, делай в нём что хочешь, всё равно мне не навредишь).