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 размазывать функцию по всему коду, как он это любит делать.

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

[jcxz]

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

Странно.... Надо будет проверить на своём МК как нить.
Думал, что любого вложенного прерывания достаточно для очистки признака эксклюзивности.......

[zltigo]

Странно.... Надо будет проверить на своём МК как нить.
Думал, что любого вложенного прерывания достаточно для очистки признака эксклюзивности.......

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

[AVI-crak]

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

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

И не стоит забывать про call функции, которые в последнее время пихают куда попало, даже в обработчики прерываний. Посему, если есть возможность выстрелить себе в ногу - такой человек найдётся. Потом придётся искать глюк, который срабатывает синхронно с магнитными бурями на Марсе.
Обработка глобальных флагов в прерывании должна завершаться CLREX, всё по той-же причине.

[zltigo]

Вы серьёзно?

Да.

Просто это как купить билет на самолёт, и отправится в путь пешком.

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

Вложенные прерывания получаются автоматически, при назначении им разных приоритетов.

Большая, но ненужная мне радость. На самом деле контроллер прерываний МЛАДШИХ кортексов это именно костыль. У старших, как и у "старых" армов, контролеры прерываний без этих костылей. Причина проста - явно предполагалось перетаскивать под крыло младших кортексов программистов с восьмибитовиков с их де-факто стилем писательства с стиле "суперцикл". Для такого подхода к делу наличие наворотов контролера в сторону навороченных вложенных прерываний, есть несомненное благо.

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

Посему для начала не надо плодить без надобности решения для стрельбы в ногу.

[jcxz]

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

Костыли - это когда начинают по каким-то идеологическим/религиозным причинам игнорировать существующие механизмы и пытаться создать свой лисапет с квадратными колёсами.
Кто-то начинает городить интерфейсы ногодрыгом при наличии аппаратно-реализованных, кто-то не использует вложенность прерываний...
Какой бы ни была функциональной ОС, во многих случаях обработать какие-то события прямо в ISR (и соответственно, пропустить "вперёд" более время-критические ISR посредством приоритета)
бывает гораздо удобнее/быстрее, чем тащить это всё в задачу ОС.

Большая, но ненужная мне радость. На самом деле контроллер прерываний МЛАДШИХ кортексов это именно костыль. У старших, как и у "старых" армов, контролеры прерываний без этих костылей. Причина проста - явно предполагалось перетаскивать под крыло младших кортексов программистов с восьмибитовиков с их де-факто стилем писательства с стиле "суперцикл".

Да ладно!! Это FIQ/IRQ в ARM7/9 - лучше???
Ну да, он удобнее когда нет вытесняющей ОС. Когда не надо переключать контексты задач и когда мало ISR, могущих конкурировать друг с другом по времени. И можно одно-два самых быстрых прерывания вынести в отдельный контекст FIQ.
Но как только возникают задачи вытесняющей ОС, как только оказывается необходимым копировать стеки между разными состояниями CPU (нормальное/IRQ/FIQ/...) сразу всё это удобство превращается в огромный костыль.
И не надо тут сказки рассказывать - мне приходилось писать порты ОС и под ARM7/9 и под Cortex-M. И это небо и земля по сложности/размеру. И любой желающий может самостоятельно сделать такой вывод взглянув на готовые переключатели задач для классических ARM и для Cortex-M.
Архитектура NVIC в Cortex-M как раз и была создана с целью оптимизации для использования под ОС. В то время как IRQ/FIQ классических ARM - для ускорения обработки ISR без механизма вытеснения задач в ISR.

[zltigo]

Костыли - это когда начинают по каким-то идеологическим/религиозным причинам игнорировать существующие механизмы и пытаться создать свой лисапет с квадратными колёсами.

Операционная система с вытесняющей многозадачностью не является "лисапет с квадратными колёсами".

Какой бы ни была функциональной ОС, во многих случаях....

Количество таких случаев зависит от сложности решаемых контроллером задач и наличия головы на полечах у решающего эти задачи.

Да ладно!! Это FIQ/IRQ в ARM7/9 - лучше???

Да, лучше. В этом случае FIQ это действительно и быстрое и приоритетное. Как раз для таких случаев когда действительно надо. На форуме уже было пара веток разговоров чем контроллер препываний ARM7/9 и старших кортексов лучше, чем удобный "кирпич" младших кортексов. Например: https://electronix.ru/forum/index.php?showt...t&p=1348629

Ну да, он удобнее когда нет вытесняющей ОС.

Глупость. Удобство состоит в возможности реализации замыслов, а не в том, что что то там "само" сохраняется не требуя умственных усилий и кода.

Архитектура NVIC в Cortex-M как раз и была создана с целью оптимизации для использования под ОС. В то время как IRQ/FIQ классических ARM - для ускорения обработки ISR бс в ISR.

По Вашей "теории" Cortex-A так же рождены для безосевых решений

P.S.
То, что касается "сделать такой вывод взглянув на готовые переключатели задач для классических ARM", то глядя на некоторые реализации портов, например, uCOS для ARM7, можно сказать, что для его писателя, действительно "M" есть благо, поскольку железо он абсолютно не понимает и то, что он сотворил с обработкой прерываний вообще и преключателе задач в частности, ни в какие ворота не лезет.

[jcxz]

То, что касается "сделать такой вывод взглянув на готовые переключатели задач для классических ARM", то глядя на некоторые реализации портов, например, uCOS для ARM7, можно сказать, что для его писателя, действительно "M" есть благо, поскольку железо он абсолютно не понимает и то, что он сотворил с обработкой прерываний вообще и преключателе задач в частности, ни в какие ворота не лезет.

Может приведёте здесь Ваш переключатель задач для classic ARM? Чтобы не быть голословным.

[zltigo]

Может приведёте здесь Ваш переключатель задач для classic ARM? Чтобы не быть голословным.

В первом приближении берете, например, FreeRTOSовские порты ARM7 и M3 и сравниваете на предмет наличия ужасных сложностей порта ARM7.
У меня отличия от штатного ARM7 порта под IAR не разительные. Могу, конечно, и свой выложить. Это не секрет. Просто под руками сейчас нет.
Потом можете сравнить с тем, что для ARM7 начиная со startup c бодуна понаписано в uCOS. Там действительно страшненько, но это не следствие ARM7, а следствие уровня писавшего порт.

[klen]

интересненько почитал... а то как то вяло на электрониксе последние пол года
по существу думаю Вы оба правы! но каждый про свое.
механизмы прерываний реализованные в железе и ОСность вещи перпендикулярные.
на armv4 считаю что создть невозможно вложенные прерывания абсалютно надежно, вот их там и не любят. в armv7 это решили пофиксить но тоже не без придури, поэтому получилось полено папы Карло.
я традиционно из stm32 "ПЛИСину" выжимаю поэтому мне ближе механизмы заложенные в armv7 так как более детерминированая сисием получается.
ну и с наступающим всех!!!
желаю всем в НГ менее глючного кода и более быстрого железа.