Конфликт флагов прерываний SREG- TCCR1A. Опции

[mogikanin]

Конфликт флагов прерываний SREG- TCCR1A.
Установлено ПО: WinAVR-20100110, AvrStudio418Setup+ AVRStudio4.18SP1. Программа на AVR GCC. При загрузке регистр TCCR1A=0x02. Последней операцией идёт разрешение прерываний SREG|=(1<<SREG_I);. Пробовал и SREG=0x80; - результат один и тот же: одновременно с флагом I (7-й разряд) устанавливается так же 7-й разряд в TCCR1A. И результат становится TCCR1A=0x82. Кто-нибудь сталкивался с такой проблемой? И как она решается? На форуме уже обсуждался аналогичный вопрос с взаимовлияниями TCCR1A и SREG, но я не понял решения и ситуация там была с выходом из программы, а не во время загрузки. В загрузке я после установки SREG добавил TCCR1A=0x02; - это помогло. Но как этот дефект скажется во время работы программы? Опасаюсь.

[ARV]

если вы "тупо" переделали программу на Си, не исключено, что внесли при этом ряд ошибок.
в частности, с SREG-ом в WinAVR напрямую работать нужды почти никогда не возникает, т.к. для разрешения и запрещения прерываний имеются макросы sei() и cli(). все периферийные регистры в WinAVR объявлены как volatile-переменные, поэтому оператор SREG|=(1<<SREG_I); выполняется неатомарно, что может давать странные эффекты.

используйте правильные средства - будет правильный результат.

[demiurg_spb]

поэтому оператор SREG|=(1<<SREG_I); выполняется неатомарно, что может давать странные эффекты.

Практически исключено (может кроме нулевого уровня оптимизации). SREG в SFR области и такой код превратится в атомарные инструкции SBI и CBI.
Хотя нет я погорячился. SBI и CBI адресуют лишь 32 байта, а SREG за этой границей. Так что очистка-установка битиков регистра SREG по маске в общем случае - неатомарная операция.

Также стоит покопать в сторону:

Вероятнее всего, что как только Вы разрешили прерывания глобально (бит I в SREG), то какое-то прерывание тут же и случилось... В процедуре обработки этого прерывания был установлен 7-ой бит регистра таймера TCCR1A.