Обработка нескольких прерываний AVR (вопрос)

[festoon]

Вот последняя программка, не хочет нормально фунциклировать с усартом.

Прикрепленный файл: 1594954.rar

[nml]

А что за TMP такой?

Билдер по умолчанию использует для макрорасширений регистры R16 и R17, обзывает их TMPL и TMHP или регистровой парой TMP. Так, если вы написали инкремент переменной в ОЗУ, то билдер постороит код

var -› R16
R16++
R16 -›var

Когда он использует R16, когда R17 - предсказать трудно, поэтому в прерываниях я всегда сохранял оба.
Это проще чем каждый раз смотреть а листинг

Почему указатель стека трогать нельзя?

Блин, как все запущено... Ладно, попытаюсь. При обработке прерывания в стеке запоминается адрес возврата. Если вы измените указатель, программа вернется ХЗ куда. А если вместо RETI сделать переход на метку, то прерывание это просто больше не возникнет - потому что RETI кроме собственно извлечения из стека адреса возврата еще и сбрасывает контроллер прерываний.

[festoon]

Про стек понятно, что может вернуться хз куда. Но в программе-то это всё предусмотрено (вроде бы ), и нужный адрес в стеке и восстановление флага I.

[nml]

По поводу "последней программы"
1)при входе в прерывание тимера надо сделать так:

R16 -›
R17 -›
SREG -›

потому что последнее не может быть сделано "напрямую", а только как

SREG-›R16
R16-›

2)Мало того что вы по прежнему модифицируете стек в прерывании, что есть грубейшая ошибка, вы еще и оставляете программу там же в вечном цикле. Логика мне совершенно непонятна. Во всяком случае, прерываний таймера более точно не будет. Впрочем как и прерывания USART - оно в таблице векторов "ниже" таймерного.

3) Любой обработчик прерывания должен быть коротким, как тост. Иначе ваша программа перестанет быть реалтаймовой. А на хрена тогда прерывания вообще?

4) в прерывании USART то же с сохранением. Вот кстати фрагмент листинга (советую в него изредка смотреть):

-----          V: USART0_Receive_Complete
               F: sreg-›  ...
$008F: $B70F:     p$3F -› r16
$0090: $930F:     r16 -›
$0091: $930F:  F: r16 -› (r16-›)

то есть R16 сперва портится засылкой в него SREG, а потом дважды сохраняется.

5) В прерывании USART надо обязательно прочесть UDR, иначе флаг прерывания не сбросится и при выходе из прерывания оно же будет вызвано снова. А при nom=1 вы его не читаете.

[ra9mig]

Такое ощущение, что или в контроллере косяк или в алгоритм билдере. Возможна ли косячная компиляцияпрограммирование? Никто не замечал подобного?

Я раньше использовал AB 4.9. Проблем ни когда не было (за исключением ограничений по коду ). Очень удобный отладчик в пошаговой прогонке и анализе алгоритма (особенно если много ветвлений), и "внутренние дела" все работают (как ни странно!).
Тут поставил 5.0 , так он даже .asm толком не формирует. .Hex не проверял, не знаю!

[nml]

Про стек понятно, что может вернуться хз куда. Но в программе-то это всё предусмотрено (вроде бы ), и нужный адрес в стеке и восстановление флага I.

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

Возможна ли косячная компиляцияпрограммирование?

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

[festoon]

Блин, банальное невнимание. Действительно, ведь надо сначала, регистры загонять, потом sreg...
По поводу прерывания таймера: оно будет, ведь флаг I устанавливается сразу после загрузки стека, в процедуре stop.
То есть, я правильно понимаю, что если не сделать UDR0 -› data, то флаг прерывания не сбрасывается? Хотя да, в описании так и написано, но в билдере RXC0 сбрасывается сразу при входе в прерывание. Или опять чего напутал...
nml, если есть время и вы поняли смысл алгоритма, опишите, пожалуйста, как бы вы решили сею задачу?

[nml]

Блин, банальное невнимание.

Обычно именно из-за этого и происходят 90% ошибок, а мы ругаем компиляторы

По поводу прерывания таймера: оно будет, ведь флаг I устанавливается сразу после загрузки стека, в процедуре stop.

Это общий флаг разрешения всех прерываний. А есть еще контроллер прерываний, который зафиксировал вход в прерывание, но не увидел выхода из него. Рекурсивные же прерывания не разрешены, ибо опасны.

То есть, я правильно понимаю, что если не сделать UDR0 -› data, то флаг прерывания не сбрасывается?

Из даташита вот:

When interrupt-driven data reception is used, the receive complete routine must read the received data from UDR in order to clear the RXC Flag, otherwise a new interrupt will occur once the   interrupt routine terminates.