Столкнулся с проблемой.
Долго мучался и ветаки поборол, но как-то странно!

Опишу кратко.
Используется два прерывания:

1:0x01A Timer/Counter1 Compare Match A - режим CLC (частота 44100 Hz)
2:0x020 Timer/Counter0 Compare Match - режим CLC ( частота 500 Hz)

У второго прерывания приоритет ниже и первая команда его обработчика SEI.
Все регистры и флаги сохраняются в каждом обработчике.
Проблема в том что во втором прерывании необходимо читать состояние PIND.4
Состояние пина иногда считывается 0-м в то время как он в 1-це.

В таком виде глючило:

CBI PORTB,7
SBI PORTB,7
ROL RTMP
SBIC PIND.4
ANDI RTMP,$01

добавил запрет и разрешение прерываний и глюк ПОЛНОСТЬЮ пропал:

CLI
CBI PORTB,7
SBI PORTB,7
ROL RTMP
SBIC PIND.4
ANDI RTMP,$01
SEI

Что это, глюк меги или я чегото не понимаю?
Ктонибудь сталкивался с подобным?

Это глюк автора программы, вероятно, забывшего о необходимости сохранять SREG.
Впрочем - это чистая телепатия, потому что из того, что Вы написали, вообще понять ничего невозможно. Дайте больше информации.

Я ж написал что "Все регистры и флаги сохраняются в каждом обработчике.
"

Попробую.
Вся проблема в том что если во время приведенных мою 5-ти команд 2-го обработчика выполняется другое прерывание то состояние 4-го пина порта D командой CBIC интерпретируется не верно.

Сообщение отредактировал zombi - Jan 27 2009, 12:48

В стеке? Код полностью огласите плз.

Полность очень много!
Попробую частями.
Настройка и разрешение прерываний:

Обработчик timer1:

Обработчик timer0:


Проблема в том что даже если на PIND.4 тупо VCC подать, то младший бит в ячейке $8000 не всегда =1 если в обработчике TIM0 нету CLI/SEI во время его опроса.

Опускаю Ваши небрежности (код выхода из TIM0, код инициализации TIM0) - я так понял, что в реале там все нормально ?
Несогласен раз:

Несогласен, часть вторая: пожертвуйте регистром 

ЗЫ марш несогласных
Раньше была проблема такая с sbrc/sbic sbrs/sbis но это было давно.

Может происходит повторный вызов TIM0? Вы же не запрещаете "ЭТО" прерывание.

Пропробуйте так:

Спасибо всем ответившим.

Через рег тоже пробывал, не помогло.

А что с выходом из TIM0? Если вы имеете ввиду RET а не RETI то я же прерывания разрешаю в теле обратотчика.

Ув. _Pasha подскажите что не правильно в инициализации TIM0?
Просто я всегда так инициализирую, подскажите где ошибка.


Незнаю. Надо попробывать . Спасибо defunct.
Но думаю что прерывание должно срабатывать по фронту?
Но даже еслиб вход выполнялся несколько раз то в мл.бите регистра RTMPA всеравно должна быть единица ведь состояние PIND.4 стабильно.


Попробывал. Результат отрицательный. Глюки продолжаются.



И так пробывал но тоже глючит.
Глюки исчезают только если CLI находится перед LSL или еще раньше, но никак не перед SBIC:


Сообщение отредактировал zombi - Jan 27 2009, 14:49

1.Инициализация


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

2. Код входа и выхода 

Конечно с таблицей векторов и POPами PUSHами все впорядке.
Это просто апычатки sorry.

Значит где-то чистят Ваш RTMPA без сохранения/восстановления. Поставьте условный брекпоинт на запись в регистр и дебажьте до победы.

Не думаю что я гдето порчу RTMPA ведь с CLI/SEI нечего не портится!!!
Всетаки мне кажется проблема с входом в прерывание в момент выполнения SBIC/S возможно даже именно с PIND.4.
В любом случае экспериментировать надоело , запрет/разрешение прерываний спасает и пару лишних тактов не жмет, работает и бог с ним.

Интересно.
Я не сталкивался, но в первых моделях указывали про ошибки возникающие именно при прерывании и именно при исполнении комад sbic/sbis. Правда, если команда следующая за этими командами - двухсловная.
При этом про команды BLD/BST никогда ничего не было.

Всётаки я думаю, что вам надо исходить из постулата, что это ваша ошибка. И, соответственно, искать её корни. Иначе она вылезет в другом месте и в другом виде. А заплатки ставить - не пацанский метод.

А из стека, кто байт флагов будет вычищать?

Сообщение отредактировал uau - Jan 28 2009, 10:50

Прошу прощения за поднятую бучу!
Все оказалось гораздо проще.
Ко входу D.4 подключен выход сдвигового регистра 74hc157.
Опрос пина был сразу после строба SCK и регистр просто не успевал переключится.
Частота процессора 16MHz а у регистра время установления выхода большое вот от он то успевал то нет.
А команда CLI просто добавляла необходимую задержку

Но благодаря defunct возможно сразу избежал следующего косяка с прерываниями:
Если время выполнения прерывания TIM1 окажется больше чем период TIM2 то возможен повторный вход в в TIM2.
Устранил эту ситуацию запретом прерывания по TIM2 путем записи в TIMSK на старте и последующим разрешением на выходе.