Еще раз. Вы методично пытаетесь вешать лапшу на уши, привязавшись к нестрогому термину "указатель volatile", который ОЧЕВИДНО не имеет смысла как volatile-указатель. Пропущенный предлог "на" так же очевидно следует из контекста и по сути ошибкой не является. Просто потому, что рассматривать отдельно, как особый случай, volatile-указатели нет никакого смысла. Они ничем не отличаются от volatile-переменных в смысле их использования.
Однако дело тут совершенно в другом. И это лично мне так же очевидно. Ведь Тимофеев как раз ПОДТВЕРЖДАЕТ изначальную постановку вопроса. ВАШЕГО, милейший, вопроса. И к тому же, Мурик ранее привел ссылку на pdf той же статьи Тимофеева и ЛИЧНО ВЫ эту ссылку привели как поучительную...
А дело тут в "Маньке" и ее "буферАх"... Ну если не считать воспаленное "самизнаетечто" у Вас, любезный....
За сим и закончим беспредметное пикирование. Лично я все давно понял.

Желаю это видеть. Попробуйте унять компилятор здесь приведением типов. Буду следить за этим с нескрываемым интересом.


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

Хотеть не вредно. Пример я приводил. Да и не припомню я чтобы когда-то что-то вам задолжал. Успехов в войне с ветряными мельницами. Чао.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Лажу вы приводили. Фиг с ним, что оно не портабельно и не собирается шлангом. Я исправил. Но проблема ровно на том же месте, где и была. Вы не понимали этого и не понимаете сейчас.



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


Да мне-то все равно. Гоните лажу, важно вытягивайте шею. Вы в своем праве.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Clang выступил в роли капитана очевидность. Я и без него знаю, что внутри функции не будет volatile, он там и не нужен. Нет никакой проблемы. Код компилируется и работает как задумано. А то что вы не знаете что такое uint32_t(adr)... Да чего удивляться то после всего вышенаписанного.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Вот так он компилируется:



Если было задумано, чтобы варнинги были на каждой строчке, то цель, безусловно, достигнута. Поздравьте себя.



Вы возомнили себя единственным знатоком заплесневелого легаси? Офигеть!

А говорил не собирается... Наврал? Ты ещё MISRA запусти. Своей головой думать надо!

В си и не должно собираться. Таковы видать у вас представления о доступном изложении -- намотать бреда и побольше.


Главное, чтобы не вашей.

А с чего вы взяли, что это должно Си собираться? В С++ более строгий контроль типов, если что. Я в своих прошивка ещё вот такой код-барьер от желающих Си собирать вставляю.

Лишний код в прошивке.

А по поводу доказывания необходимости volatile, вот что вспомнилось.

Спойлер

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

Выкиньте компилятор, который на это выражение код генерит

Вас забыл спросить.

Какой бы "барьер" для любителей компилить сишный код посредством не gcc. а g++ придумать?

Что предлагаете взамен gcc-arm-none-eabi-9-2020-q2?
Думаете компилятор кейла лучше будет?

Лично мне кейловский 6.14 показался чуть повеселее.

Тогда научитесь им пользоваться. А скорее всего, правильно читать листинги. Вот добавление этого выражения не добавило ни одного байта к прошивке.
Прыгать с компилятора на компилятор сейчас особого смысла нет. Лучше хорошо уметь пользоваться каким-то одним и дружить с остальными.

Прыгать может и нет, а проверить, как проект собирается разными компиляторами, полезно.

Кстати, насчёт разных компиляторов...

Прикупил такую плату с камерой и дисплеев для экспериментов. Товарищи китайцы даже на github для неё разные Examples держат.

Что плохо - проекты делались под Keil uVision. Попытался их проект для "куба" в вариант под GCC/Makefile переделать, пробросил недостающие DEFINEs (из xml-ки проекта uVision), пути к includes/sources. Проект компилируется. Но:
- с GCC версий 8 или выше - дисплей не инициализируется, шум на нём. Беру GCC 7 или младше - работает (пример 03-LCD_Test)
- с GCC любой версии пока не удалось запустить камеру (пример 08-DCMI2LCD). Сильно не копал, но видно, что вроде как коллбэки от камеры не приходят, код висит в ожидании флага о наличии нового фрейма.

Если прошивать их hex-ы с github (сделанные в uVision), проекты работают.

В общем, совместимость там та ещё...

А с какими параметрами оптимизации проект собирался под "GCC 8 или выше" ?

-Og во всех случаях. Пытался отключать вообще, но эффекта не было.

Ещё пытался сделать следующего "Франкенштейна":
- Собрал 7-м gcc работающую прошивку, сохранил из сборки сгенерённый объектник lcd.o, почистил проект
- Собрал 8-м gcc неработающую прошивку.
- Заменил объектник lcd.o сохранённым, перелинковал

В таком сочетании заработало. То есть, проблема либо в коде lcd.c, либо в возможно встраивающихся в него функциях из других файлов (хотя lto не включен, так что вряд ли).

P.S. Если интересно покопать, положил свои эксперименты сюда. Там в архиве есть каталоги с продуктами сборки от обеих версий gcc, логи сборки из консоли. Возможно, что-то полезное дало бы сличение файлов lcd.lst в обоих случаях, но "я уже в пижаме"...