Обычная переменная для ISR и volatile для всех остальных, как лучше реализовать? Опции

[sonycman]

Что-то вот задумался над одной мелочью, в принципе.
Есть переменная таймера, которая объявлена как volatile, так как модифицируется в обработчике прерывания.

Всё бы хорошо, да только хотелось бы, чтобы эта переменная была volatile для всех, кроме самого обработчика прерываний, так как лишние сохранения/загрузки в нём - это совершенно лишнее.

Есть мысля сделать так:

Код

union {
dword isr_timer;
volatile dword timer;
}

и в ISR юзать isr_timer, а в других местах - просто timer.

Что скажете?

[kimstik]

Я стараюсь union реже использовать - это одна из самых непереносимых и компилерозависимых вещей.
Не все компилеры понимают безымяный union. Длинные бестолковые имена. Куча не всегда понятных переменных.
А то что в хедер для проверки не вставить объявления - это цена вопроса.
Вы же сами просили решения(хака)? Значит вам за него и отвечать.

[zltigo]

Длинные бестолковые имена. Куча не всегда понятных переменных.

С точностью до наоборот - позволяет создавать толковые имена и понятные переменные.

[777777]

А ты не пробовал объявлять ее вообще без volatile? Вообще-то это требуется крайне редко, например, в подобном коде:

int n = 10;
while(n--)
{}

Здесь компилятор просто присвоит переменной -1 и больше никакого кода создавать не будет. Если же у тебя в обработчике таймера переменная инкрементируется, а в основной программе только читается, то обычно никаких проблем не возникает - нет для этого почвы. Компилятор не может сделать никаких предположений о содержимом переменной и будет вынужден ее прочитать.

[sonycman]

А ты не пробовал объявлять ее вообще без volatile?

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

Код

extern dword sys_tick;

Wait(dword mksec) {
dword new_value, old_value = sys_tick;
do{
new_value = sys_tick;
}while ((new_value - old_value) < mksec);
}

Без volatile цикл while просто повиснет, так как new_value просто не будет считываться - компилер, будучи уверенным, что она не изменяется (нет присваивания), выкинул операцию считывания из кода...

[_Pasha]

Код

do

{


ATOMIC_BLOCK(ATOMIC_RESTORESTATE) new_value = sys_tick;
}

while ((new_value - old_value) < mksec);

Пусть sys_tick volatile, проехали предыдущий вопрос. Если мы говорим конкретно об AVR, то дороговатая операция получается. Я бы для такого случая завел бы какой-нить байтовый кеш таймерок. Тогда не надо атомарного доступа.
Портируемость AVR->ARM стремится к нулю

[sonycman]

Пусть sys_tick volatile, проехали предыдущий вопрос. Если мы говорим конкретно об AVR, то дороговатая операция получается. Я бы для такого случая завел бы какой-нить байтовый кеш таймерок. Тогда не надо атомарного доступа.

Тогда страдает или разрешение таймера, или величина макс. выдержки.
На AVR приходилось делать на двух байтах.
На ARM вообще без проблем

[_Pasha]

Тогда страдает или разрешение таймера, или величина макс. выдержки.

Я применял это там, где тик был медленный = 1мс. В таких условиях в мониторе событий крутился опрос "быстрого" однобайтового таймера  и этот тик (в предельном случае-вместе с вызовом обработчика) генерился там же. Т.е. преследовались цели: разгрузить прерывание, минимизировать джиттер прерывания от таймера из-за частых запретов/разрешений, разделить быстрые и медленные процессы. Понятно, что на  ARM "мельчить" объектами меньше чем 32 бита не только не полезно, но и вредно. И никаких извратов там не надо.
И, следуя вполне нормальному желанию портировать код, завел тип timer_t - размерностью какой надо в конкретном случае. Извиняюсь если написал много банальщины.

В варианте для AVR считывать sys_tick в цикле и сравнивать с предыдущим значением.

По остальным тезисам - согласен, а тут - слишком искусственная ситуация, ибо такие циклы встречаются довольно редко. Согласитесь, чаще встречается  конструкция типа 

Код

void action (void)

{
static timer_t local_timer =0;
timer_t tmp;
tmp = get_tick();
if ((local_timer - tmp) < My_Time_To_DO) return;
local_timer = tmp;
Do_Be_Do_Be_Do();

**********

return;
}