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

Если под "умным" опустошением предполагается их, при их априори полной бесполезности тем не менее складывать куда-то дабы "когда свалимся в 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-а в том, что компилятор не учитывает волатил из структуры, но будет учитывать при непосредственном объявлении в переменной. Проверить-то легко.

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



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