Если это так, то это ошибка того, кто эти h-файлы писал.


Ну если так...
А проверьте то же самое с явно заданной а не с SPSR.
Может где-то отвалилась volatile-ность __io_memory

Интересно. А если принудительно объявить его как volatile? Или провести эксперимент с обычной volatile переменной, как советует уважаемый ReAl?

Такой глюк был в версии IAR3.20C, регистры I/O оптимизатор глазом не моргнув кэшировал. Но потом в начиная с 3.20D вроде его исправили.
Попробую просто с обычной переменной.

То же самое

Рискну повторить вопрос aaarrr из поста №38 - у вас точно не включен режим C++?

Да нет, тут дело, похоже, в том, что переменная локальная.

Конечно, Сергей, прав
В режиме С все читается нормально, был С++.

возможно, степень выдачи ворнингов - параноидальная? как мне кажется, это настраивается... WinAVR не выдает ничего с опцией -Wall


off: подозреваю, что все одиозные уязвимости и проблемы Windows вытекают из "виртуозности" кодировщиков, с которой компилятор не справляется


а что плохого в том, чтобы быть понятым всеми? или аура "продвинутости" тает при этом? мое мнение: применение "вывертов", которые допускает синтаксис Си, используется исключительно для того, чтобы выделить себя (личность) из ряда прочих (серостей). чем проще изложен алгоритм - тем меньше шансов, что будет допущена логическая ошибка в нем, заодно меньше неоднозначностей при переносе между разными компиляторами. витиеватость кода никак не отражается на оптимальности генерируемых ассемблерных конструкций (если, конечно, эта витиеватость правильно понята компилятором), и разница между i++ и i = i + 1 не видна абсолютно. и если этот пример оправдан хотя бы экономией 2-х (!!!) символов, то применение более "накрученных" штучек мало того что затрудняет восприятие кода другими, но еще может оказаться неверно понятым компилятором... так ради чего сыр-бор?! какова конечная цель: получить всегда гарантированно однозначно воспринимаемый человеком и дающий всегда верный результат код или создать некое произведение искусства, понять которое без опытнейших искуствоведов никто не в силах, и которое транслируется одинаково далеко не во всех случаях?

Степень нормальная и ворнинг вполне уместный.


Да, очень легко хаять программистов Майкрософт. А проблемы-то как раз и начинаются с подавления сообщений компилятора.


Цель - не получить сотню-другую "левых" ворнингов при сборке проекта, среди которых так легко теряются "нужные".

-Wall -Wextra, без --pedantic, хотя иногда стоит и его включать.

Ну вот, то про маты что-то, то про ауру и выделение личности из серостей... "у кого что болит, тот о том и говорит"?

Написать присваивание какой-то переменной там, где оно не нужно и для переменной, которая больше нигде не используется, или if(UDR); там, где не нужно ничего проверять и рисовать для этого пустое тело if - это не "выверт", это "простое изложение алгоритма"?
Как на мой взгляд, так это как раз выверт для того, чтобы компилятор допёр до того, что надо всё же прочесть.
Приблизительно как FUNC(VAR + 0) в фортране - тоже был некий выверт для обхода неких особенностей.
Но дело в том, что если он не читает просто volatile_var; , то кто гарантирует, что при следующем витке развития он будет продолжать читать if(volatile_var); или temp = volatile_var; ?
Уповать на конкретную особенность конкретного оптимизатора конкретного компилятора - это "тем меньше шансов, что будет ошибка" ?
Да тут не между разными компиляторами, а между разными версиями одного компилятора или даже между разными ключами одной версии может переносимости не быть!

Все "выражения" (expression) должны быть абстрактной машиной "вычислены" или "оценены" (evaluate)
Так вот первые два выражения в примере выше тоже должны быть "evaluated", как и третье.
И если в третьем переменная temp в этом файле нигде больше не используется и не глобальная (глобальность тоже может не помочь, кстати) и var не volatile, то компилятор имеет полное право выбросить его полностью - это не нарушит "observable behavior".
Повторюсь - когда-то давно не выбрасывал и во многих программах работы с аппаратурой вместо описания регистров ка volatile просто делали такое присваивание для принудительного чтения, и тянется жто до сих пор. Но это довольно быстро перестало помогать, как кстати и jmp на следующий адрес для задержки при обращении к медленным портам на PC.
А если var квалифицирована как volatile, то компилятор обязан зачитать её и в первом случае.
Во втором может иметь добрую волю выдать предупреждение, что результат вычисления var+1; нигде не используется, так же как и в третьем имеет право поворчать, что результат присвоения temp нигде не используется и выбросить запись в temp (но при этом обязан прочесть из var).

Поэтому я и говорю, что выверты с присвоением специально для этого заведёной переменной или if с пустым телом можно рассматривать только как обход ненормальности конкретного компилятора (либо, см. выше, докажите мне это со ссылкой на стандарт и я поменяю мнение), а не как хорошую практику программирования.

p.s. По крайней мере в случае С.
Надо разобраться, что там с С++ - мне казалось, что базоыве вещи должны были остаться и там, иначе нет той совместимости, которая декларировалась.

гм... я и не говорил, что пустой if - это норма... я как раз придерживаюсь противоположного мнения... а вот присваивание временной переменной с моей точки зрения - вполне нормальная практика, логичная и не нарушающая никакие стандартны-нормы-правила. volatile тут совсем ни при чем - этот модификатор никто не отменял и его значение (и назначение) не оспаривается.

на счет "специально заведенных переменных"... на сколько я понимаю, при определенном напряжении сил можно очень сложные выражения (например, нечто типа БПФ) уместить в единственном операторе, избежав "лишних" переменных (обычно они называются локальными)... и, хотя с точки зрения результата это будет совершенно верное "выражение", назвать его удобочитаемым будет можно вряд ли. скорее всего и по объему результирующего кода результат не будет отличаться от "развернутого" варианта...

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

можно сколько угодно рассуждать о том, что компилятор "должен сделать", если встретит просто упоминание переменной, но ведь если записать чуть иначе - пропадет сам предмет спора, ибо поведение компилятора станет очевидно на 100%.

Если Вам приятно в таком духе - продолжайте, утрируйте, доходите до нелепиц и спорьте с ними - но без меня.
Я вижу разницу между промежуточными переменными для разбивки сложных выражений на более простые и лишними переменными, в которые пишется для того, чтобы никогда из них не читать и этой записью ничего в окружении программы не менять (так как сама эта лишняя переменная - и не SFR и никогда никем не читается).
Если бы эта запись была необходимым или достаточным условием для чтения из переменной в правой части независимо от её volatile-ности, то в этом был бы смысл.
На мой взгляд в такой записи смысла приблизительно столько же, сколько в комментарии
(хотя для малознакомого с С новичка этот комментарий и повышает читаемость), так как она всего лишь косвенно, через запсиь в другую переменную, говорит "а мы эту переменную прочитали!" для того, кто этого сам не видит. Всего лишь.

Обсуждение напоминает обсуждение кода типа

"Индийский код..."
Чем не устраивает вариант с просмотром дизассемблерного варианта полученного кода? Все сразу встанет на свои места - что лучше, а что хуже..

хочу для универсализма сделать версию функции printf() для вывода строки на 7-сегментный индикатор, при этом реализация получается примерно такая:

трабла такая: как передать "хвост" аргументов, полученных на входе в printf_7led непосредственно в вызываемый sprintf?
P.S. Работаю с WinAVR (GCC)

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

большое спасибо! я вокруг чего-то похожего бродил, но до верного решения так и не дотумкал.
а на счет вывода в поток "дисплея" - мне кажется, это хоть и красивый метод, но для 6-символьного 7-сегментного дисплея наверное слишком избыточный... просто строчку вывел - сразу понятно, что предыдущая затерлась... а при посимвольном выводе надо как-то так же красиво и логично отслеживать момент, когда строка кончилась... не находите?

Ну избыточный он не этим - на шести символах просто толком негде разгуляться форматными строками с ширинами полей и т.п.
А что касается "отслеживать момент" - да на раз, було бы желание покуражиться.
Можно заставить по '\n' очищать строку - причём:
- либо сразу по нему, тогда выводить строки вида
"\nHELLO", что будет приводить к очистке и выводу, последующий вывод допишет в конец
- либо по нему запоминать, что строка была завершена и уже последующий вывод очистит и начнёт с начала строки, тогда выводить (&Display, "Err %02X\n", err_code);

Во втором случае в putchar_7led заводится статический флаг, который запоминает прохождение '\n'

как раз желания куражиться и не было.
я поступил по первому совету - сделал оберточные функции для sprintf с преобразованием нормальных символов в семисегментные и весьма доволен результатом. на верхнем уровне и для семисегментника пишу printf_7led("%.2u", var) - и все выводится а когда надо, то и так работает printf_7led("stop"). жаль, не все буквы в семисегментные варианты преобразуются особенно кириллица - слишкам многа букафф

http://electronix.ru/forum/index.php?showtopic=56439&hl=

ну да, это и имел ввиду - vsprintf конечно

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

Во-первых избегать появления дурного кода - т.е. сводить в минимуму потребность в таких вот "var;" и лишних переменных. С какого бодуна драйвер решил вдруг опустошить содержимое буферов? Ведь можно построить драйвер так, что тупое опустошение не понадобится вовсе! Или почему SPSR надо обязательно читать в никуда?
Можно же хотя бы в целях статистики хранить последнее значение SPSR:

производительности-то оно не сожрет.

во-вторых - применять практику самодокументируемого кода - завести однозначно понятные макросы:


Встретив в коде

Даже те "кто в танке" сразу поймут, что делается с SPSR.
А столкнувшись с "финтом" компилятора - достаточно поменять только тело макроса...

Научите у LPC2000 за тем-же SPI есть FIFO которое
- не отключается
- нет возможности сбросить его
Как сделать запись по SPI так, что-бы когда-нибудь при чтении можно было прочтать SPI, а не содержимое забитого при записи FIFO.

Потому, что там содержится "ничто" которое отлично отправляется в "никуда".
Я бы не отказался и от обратной возможности - записи "ничего", а то бывает приходится писать, например,

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


Да? Вместо, например, команды чтения в первый попавшийся расходный регистр будет производится считывание (для load/store через тот-же промежуточный регистр) в структуру находяшуюся в памяти.....

Угу, приходишь в магазин, а там на бутылке с маслом надпись
масло(масло);
Начинаешь думать, а чего это вдруг так написали - может смысл какой есть? Смотришь header спрашиваешь и тебе объясняют,что это масло для танкистов.... . В общем-то конечно можно макрос написать, но лишняя сущность.

А почему не так:
Чтобы избежать лишнего обращения к константе? По-идее будет взята из генератора констант...

Полноразмерная Константа будет взята из памяти, или сгенерирована в регистре, но все это уже громоздко по сравнению с минималистичной записью первого попавшегося регистра c произвольным значением. По этой причине и указываю имя некой "недалеко" находящейся переменной.

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


Можно дать константу (опять же если производительности хватает).
VICVectAddr = 0;
или
VICVectAddr = CurrentVector;
будет чуть-чуть дольше, зато интуитивно понятно, что делается.


Да, тут сознательно добавляем запись в память. Медленнее чем в регистр - да, сильно скажется на производительности всей системы - нет! (всего лишь запись одной ячейки на FIFO циклов SPI). Польза от этой записи - когда свалимся в DABT, можно будет снять дамп и посмотреть состояние железа, в т.ч. и значение SPSR (вдруг именно его значение поможет найти причину аборта).

Я говорю не отказаться, а свести к минимуму потребность в пустых чтениях, пустых переменных, и прочем дурном коде, и чтобы не быть пустословным показываю как можно этого добиться. А выбор делать так или нет - как всегда за разработчиком.



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


Дело привычки. Например как Вы поступите если есть некий шаблон колбека:



и куча функций подпадающих под этот шаблон, но не использующих все параметры?

Мне удобно поступать так:

Вопрос ведь в том, КУДА ОН ИХ БУДЕТ ДЕВАТЬ после ВЫТАСКИВАНИЯ? Выбрасывать? Вы обещали научить меня писать драйвера

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

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



Будете смеяться, но мне - удобно АБСОЛЮТНО аналогично .

Только это совсем разные случаи, ибо в описываемый ранее
SPSR;
Абсолютно самодостаточен и не совершенно не нуждается, в отличии от priority, ни в каких мусорных обертках ignore( SPSR ); Если хотите сделать понятным для "танкистов", то напишите комментарий - "танкист" чуть-чуть выглянет из люка и узнает немного нового

Складывать в кольцевой буфер, и "семафорить - данные есть". Если эти данные хоть кому-то нужны, обрабатывающий процесс их заберет, если не нужны драйвер перетрет их нафиг по кольцу. Но взятки - гладки, свою работу - принять, нативно опустошить, просигналить - драйвер сделал.


Это перебор. Я такого не обещал, к тому же Вы и так умеете их писать.
А порассуждать как можно написать драйвер, чтобы избежать пустых чтений - это пожалуйста.


Под "умным" опустошением понимаем - монотонную работу драйвера. Не ему решать что полезно, а что бесполезно. Принимать без разбора драйвер должен абсолютно все, что физически приходит, и отдавать upper layer'у на рассмотрение.


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

if (a || b && c)
или
if (a || (b && c) )
вроде одно и то же, но второе ведь наглядней.


Смеяться не буду, - хорошо, что мы на одной волне в этом вопросе


Я бы не был так категоричен. Потому что SPSR - это не переменная, а макрос. Что там за ним спрятано - хз. Скажете, а UM на что, а если его нет под рукой у читателя кода?


шутку понял

Но все же
argused()
ignore()
accessed()
и т.п. делают код прозрачнее, и гибче при переносе.

Это далеко не одно и то же. Логические операции И и ИЛИ всегда выполняются слева направо. Даже компилятор не имеет права изменить этот порядок. Эквивалентным будет if (( a || b ) && c) и со скобками действительно нагляднее.

А приоритеты операций?

Все-таки
if (a || b && c)
или
if (a || (b && c) )
это одно и то же.
Если есть время, просимулируйте вот этот тестик:

У меня результат этого теста - "1 || (0 && 0)". (RVDS 2.2 и 3.1).

Точно. Приоритеты подзабыл. Решил, что у них одинаковый приоритет. Посыпаю голову окурками.

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

как-то натолкнулся на высказывание "в Си скобки лишними не бывают" понравилось, следую этому правилу постоянно. голова болит меньше и проблем тоже меньше

Что-то не получается обойтись без временной переменной.
Вот код:

на что компилер (RV) ругается: i2c.cpp(71): warning: #174-D: expression has no effect

Тот же самый код разложенный по "полочкам":

Как убрать предупреждение компилятора, и обойтись без явной временной переменной?

Что-то я совсем не понял, что и как Вы собственно написали . А вообще так:

P.S.
И вместо мути в структуре ввиде 'reserved' используйте 32bit паковку.

Так эта муть - библиотека ST для STM32. Я из неё использую только определения регистров.
Ну её нафиг переделывать, и так пришлось править, чтобы хидеры из C++ компилировались...

Попробовал, как Вы подсказали:

но компилятор по-прежнему ругается: main.cpp(26): warning: #174-D: expression has no effect
и выкидывает из кода эту строку...

Так что, плюсовым компилируете!? Так тут уже по моему обсуждалось в начале топика - у плюсового свои странные понятия ....
А такое, тогда он просто молча выкинет?
(void)I2C2_1->SR2;

Впервые вижу волатильную структуру Может я ошибаюсь, но только переменная может иметь этот атрибут. Попробуйте объявить так:

Потом проверьте есть ли в листинге чтение этого регистра.

Я написал без временной переменной, но если она нужна или надо делать несколько чтений, то можно так:

С чего-бы это вдруг, тем более, что сами написали
volatile I2C_Type_Def * I2C2_1
А если хотели
I2C_Type_Def * volatile I2C2_1
так это совсем другое....

Не, не. Я правильно выразил свою мысль в коде
<<volatile I2C_Type_Def *>> говорит, что там, по адресу будет лежать волатильная структура/переменная. Переменная с адресом (I2C2_1) не должна/обязана быть волатильной. Разглядывая чужие хидеры, например из ИАРа, я ни разу не встречал волатил при объявлении структур, а вот при объявлении переменных - всегда. Поэтому и удивился. Если, теоретически, структуры могут иметь этот атрибут, то возможно проблема у sonycman-а в том, что компилятор не учитывает волатил из структуры, но будет учитывать при непосредственном объявлении в переменной. Проверить-то легко.

Проблема в том, что компилятор плюсовый.



Угу, только почему-то буквально строчкой выше Вы выражали сомнение в возможности описания таких структур . О чем речь я и завел.

В оригинальной библиотеке для STM32 квалификатор volatile стоит у каждого члена структуры:

По совету zltigo я попробовал с квалификатором перед всей структурой:

Но, к сожалению, разницы нет.
Такая прикольная конструкция:

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

В общем, буду знать, что C++ не допускает выражений, подобных
...
variable_name_only;
...

И не должно быть. Я просто по привычке в естественной форме без ненужных излишеств написал.

Конечно могут, как и любые другие типы данных. Применение модификатора volatile (также как и const) к структуре распространяет его на все члены структуры.

Точнее это бага плюсового компилятора. Я все-таки залез в стандарт С++, и вот что он пишет:

Хм, бага? В одной из последних версий RealView?
Неужели никто не использует подобные приёмы обращений к данным?
Тем более из плюсов?

Я пробовал такое в MS VS2008 для ARM. Данные читаются, предупреждений никаких.