'---------------------
' назначение векторов прерывания.
On Pcint0 Pci_ab Nosave                 'вектор внешнего прерывания от изменения уровней в порту C(0)
...
'НАСТРОЙКА ДЛЯ ATMEGA88,168
Pcicr = &B00000001                      'разрешить прерывание по изменению уровня линий портов PCI0...PCI7
Pcmsk0 = &B00001100                     'а конкретно PBI2 и PBI3
Sei                                     'разрешить прерывания
...
'ПРЕРЫВАНИЕ ОТ ИЗМЕНЕНИЯ/ УРОВНЕЙ В ПОРТУ
Pci_ab:
    Push R31                            'сохраним регистры
    In R31 , Sreg
    Push R31
    Push R30
    Push R29

'.... ДЕЛАЕМ, ЧТО НАДО.

    Pop R29
    Pop R30
    Pop R31
    Out Sreg , R31
    Pop R31
    Reti
$end Asm
Return

А почему выбраны именно эти регистры?

Я не про это. А вы уверены, что при компиляции именно эти регистры будут задействованы? По моим наблюдениям в небольших п/п прерываний компилятор "любит" использовать R24, а вообще то нужно дизассемблировать программу для того, чтобы точно узнать регистры, задействованные компилятором в п/п прерывания. Сделать это можно открыв файл obj в AVR Studio.

Я ее попробовал и... снес к чертям, хотя машина у меня вполне приличная. Для этого монстра нужен не РС, а Cray
Использую студию 4.19, да и то в качестве программатора или дизассемблера. Пишу в ней редко.
Для программирования либо BASCOM-80%, либо AVR GCC-20%. Его блокнота вполне хватает. Отладка чаще всего в железе, через СОМ.
А 5-ка Бета или уже релиз? Сегодня смотрел на сайте Atmel, там вроде бы уже релиз выложили. Правда полный инсталятор 609 метров! и Бета не апгрейдится, только полное удаление и установка.
Может получше будет работать.

Отредактировано sva-don (2012-01-29 11:53:30)

Да, программатор, инсталлятор которого весит 609 метров - это круто! 
Мне кажется, что в Atmel кто то чуток перестарался. Мне это напомнило историю с Vista. Но там Билл хоть вовремя спохватился, будем надеятся, что и нам повезет.
Кстати, в инете нужно поискать дизассемблеры. Должны там они быть. Правда студия еще и исходные строки туда вставляет чаще всего  не по месту, но очень помогает.

Отредактировано sva-don (2012-01-29 15:27:10)

Вообще, когда запускается прерывание, то оно обязано полностью отрабатывать, т.е. его нужно запрещать, но понятное дело, что потеря такта прерывания непозволительная роскошь при длительном его выполнении... Скажем в кнопках и обмене с RTS и CTS - можно, но на таймере и счетчике - нет. 

Железячные счетчики надежнее

Оно? А то он у меня не работает 
Вот, 246я страница - http://kazus.ru/nuke/users_files/19082009/8967238.pdf

10000 * 3000 / 60 = 500000

500 тысяч прерываний в секунду проблематично обработать на AVR. Даже если получится, то МК придется разогнать, обработчик писать на асме и времени на обработку будет очень мало.
Для чего это нужно? Возможно есть аппаратное решение.

Решение есть, но не на AVR (может на xmega получится, не знаю).
В STM32 один из режимов работы таймера это считывание данных с инкрементальных (квадратурных) энкодеров. Решение аппаратное и не требующее генерации прерывания на каждый щелчок энкодера. Нужно лишь периодически считывать текущее значение счетчика таймера и сравнивать с предыдущим. Но программу придется писать на Си...

Судя по этой статье, таймеры xmega также поддерживают энкодеры.

Таймер используется как счетчик щелчков энкодера, т. е. аппаратно с ним работает. Не нужно обрабатывать прерывания от входа INT. Необходимо периодически считывать содержимое счетчика таймера чтобы узнать сколько раз энкодер щелкнул после предыдущего считывания счетчика. Т. е. считайте что в данном случае таймер это аппаратный модуль для энкодера.

Если писать на асме то может и получится, но МК будет почти все время находится в прерываниях и ни на что другое у него времени не останется. Вариант с таймером хорош тем что пока таймер считает щелчки энкодера, процессор может выполнять какой-то код, т. е. процессор МК почти не будет участвовать в работе с энкодером.

А зря. Они не кусаются. В любом случае попробовать можно, ведь даже если не получится, ну и ладно...
Ладно STM32, которые сильно отличаются от AVR, но xmega это же AVR и более того, поддерживается баскомом.   Правда для них с программаторами/отладчиками все не так хорошо как для STM32 для которых программатор/отладчик стоит около 130 рублей. Да и в целом xmega в несколько раз дороже STM...