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

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

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

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

Что скажете?

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

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

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

А я почему-то подумал, что 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. Длинные бестолковые имена. Куча не всегда понятных переменных.
А то что в хедер для проверки не вставить объявления - это цена вопроса.
Вы же сами просили решения(хака)? Значит вам за него и отвечать.

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

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

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

точно не помню но нарывался уже на непонимание анонимного union, и вроде как даже не в одном месте. И это был С без плюсов.
zltigo: вам виднее,и спорить не хочется. мне лично две длинные переменные вместо одной короткой - лишняя сущность (по оккаму).
Тем не менее хочется отметить что вы везунчик - у вас есть выбор как минимум из 3х подходов реализации задачи

Но разве безымянные объединения не являются фичей исключительно C++?

Не только.
Насколько я ничего не помню, в С безымянные структуры могут быть,
но они должны обязательно включаться в конечном итоге в именованные структуры или объединения.
типа:

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

И раз уж зашла речь о безымянных обединениях и структурах, вот такой пример:
Чему будут равны A,B,C в конце main ?

Для начала эта мусорная структура не должна откомпилироваться.

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

а что скажут компиляторы на вот такую структуру:
?
только попробуйте сначала реально скомпилить прежде чем говорить что не скомпилит.

1. Multiple declaration for 'b'
2. "b" has already been declared in the current scope
3. Duplicate name 'b' not allowed in struct or union
Что было видно и без попыток скомпилировать сие тремя компиляторами. Начиная с самого древнего и кривого BCC.

 

живодеры!!
вот увидете - перестанет компилятор вам компилить вообще после этого - пожалеете

вот это:

VisualStudio 2005 прожевывает не поперхнувшись...

Ну фиг с ней - у меня по любому такое написать не получится. Хотя иногда достаточно, на первый взгляд, запутанные union-ы пишу.



Комментариии, правда,удалены .

Это просто было в качестве примера что неименнованные структуры и объединения нужно очень осторожно применять, можно случайно нарваться...

Структурки у Вас веселые...

Зато потом, после достаточно вдумчивого и аккуратного описания, ее результатами пользоваться очень удобно и без лишних раздумий.

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

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

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

Шикарный совет. "Как, вы еще не получали граблями в этом месте? Вот вам! " Вообще-то это требуется всегда, когда переменная изменяется неизвестным компилятору образом, например в прерывании, другом потоке или аппаратно отражает состояние внешних по отношению к ядру устройств. Зато _вы_ можете сделать предположение за компилятор. . Может он. Чтобы не мог - существует volatile. Если в конкретном случае без volatile вдруг не сделал, то при малейшем изменении исходника или версии компилятора сможет сделать и вот вам граблями в лоб - получите. Даже если чтения разнесены в разные функции и файлы - все больше компиляторов поддерживают многофайловую компиляцию. Хотите приключений - делайте, но не советуйте этого другим. Это примерно как "лазил я однажды в телевизор и нифига меня током не ударило. Так что незачем при ремонте его отключать от сети".

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

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

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

Сделать для чтения переменной встраиваемую функцию-обертку, которая и будет портируемой. В варианте для AVR считывать sys_tick в цикле и сравнивать с предыдущим значением. Если старший(старшие) байты двух чтений совпали - возвращать результат. Для ARM и переменной размером меньше 32 бит - просто считывать и возвращать результат.

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

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


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

Да. Так вот

Спасибо, понял. 

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

Ну например, в прерывании таймера инкрементируется некая переменная, а в прерывании какого-нибудь передатчика ее значение куда-то передается. Что может знать компилятор о ее содержимом? И "малейшего" изменения исходников (а тем более версии компилятора) недостаточно для изменения ее поведения. Нужно "существенное" изменение, например, если мы попытаемся ввести какую-нибудь паузу, как написал ниже sonycman - но паузы и задержки это и есть то, для чего придуман volatile. Но с другой стороны, введение задержек в микропроцессорной системе таким способом - явный признак дурного стиля, это снижает производительность системы. Для задержек как раз и существуют таймеры.

Это был просто пример.
Естественно в реальной системе мёртво стопорить процессор при ожидании глупо.
Хотя иногда и необходимо, и такие функции существуют.

Но вернёмся к теме - вы всё же считаете, что volatile не обязателен для случая с инкрементом счётчика в ISR и чтения его в основной программе?

Знает. Почитайте что такое точки последовательности, побочные эффекты. Функция исполняется от начала и до конца. Одна. Компилятор ничего не знает ни о прерываниях, ни о многопоточности. Задача прерывания - обеспечить неизменность состояния среды исполнения (state of the execution environment). Все, что изменяет это состояние является побочными эффектами (side-effects). Одним из побочных эффектов является обращение к volatile-переменной. Прочтите стандарт, чтобы не писать глупости.

И компилятор имеет право встроить функцию. Так что "Транслируя каждую функцию по отдельности" бывает далеко не всегда.