STM32F7XX аналог bit-banding Опции

[amiller]

В последние годы пришлось достаточно много писать для STM32F1XX и STM32F4XX.
Везде активно пользовался механизмом bit-banding для доступа к битовым переменным.
Сейчас заказал отладку с STM32F746ZG.
Читаю документацию и вижу, что там никаких упоминаний про bit-banding при работе с оперативной памятью...
Ткните носом, что на замену? Может появились неделимые операции "чтение-модификация-запись"?

[AVI-crak]

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

Атомарные операции не терялись. Вот только выглядят они как громадный костыль.

Применимы к флагам которых безумно много, или как вариант - обязаны занимать минимальное место (не всегда правило).
В общем у меня получатся так: глобальная структура с флагами ( ingl ) - цель, собрать в кучу мелкие имена флагов, строго 32б, ну и модификация с помощью стандартных команд __LDREXW и __STREXW.
Поместил функции f_ask_с и f_ask_d в разные задачи, они там в цикле просто меняют свой флаг. Смысла в функции нет, потому как я не придумал способ передать указатель члена структуры (оно ниже физического адреса). Возможно можно перечислениями сделать, но как потом не запутаться - не знаю.

Словом, если кто предложит решение - буду рад.

CODE

typedef union
{
struct
{
uint32_t stop:5;
uint32_t start:1;
uint32_t a:1;
uint32_t b:1;
uint32_t c:1;
uint32_t d:2;
uint32_t e:1;
uint32_t f:1;
uint32_t g:1;
uint32_t h:1;
uint32_t i:1;
uint32_t j:1;
uint32_t k:1;
uint32_t l:1;
uint32_t m:1;
uint32_t n:1;
uint32_t o:1;
uint32_t p:1;
uint32_t q:1;
uint32_t r:1;
uint32_t s:1;
uint32_t t:1;
uint32_t u:1;
uint32_t v:1;
uint32_t w:1;
uint32_t x:1;
uint32_t y:1;
uint32_t z:1;
} Flags;
uint32_t Flagi;
} Flag_Type;

Flag_Type ingl;


static void f_ask_c (void);
void f_ask_c (void)
{
Flag_Type tmp;
do
{
tmp.Flagi = __LDREXW(&ingl.Flagi);
tmp.Flags.c ^= 1;
}while ( __STREXW(tmp.Flagi, &ingl.Flagi));
__CLREX();
}

static void f_ask_d (void);
void f_ask_d (void)
{
Flag_Type tmp;
do
{
tmp.Flagi = __LDREXW(&ingl.Flagi);
tmp.Flags.d ^= 1;
}while ( __STREXW(tmp.Flagi, &ingl.Flagi));
__CLREX();
}

Сообщение отредактировал AVI-crak - Dec 28 2016, 02:19

[jcxz]

Словом, если кто предложит решение - буду рад.

А зачем Вы у себя использовали CLREX?

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

Как предположение: возможно бит-бандинг убрали из-за того, что он не работает в многопроцессорных системах?
По крайней мере про механизм LDREX/STREX в мануале заявлено, что он нормально работает и в многопроцессорных системах.
А я думаю, что цель развития МК в дальнейшем - по несколько ядер в одном чипе. Некоторые вендоры это уже осознали.
Так что может и не зря сейчас переходите. Потом когда выйдет новый МК с несколькими ядрами, окажется что Ваш код с бит-бандингом весь надо переписывать, а если напишете на LDREX/STREX - он и там окажется рабочим

[AVI-crak]

А зачем Вы у себя использовали CLREX?

Там написано что это снятие блокировки, но мне кажется это корявый перевод гугла.
В реальности это очистка регистра адреса, который используется для мониторинга атомарного адреса. Прикол в том что когда __LDREXW и __STREXW применяется в прерывании, и перебивается другим прерыванием ровно между командами - при возврате получается глюк.
Поймал пару раз, теперь просто ставлю CLREX.
В майне любое прерывание работает как CLREX, команда короткая и простая, к тому-же с явным указанием перезагрузки операторов "memory". Этот барьер запрещает GCC размазывать функцию по всему коду, как он это любит делать.

----------------
Есть мысли? как в функцию передать адрес члена битовой структуры???
Гугол молчит на эту тему, наверное это особо_извращённая методика программирования, возможная исключительно под грибами (запрещёнными Законодательством Российской Федерации). Грибы есть, мыслей нет.

[KnightIgor]

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

Я тоже много думал и пытался найти подробнее, как работает LDREX/STREX пара, предполагая, что там какие-то адреса мониторятся. Все гораздо... тупее. Никаких адресов. Если между LDREX и STREX произошло хоть какое прерывание, считается, что оно МОГЛО что-то изменить в атомарной переменной, даже если обработчики ни сном, ни духом и нигде пальчиками не лазили, и операция экслюзивности отвергается. Так, на всякий случай. Я не подпишусь, как там с DMA, который может влезть на атомарную переменную. Не нашел упоминания по поводу (может, плохо искал), но по логике предполагаю, что если между LDREX и STREX хоть какое-то телодвижение со стороны DMA было, эффект будет аналогичный прерыванию. В этой связи есть у меня подозрение, что LDREX/STREX внутри прерывания может действительно приводить к странным эффектам.

P.S. Касаемо bit-banding, а точнее - его нужности, то дискуссия в ее нынешнем состоянии есть просто излишня. Здесь нужно принимать явление феноменологически: коль ARM такое замутил, то в этом был и есть глубинный смысл и польза. Не нравится - не ешь.

Сообщение отредактировал KnightIgor - Jan 9 2017, 13:30

[zltigo]

В этой связи есть у меня подозрение, что LDREX/STREX внутри прерывания может действительно приводить к странным эффектам.

И каким образом лишний сброс флага эксклюзивности развеивает Ваши подозрения?

[KnightIgor]

И каким образом лишний сброс флага эксклюзивности развеивает Ваши подозрения?

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

А что там думать? Всё же написано:

Очень хорошо написано. Кратко. А кто спорит? Но мне в свое время недоставало в документации некой преамбулы, фразы о концепции, идее LDREX|STREX с точки зрения всей системы в процессоре. Вроде "если ход исполнения между LDREX и STREX будет прерыван, будем рассматривать такое ответвление как риск потерять целостность операции, потому, независимо от того, действительно ли изменилась атомарная переменная в результате прерывания или осталась нетронутой, атомарная операция отклоняется". Вроде того.

Кстати, ни слова про DMA, как я на сей момент и предполагал. То есть, надо чисто организационными методами предотвратить какие-либо доступы со стороны DMA в память семафоров. Иначе - защиты от дурака нет.

Сообщение отредактировал KnightIgor - Jan 9 2017, 14:48