Есть некоторый код, проблема в том что имеется переменная которая после выхода из прерывания восстанавливает своё значение,
т.е. независимо от volatile компилятор по ходу разместил
переменную event_flag в регистре??!!!
При чём данная ситуация возникает не часто, иногда установленное значение
в прерывании остаётся и после выхода из него((


/////////////////////////////////
// AVR Studio 4.16 Build 628 //
// WinAVR-20090313 //
// Atmega8535 //
/////////////////////////////////

............................
volatile uint8_t event_flags;
#define START 0x01
............................
#define PACK_NOW 0x20

volatile uint8_t macro_rx = 0;

ISR (USART_RX_vect)
{
.............
.............
event_flags |= PACK_NOW;
macro_rx = 1;

//тут PACK_NOW устанавливается, но после выхода из прерывания,
//в event_flags восстанавливается предыдущее значение

}

void main_loop()
{
............
............
if(macro_rx)
{
if(!(event_flags & PACK_NOW))
{
//!!!!!! ОШИБКА !!!!!!
//т.е. macro_rx так и осталась в установленном в прерывании значении
//а event_flags нет!!!
}
}
............
............
}

int main()
{
while (true)
{
main_loop();
}
}

Помогите разобраться в ситуации...

Переменная сама по себе никак не может принимать произвольные значения.
Где то идёт запись в эту переменную.

Приведите весь код, работающий с данными volatile переменными.

А где написано что event_flags принимает произвольные значения?
Это не весь код, в начале программы выполняется event_flags |= START;
Затем пошагово выполняю код в avr studio. Иногда натыкаюсь на вышеописанную ситуацию: В прерывании event_flags устанавливается (значение изменяется, видно в окне Watch), а на следующем шаге - выхожу из прерывания и вижу что event_flags снова равна START

Весь код проблематично привести...

Поиском найдите где эта переменная ещё меняется. И подумайте в каком из этих мест она может затираться.

Очень маловероятно чтобы эта переменная была в регистре. Листинг скажет точно.

Я же описал выше: Хожу по коду пошагово по F11,
Попадаю в прерывание USARTa здесь пошагово дохожу до строчек

event_flags |= PACK_NOW;
macro_rx = 1;

Смотрю в окно watch - переменная event_flags равна установленному вначале программы значению (0x01), затем выполняю 2 вышеприведенные строчки и вижу как event_flags стало равно 0x21, а macro_rx стало равным 1, затем снова делаю шаг по F11, и выхожу из прерывания и попадаю в main_loop, В ОКНЕ watch снова event_flags равен 0x01. Т.е. никаких команд после выхода из прерывания не было, а значение поменялось. Это могу объяснить только тем что event_flag была в регистре.

Ходите по асм-коду. Там всё предельно ясно - в регистре или нет.

Включите генерацию компилятором ассемблерного кода и посмотрите, где лежит переменная. Глюки компиляторов тоже встречаются, но реже, чем ошибки программистов.

В AVRStudio добавте переменную в Watch и увидите где она расположена.

В файле mega32.map переменной event_flags нет вообще это может чтонибудь значить?

Дался вам этот волатайл. При чем тут вообще это? Обычная статическая переменная. Ей без разницы, где она лежит, в регистре или в памяти. Если компилятор ее в регистр положил, наверное этот регистр никто больше не используют. 99% процентов что ваша программа кривая.

А есть опции оптимизатора? Если есть возможность спуститься на несколклько шагов в оптимизации и посмотреть как будет работать?

Ну второе , что можно посмотреть : по мапу посмотреть какие переменные размещаются до этой переменной, если там есть массив - надо насторожиться и попробовать ему размер увеличить - может он проезжается .

Есть и посвежее - рекомендую...

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

При том... Читайте стандарт там всё подробно описано.

А у вас в main_loop'е случайно нет локальной переменной event_flags?

Всем спасибо за помощь. Действительно в одном из участков кода проморгал атомарность((

ЗЫ: Старался всегда учитывать эту возможную бяку, но никогда ещё на неё не попадал. А ведь хорошо что попал, впредь буду более внимательно относится к битовым операциям.

Присмотритесь повнимательнее в пространство SFR - GPR0 итд - меняются легко флаги, это если не хочется в регистре переменную держать.

Грязный хак
Не люблю такие заходы...

Если Вы о портабельности, то ее здесь нет. А если не о портабельности, то о чем?

А я тоже без стеснений юзал битовые поля в неиспользуемых регистрах вместо переменных. Иногда байтовые, типа TWAR,TWDR.

Я о том, что этот заюзаный не по своему назначению регистр может быть неожиданно востребован.
Не Вами так наследниками Вашего хозяйства (а мужики то не знали...)
Чтобы даже гипотетически не закладывать проблемы, я всегда воздерживаюсь от таких вот выкрутасов.
Ибо почити всегда есть более прямое решение, как например не использовать битовые переменные вовсе (для AVR - это отличный способ избавиться от геморроя).
Таков мой подход и я его не навязываю. Вольному - воля!

Попутно ещё вопросик:
Например есть код

ISR()
{
adc_flags |= PROCESS_I_NEG;
}

loop()
{
...................
if ( adc_flags & PROCESS_UOUT_POS )
{
cli();
adc_flags &= ~PROCESS_UOUT_POS;
sei();
}
else
{
}
..........
}


Компилятор превратит во чтото следующее

;if ( adc_flags & PROCESS_UOUT_POS )

R24,adc_flags

;/////////////////////////////////
; ТУТ ВОЗНИКАЕТ ВДРУГ ПРЕРЫВАНИЕ
;(где сохраняется регистр R24, затем добавляется бит PROCESS_I_NEG к adc_flags
;и воосстанавливается R24)
;/////////////////////////////////

;далее продолжается выполнение if
SBRS R24,1<<PROCESS_UOUT_POS
RJMP m1

;adc_flags &= ~PROCESS_UOUT_POS;

А вот тут вопрос:
будет ли компилиться так (т.е. в R24 снова считывается adc_flag)
CLI
LDS R24,adc_flags
ANDI R24,~PROCESS_UOUT_POS
STS adc_flags,R24
SEI

или же возможна ситуация когда компилер
не будет считывать в R24 переменную adc_flags, а посчитает что она ранее была считана
в R24 и таким образом не учтёт изменение её в прерывании

Т.е. другими словами, необходимо ли и для if тоже использовать атомарность например в виде

cli()
rez=adc_flags & PROCESS_UOUT_POS;
sei()

if(rez)
{
.......
}

Если переменная волатильная, то компилер обязан её считывать каждый раз оттуда, где она лежит, и никак иначе. Т.о. перед IF не нужно запрещать прерывания.

Переменная однобайтовая. Какая атомарность?

Да байтовая но в ней 8 бит-флагов:
как происходит изменение бита в ОЗУ, а вот так:
1 load
2 modify
3 store

так если произойдёт прерывание между пунктами 1-3 изменяющее этот же байт, то все изменения сделанные в прерывании будут похерены пунктом 3.

И напоследок:
volatile нужен для любой переменной хоть битовой хоть байтовой, хоть QWORD , если эта переменная используется (пишется или только читается) в прерываниях или является частью SFR.

Всё! Учим наизусть и повторяем вместо мантры:-)

Не хотите читать стандарт - поищите по форуму, тема про volatile уже неоднократно всплывала.

Код посмотри:

Си:
adc_flags &= ~PROCESS_UOUT_POS;

Асма:
LDS R24,adc_flags
ANDI R24,~PROCESS_UOUT_POS
STS adc_flags,R24

Если эта переменная используется и в прерываниях и в основном цикле (или в нескольких потоках при использовании ОС).

Да volatile к этой проблеме никакого отношения не имеет, и никак не поможет! Тут единственное что поможет, так это запрет прерываний на время доступа!


Да ради бога, только если у вас разграничение доступа не организвано должным образом, работать не будет все равно, volatile или нет. Иными словами, от критических секций вы все равно не избавитесь.

Для байтовой переменной на AVR избавлюсь от критической секции. И работать будет только если volatile.
Я Вас не пойму. Вы что-то из пустого в порожнее всё переливаете и переливаете. К чему это?
Перечитайте Ваши сообщения в этой ветке. Либо странные утверждения либо повторение за кем-то прописных истин после доходчивого разъяснения...

Ваша формулировка как всегда более точная:-)