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

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

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

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

Что скажете?

ISR сделай в отдельном файле и используй как
dword timer;

а в основном объяви как
extern volatile dword timer;

Сообщение отредактировал kimstik - Jan 24 2009, 16:54

Спасибо!
Работает

А я почему-то подумал, что extern должен быть с точно таким-же типом, что и оригинальная переменная...

Заведите внутри обработчика прерывания локальную переменную, считайте в нее timer и работайте дальше с ней. В конце, если надо, сохраните локальную переменную обратно в timer. Зачем какие-то велосипеды с выносом в другой файл?

А я вот чего-то совсем не припоминаю из стандарта почему исходный вариант неправильный ?
ИМХО, вполне себе подходит с union.

Хорошо.

Он не неправильный. Он несколько... некрасивый. Как вы организуете доступ к этому безымянному unionу из другого файла? Вы вынесете его в заголовочный файл с extern, и при этом сделаете видимым не-volatile пременную. Никакой гарантии, что случайно не используете эту переменную вне прерывания. Если есть возможность железно ограничить область видимости не-volatile переменной обработчиком прерывания, сделав ее локальной - почему не использовать ее?

Думаю, что он может накладывать дополнительные ограничения (volatile, const) на переменную, но не снимать их. Искать в стандарте лень, никогда не использовал такой финт.

Этот счётчик необходим для класса таймеров рассредоточенных по всему проекту.
Поэтому его вынос обязателен.

Последовал совету kimstik.
Накладывание доп. ограничений (volatile) на внешнюю переменную для внутренних нужд - это прикольно
Можно ещё и const добавить для подстраховки...

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

А сам бы я тоже локальную просто завел... чисто по привычке.

Компилер заставил поставить static. А имя - зачем оно? Лишняя писанина только...
Объединение не должно быть в области видимости снаружи. Оно только для нужд прерывания.
А снаружи - только volatile dword...

Да ладно, это не актуально более

Ну вообще говоря "желательно".
Прокатить такое может только если в файл с обработчиком ISR не включать тот h-файл, в котором объявлено переменную для остальных - я же предпочитаю объявлеия включать везде для проверки (если вдруг поменяю в .h uint16_t на uint32_t, а в .c забуду - компилятор выругатся.
Но тогда
vv.h

vv.c

Компиляция:


Я как правило кеширую переменную в обработчике прерывания во веменную и сохраняю при выходе.

Можно и так, набросал вот

Хм, спасибо!
Если будут проблемы с extern, то придётся именно так и поступать.
Эх, пора мне, наверное, шаблоны поизучать - а то аж искры из глаз, пока силился понять, что там вы с ними "замутили"
Можно, конечно, и без них обойтись...

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

Согласен со всем.

Позволю себе усомниться, разве что, что не все компиляторы понимают безымянное объединение.
И какие, например, компиляторы С++ не соответствуют стандарту?

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