Приоритет прерываний в AVR, что он означет? Опции

[777777]

В даташитах этот термин есть, но написано лишь что прерывания с меньшим номеров имеют больший приоритет. А что вообще означает это слово? Я считал, что в подобных системах (имеющих лишь один бит в регистре состояния для разрешения/запрещения прерываний) это означает, что если возникнут одновременно два прерывания, то первым будет обрабатываться то, которое имеет больший приоритет. Во во время его обработки бит I сбрасывается, но если выполнить sei, то мы разрешим обработку других прерываний, в том числе и с меньшим приоритетом. Просто потому, что процессор не знает, что он в нанный момент делает - выполняет обработку прерывания или основную программу. Нет у него битов определить это.

Однако сейчас, отлаживая устройство, я обнаружил странную вещь - прерывание таймера не прерывается UART-ом. Обработка UART-а задерживается независимо от того, ставлю ли я sei в начале подпрограммы обработки таймера или не ставлю. Может ли такое быть или у меня глюки? И если может, то как разрешить прерывать таймер во время его обработки?

[GetSmart]

А может таки листинг засветите прологов/эпилогов у обоих прерываний.

[777777]

А может таки листинг засветите прологов/эпилогов у обоих прерываний.

Прологи/эпилоги обычные, вот например:

Код

ISR(TIMER0_COMPA_vect)
    {
37c:    1f 92           push    r1
37e:    0f 92           push    r0
380:    0f b6           in    r0, 0x3f; 63
382:    0f 92           push    r0
384:    11 24           eor    r1, r1
386:    2f 93           push    r18
388:    8f 93           push    r24
38a:    9f 93           push    r25
и т.д.

Только зачем это? Я всего лишь хотел узнать, можно ли сделать чтобы прерывание от UART могло прервать прерывание таймера. То, что вложенные прерывания возможны в принципе, я знаю, в другой программе АЦП успешно прерывается другими прерываниями, но у него и приоритет ниже. Так может приоритет - это не только порядок в котором будут обрабатываться одновременно пришедшие прерывания, но и невозможность прервать более высокоприоритетное устройство низкоприоритетным?

Извиняюсь, действительно перепутал.
Полистал сейчас avr-libc-usert-manual и наткнулся вот на какую вещь
#define ISR_NOBLOCK

Да, есть такое. Этот ISR в самом начале вставляет sei. Это лучше, чем вставлять его после сохранения регистров, но на мою программу это не повлияло - UART так и не прерывает таймер.

[demiurg_spb]

Да, есть такое. Этот ISR в самом начале вставляет sei. Это лучше, чем вставлять его после сохранения регистров...

Это не только лучше, но и хуже т.к. в компиляторе похоже бага по части ISR_NOBLOCK:(.
Он поступает ровно так как Вы и сказали - тупо ставит sei в самом начале обработчика.
А если у вас в обработчике есть стековые переменные - всё может пойти в тар-тарары..
Т.к. он модифицирует указатель стека не в критической секции (забыв что прерывания уже разрешены)

Код

280 0116 DEBF              out __SP_H__,r29
282 011a CDBF              out __SP_L__,r28

а должен бы так:

Код

278 0112 0FB6              in __tmp_reg__,__SREG__
279 0114 F894              cli
280 0116 DEBF              out __SP_H__,r29
281 0118 0FBE              out __SREG__,__tmp_reg__
282 011a CDBF              out __SP_L__,r28

Для решения сей баги есть стандартный ход:

Код

ISR(MY_ISR)  
{
    sei();

    code....

    cli();
}

Вообщем так, молодёжь!
Объясняю на пальцах.
При возникновении разрешённого прерывания сбрасывается влаг глобального разрешения прерываний в SREG и осуществляется переход на процедуру
обработки прерывания по соответствующему вектору.
Если в обработчике прерываний "вручную" установить флаг глобального разрешения прерываний в SREG, то возможно получить вложенные прерывания.

Согласен.

Причём более "низко" приоритетное может прервать более "высоко" приоритетное прерывание.

Не согласен.
Все остальные разрешённые прерывания могут прервать выполнение текущей ISR с вручную установленным флагом I внутри этой ISR.