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

Как соорудить костыли, это я и сам догадаюсь. Но что тогда делать с драйвером периферии, причем таких драйверов может висеть на одном SPI несколько штук. В каждый из них прописывать этот костыль? Или все-таки использовать bit-band, дабы вообще не трогать SWJ_CFG[2:0]?

А как вы думаете... как боролись с RMW в младших ПИКах, в которых не было регистра LAT ??? Создавали "фантомный" регистр... типа:

И это не считалось проблемой... считалось - решением...


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

ИМХО... Вся сложность STM32 - в его простоте... при широких возможностях...

С каких пор, вырезание гландов через анус, называется "решением"? И что тогда называть "костылём", если создание фантомного регистра - "решение". Реальное решение, это использовать bit-band. Вот это - действительно решение. А наплодить тонну фантомных регистров, создать прослойку для работы с ними и радоваться, что хоть как-то разрулили аппаратный недостаток... Философия Microchip/Microsoft в действии?


Ну вот, опять общие слова - "вы не поняли", "вы не дочитали". Ну а конкретно-то можно? Что именно я "недочитал" и "не понял", касательно работы с AFIO_MAPR_SWJ_CFG? Может наоборот, это вы оба недочитали, раз не используете bit-band, а заводите какую-то левую переменную в памяти? Да чего уж скромничать, продублируем все регистры ядра и периферии в памяти. Вот будет веселье.

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

Вот... лучше не надо... веселья... поверьте...

Есть много разных способов избавиться от головной боли. Гильотина - не лучший. Хотя некоторые сочтут его вполне годным.

В данном случае, никто не ноет. Есть вариант с bit-band. Это - решение. Все остальное - не решения, а какая-то отрыжка из конца 90-х, с их кривыми PIC-ами.

"Проблемы индейцев - вождя не колышат!"(С)...

"Решение"... или... "праздничный костыль"???

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

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

Понятно. Т.е. нормального решения предложено не будет.

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

Изначально - нужен bit-band или "можно и без него обойтись, не очень-то и хотелось".


Ключевое слово здесь "я". Это частный случай. Но начиная с какого-то размера, трудоемкость raw кодирования сильно увеличивается. Избежать этого поможет разбиение на блоки. Но появляется ограничение - блоки должны работать корреткно, в т.ч. независимо от того, в какой последовательности их вызывают. В моем случае, есть несколько разных модулей верхнего уровня, каджый из которых может вызвать инициализацию в произвольный момент, а не только в начале программы. Больше того, модули верхнего уровня могут быть написаны сторонними людьми, поэтому достоверно определить, когда вызывается инициализация - затруднительно. Совсем не факт, что она вызывается только один раз в самом начале.


Вообще-то, проблему я выше изложил. Позже даже разжевал, причем подробно. Но раз нет - значит нет. На том и порешим.
P.S.
"Пушкин, он как гамлЕт. Все отрицал." (с) Шура Каретный

Хорошо...
Почему проблема возникла только у вас... судя по отсутствию "горячего" обсуждения... проблема "чисто ваша"...
Иначе... было-бы и обсуждение и методы решения...
Думать, что ремапом пользуетесь только вы.... наивно, по крайней мере...
Отсюда: Проблемы нет... и она никому не интересна, ввиду её полного отсутствия...

Дальше...
Регистр прочитать нельзя... но писать то можно??? Трудности с установкой/ очисткой битов??? Не знаете что такое маска???
Очистили нужные биты, потом установили... в хэдэр хоть заглядывали??? Так в чём проблемы???
А бит-бэндинг/ не бит-бэндинг это уже частности... а не панацея...

Возвращаясь в тему.
ИМХО для АРМов использовать "дефайны" и "инлайн функции" в заголовочниках сейчас не имеет никакого практического смысла. Современные компиляторы (свежие GCC с опцией -flto) прекрасно анализируют код и при необходимости сами "заинлайнят" нужные функции. А если указана опция оптимизировать по размеру, то наоборот не будут "разворачивать" код.
Отказ от "дефайнов" приводит к более красивому коду и к простоте отладки. Дефайны не осуществляют проверку типов и т.п.

C vs C++ ???

Это-то тут причём? Ради флуда?

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

так как общее правило для него считать значение, изменить нужные маскированные биты, и записать значение обратно. В этом случае если нет возможности достоверного считывания значения то и нет возможности записать его достоверно обратно.
к примеру бит который читается всегда как 0, но может быть выставлен в единицу, после считывания и записывания обратно гарантировано занулиться...

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

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

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

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

резюме: без бит-банда можно обойтись, иначе не было прошлых процов без него, он также удобен - иначе бы его не делали. То есть это инструмент который делает нашу жизнь лучше и не надо его отрицать, ровно как и положить за него жизнь... ИМХО

Ещё раз... читать нельзя... но есть Reset value... есть от чего отталкиваться...
А дальше... или я по маске набью переменную и целиком затолкаю в регистр... или положу в регистр заранее подготовленное значение... или буду дёргать бит-бэндом... всё от задачи...
А сама проблема ремапа... где???

Индусский подход? Именно так в либах от ST и сделано ( о чудо, оказывается я заглядываю в "хидеры" и "либы" ). К чему это приводит, я уже объяснял. По второму разу жевать одно и тоже - никакого желания.


Круто. Расписать несколько вариантов "костылей", а потом самому же скромно спросить - а где, собственно, проблема? Я оценил.


Все верно. И таким образом, тема плавно перетекает в грамотно продуманный API.

Если подумать... то вариант с бит-бэндом, при частом ремапе, самый бестолковый "костыль"...
Но это ваша "проблема"...