Прерывания USART AVR32. Опции

[DeadCodder]

Здравствуйте!

Подскажите в чем может быть дело -

процессор AT32UC3A3256, прерывание по приему для одного (UART0) UART работает, для остальных нет.
Чтение без прерываний работает, что подтверждает правильность настройки самого модуля.

Инициализация прерываний аналогична во всех случаях.

Что может быть причиной?

[slavik.ksu]

Доброго времени суток!
Новую тему не стал заводить, название вроде подходит? кристал маленько другой

Объясните пожалуйста такую вещь:

1 случай:
ldi temp , 0b00000011 ; активирую таймер с делением частоты на 64
out TCCR1B,temp
ldi temp,(1<<TOIE1 ) ;активирую прерывание по переполнению!
out TIMSK,temp

обработчик прерывания:
perepolnenie:
in temp, PortB
eor temp,r18
out PortB,temp
reti
В этом случае светодиод моргает с частотой 1 раз в скунду

2 случай:
ldi temp , 0b00001101 ; запуск таймера T\C1 с делением !!! на 1024 !!!
out TCCR1B,temp ; режим(CTC) сброс при совпадении

ldi temp, 0xFF ;здесь записываю максимальное число
out OCR1AL,temp ;по сути получается "прерывание по переполнению"
ldi temp, 0xFF ;
out OCR1AH,temp ;

ldi temp,( 1<<OCIE1A) ; разрешение прерывание по сравнению
out TIMSK,temp

НО!!! в этом случае, не смотря на то что деление частоты большее,
т.е. таймер должен работать медленней,а моргание происходит чаще!
Как такое может быть?


Работаю на отладочной плате STK500, на Atmega8515
полный код прилагаю.

Прикрепленные файлы

 __________.rar ( 2.1 килобайт ) Кол-во скачиваний: 17

 

[Xenia]

НО!!! в этом случае, не смотря на то что деление частоты большее,
т.е. таймер должен работать медленней,а моргание происходит чаще!
Как такое может быть?

Может. Потому что при прерывании по переполнению счет ведется от заданного значения вверх до переполнения, а в режиме CTC - от нуля до заданного значения. И эти отрезки по длине разные!

Представим себе ситуацию, что задано значение 10, а переполнение происходит после 255. При этом я считаю в 10 раз медленнее, чем вы. Но я считаю в режиме CNC от нуля до 10, а вы в режиме переполнения с 10 до 255. Кто из нас быстрее достигнет прерывания? - Я! Потому что мне надо перечислить только 10 чисел, а вам 245. И тут я со своей в десятеро медленной скоростью стравлюсь быстрее.

[slavik.ksu]

Может. Потому что при прерывании по переполнению счет ведется от заданного значения вверх до переполнения

а это значение как задается? в каком регистре храниться?

[_Артём_]

а это значение как задается? в каком регистре храниться?

При переполнении:
TCNT1=<заданное значение>

При совпадении максимум счёта определяется OCR1A(B,C).

[slavik.ksu]

При переполнении:
TCNT1=<заданное значение>

Чтобы после каждого прерывания счет шел с этого "заданного значения", его надо прописывать в конце обработчика? правильно я понимаю?
А если его проинициализировать один раз, то счет после переполнения будет начинаться с нуля?

[ILYAUL]

Чтобы после каждого прерывания счет шел с этого "заданного значения", его надо прописывать в конце обработчика? правильно я понимаю?
А если его проинициализировать один раз, то счет после переполнения будет начинаться с нуля?

Возьмите DS на свой процессор и почитайте про режимы работы таймеров AVR. Есть куча изданий и на русском языке - интернет в конце концов

[Xenia]

Чтобы после каждого прерывания счет шел с этого "заданного значения", его надо прописывать в конце обработчика? правильно я понимаю?
А если его проинициализировать один раз, то счет после переполнения будет начинаться с нуля?

При прерывании по переполнению, TCNT1 приходится обновлять каждый раз в процедуре прерывания. Потому что TCNT1 это есть тот самый счетчик, число в котором насрастает со временем. Поэтому в процедуре прерывания там 0 (или чуть больше, т.к. сама процедура прерывания и сохранение значений рабочих регистов в ее начале тоже занимают время).

А в прерываниях по совпадению (CTC) уровень в регистре OCR1 обновлять не надо, т.к. его значение при сравнениях не портится, оставаясь постоянным, а значение TCNT1 аппаратно сбрасывается на 0 в момент совпадения.

Первый способ организации часов теоретически чуть менее точный, т.к. часы будут маленько отставать из-за того, что устанановить свежее значение TCNT1 точно в момент прерывания невозможно, поскольку между моментом переполнения счетчика и выполнением присваивания TCNT1 нового значения проходит какое число циклов, потребных для перехода в прерывание, сохранение значений рабочих регистов в ее начале и самой операции присваивания. Тогда как организации часов по совпадению (CTC) лишена этого недостатка, т.к. код, выполяемый в процедуре прерывания никак не участвует в ходе часов. Однако разница эта настолько мала, что ею спокойно можно пребречь.

[slavik.ksu]

При прерывании по переполнению, TCNT1 приходится обновлять каждый раз в процедуре прерывания. Потому что TCNT1 это есть тот самый счетчик, число в котором насрастает со временем. Поэтому в процедуре прерывания там 0 (или чуть больше, т.к. сама процедура прерывания и сохранение значений рабочих регистов в ее начале тоже занимают время).

Спасибо, полностью разобрался!