не понятно почему так не сделана либа STM, и к чему тогда возникающие периодические споры про корявую либу СТМ или какие то хитрые дефайны с регистрами, если всего то надо разок потратить время и перебить функции на инлайн.

И некоторые из них просто станут неработоспособными... если не ошибаюсь... SPI, например...

Это вроде как логическое продолжение CMSIS. Потом, там MISRA2004 проехалась, потом - операции с битовыми полями априори неизвестно как себя ведут на разных компилерах, иначе все было бы попроще. Всему есть причины.

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

--
Как альтернатива - Coocox"овые либы... Но там другая сторона медали: в STшных - инициализация через структуру, зато функции с 2-мя параметрами и повторное использование, в кокосовых - функции с большим числом параметров. Хрен редьки, как говорится.


Ухты! Где?

Точно уже не припомню...
Зато точно помню... что желание инлайнить весь этот колхоз, почему-то, не возникает...

ну да стандарты, есть стандарты. Но для себя решил, надо выделить время и по той периферии которая используется заинлайних их функции. Что удобно, что там объявлены большинство регистров, иногда даташит даже открывать не приходится, просто надо как и всё под себя с оптимизировать минимальными ресурсами. Даже имена им менять не нужно.

Вот только есть одна неприятность. Учитывая, как у ST оъявлены биты, использовать bitband не получится. Остается уповать на компилер, но тот же IAR не торопится задействовать bitband регион.

Смотрю я на этот битбанд и что-то выигрыш не особо просматривается... кроме атомарности.

Сообщение отредактировал _Pasha - Feb 8 2013, 18:30

А прочего от него особо и не требуется.

Ну и, как обычно, смотреть надо на проблему в целом, а не на стоимость отдельных частей. Использование bitband позволит избавиться от ENTER_CRITICAL()/EXIT_CRITICAL(). Ну и как теперь, выигрыш "просмотрелся"(с) ?

А, вроде, в новеньких F3 вход-вывод не попадает в bit-band?...

Bitband, это фича ядра, не контроллера. Производители ядра говорят что такая фича есть, хоть и опционально. ST тоже говорит, что есть. См. STM32F3xxx and STM32F4xxx Cortex-M4 programming manual, "2.2.5 Bit-banding".

Про фичу ядра согласен. Но в приведенном Вами документе для периферии выделяется Peripheral bit-band region 0x40000000-0x400FFFFF (см. стр. 31). Легко убедится (см. RM для stm32f3xx), что GPIOx туда не попадает, т.к. начинается с 0x48000000. ((
Сам с данной неприятностью столкнулся при использовании "универсальных дефайнов для работы с GPIO"...

А смысл работы GPIO в означенном регионе? Если и так чтобы установить/сбросить атомарно - все есть.
А конфигурацию пинов зачем атомарно менять? Я даже такой ситуёвины представить не могу

Б-г с ней, с атомарностью. "Ситуевину представить"(с) - "легко, смеясь"(с) : как я налетел с ремапом. А именно:


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

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

Написал библиотеку для работы с UART.
При инициализации передаем адрес бита ножки GPIO, отвечающую за передачу в RS-485.
Как быть теперь? Применить свою виртуальную адресацию битов портов?
По библиотеке для этих целей могу "протащить" лишь одну 32-битную переменную.