__LDREX __STREX в STM32F407 Опции

[_lexa_]

Всем доброе время суток!

IDE - IAR+плагин IAR для eclipse+eclipse.
Решил проверить, как работает синхронизация с использованием __LDREX/__STREX. Пишем следующий код

CODE

typedef struct
{
...
volatile unsigned long sync; //переменная для синхонизации доступа к данному элементу
} burst_measur;

burst_measur cur_mes;

void mpu_cfg_test()
{
//настраиваем область внутренней RAM, как разделяемую
__DMB();
SCB->SHCSR &= ~SCB_SHCSR_MEMFAULTENA_Msk;
MPU->CTRL = 0U;

MPU->RNR = 0UL;
MPU->RBAR = 0x20000000UL;
MPU->RASR = (0x10UL << MPU_RASR_SIZE_Pos) | MPU_RASR_C_Msk | MPU_RASR_S_Msk | (0x3 << MPU_RASR_AP_Pos) | MPU_RASR_ENABLE_Msk;

MPU->CTRL = MPU_CTRL_PRIVDEFENA_Msk | MPU_CTRL_ENABLE_Msk;
SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk;
__DSB();
__ISB();

//выполняем запрос эксклюзивного доступа к переменной cur_mes.sync
DWORD sync=0;
sync = __LDREX(&cur_mes.sync);
__DMB();
soft_int_ini(); //настойка программного прерывания
soft_int_on(); //вызов программного прерывания
__WFI();
}

в обработчике программного прерывания:

CODE

DWORD sync;
do
{
sync = __LDREX(&cur_mes.sync);
sync++;
sync = __STREX(sync, &cur_mes.sync);
}
while (sync);

Т.е. сначала выполняется __LDREX(&cur_mes.sync), потом происходит прерывание и выполняется __LDREX(&cur_mes.sync) + __STREX(sync, &cur_mes.sync).
По всем документациям, как я их понял, __STREX(sync, &cur_mes.sync) должна возвратить "не ноль", однако возвращает "ноль".

Помогите, пожалуйста, разобраться, что я делаю не правильно?

[Alechek]

И правильно! Через DMA и пр. - ЗАЧЕМ???

Импульсивный Вы наш, по делу бы что сказали!

Добавьте в ваш список выводов, что монитор может срабатывать на любое изменение уровня прерываний

Добавил, куда можно было. Весь этот раздел A3.4 - сплошные выводы. Читать и читать.

ЗЫ. Хотя насчёт DMA - я лично не верю. В этом случае при непрерывно идущих быстрых транзакциях DMA можно наглухо зависнуть в LDREX/STREX.

Мне тоже идея с DMA не очень нравится.
Вроде как не обязательно Store от ядра должно исходить.... В одном месте так написано, в другом - по другому...
Вобщем, все на откуп реализации:

Опыты, только опыты... Ни в одной докуметации на MCU не видел таких тонкостей.

[AVI-crak]

Проверять нужно кодом на асме, чтобы gcc не наоптимизировал записи до нуля.
Тестовую запись нужно сбрасывать в память принудительно, с ожиданием завершения физической записи.
Неявная запись (PUSH) - является отложенным событием (как и любая запись кучи регистров), код выполняется параллельно, сбросить физику с подтверждением не получится, но можно немного подождать в пустом цикле или сбросить конвейер.

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

[jcxz]

Неявная запись (PUSH) - является отложенным событием (как и любая запись кучи регистров), код выполняется параллельно, сбросить физику с подтверждением не получится, но можно немного подождать

Сколько? Сколько вешать в граммах?

в пустом цикле или сбросить конвейер.

Это что такое? И как оно поможет?

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

DMB/DSB/и прочие B - спасут отца русской демократии

На Cortex-M, которые по определению одноядерные

Вы это расскажите NXP с их линейкой LPC43xx. Про свои определения.
Или Ваш мир Cortex-M ограничен STM32?
Курица - не птица, Cortex-M - не STM! Рифма одна-ко. Надо в подпись внести ©

[Forger]

Коли SVC синхронное и его не получиться использовать нормально в прерываниях (для lockfree решений), то может быть для этой цели подойдет pendSV?

А, чтобы разделить переключатель контекста rtos и юзерские вызовы этого самого pendSV, скажем, в R0 кладем адрес функции, а в остальные регистры ее параметры, а уже внутри pendSV все это разбираем.
Приоритет pendSV самый низкий (ниже лишь systick).
Тогда другой вызов pendSV прервать его не сможет, а лишь поставить в очередь. Т.е. обеспечивается атомарность действий как в прерываниях, так и в основном коде.
Вижу одно ограничение - передавать в такие функции указатели нежелательно, а можно лишь готовые данные (прямо в регистры R1...), т.е. ограничен объем передаваемых данных.
В противном случае нет никакой гарантии, что к моменту вызова соотв. функции (внутри pendSV) данные по указателям будут актуальны.

Или тут есть какие-то подводные камни?
зы. Предположительно вангую грабли со вложенными вызовами (вытесняющие прерывания), где оба обработчика вызывают pendSV...

[jcxz]

зы. Предположительно вангую грабли со вложенными вызовами (вытесняющие прерывания), где оба обработчика вызывают pendSV...

PendSV не "вызывают", а лишь возбуждают запрос на него. В том числе и в ISR-ах, где вход в PendSV будет отложен до завершения всех других ISR, а из фонового процесса - вход в PendSV будет сразу, подобно синхронному SVC.

[Forger]

PendSV не "вызывают" ...

Да, это-то понятно, это все - придирки к словам, а речь о другом:
как сделать так, чтобы pendSV могли вызывать взводить разные обработчики, особенно вложенные друг в друга, но так, чтобы в стеке сформировалась очередь данных, которые позволят этот pendSV обработать несколько раз подряд и не потерять ни одного запроса и не разрушить стек?
Понятно, что pendSV не для этого был задуман, но тем не менее ))

Размышляя вслух дальше - выполняемый в данный момент pendSV может прервать другое более приоритетное прерывание и опять накидать в стек новых данных перед взводом pendSV,
Или использовать внутри pendSV вызов соотв. SVC, который имеет приоритет выше pendSV...
Заумно как-то выходит. Но возможно ли осуществить что-то подобное?
Цель - избежать критических секций с запретом прерываний и "капризного" LDREX/STREX.

[Шаманъ]

как сделать так, чтобы pendSV могли вызывать взводить разные обработчики, особенно вложенные друг в друга, но так, чтобы в стеке сформировалась очередь данных, которые позволят этот pendSV обработать несколько раз подряд и не потерять ни одного запроса и не разрушить стек?

Очередь данных в стеке не формируется - формируйте ее отдельно, а потом обрабатывайте в PendSV. Но для данной задачи это неэффективно и не имеет смысла - есть LDREX/STREX, если его не хватает, то есть запрет части или всех прерываний.

[Forger]

Очередь данных в стеке не формируется - формируйте ее отдельно, а потом обрабатывайте в PendSV.

А все равно грабли - процесс формирования очереди должен быть защищен критической секцией, масло масляное (((

Но для данной задачи это неэффективно и не имеет смысла - есть LDREX/STREX, если его не хватает, то есть запрет части или всех прерываний.

Согласен, но хочется ведь гипотетического универсального решения, вот и спрашиваю )))

Короче, задача довольно тривиальная:
программная очередь, набиваемая в обработчике (скажем, очередь байтов), там же сигналим счетным семафором, переходим к соотв. задаче, которая это семафор ждет и выгребает из этой же очереди байты.
Нужно защищать указатели (голова/хвост) очереди от прерывания.

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

[Шаманъ]

хочется ведь гипотетического универсального решения

Если пишите под GCC, то можно посмотреть на atomic built-in функции https://gcc.gnu.org/onlinedocs/gcc-4.4.3/gc...c-Builtins.html .

Короче, задача довольно тривиальная:
программная очередь, набиваемая в обработчике (скажем, очередь байтов), там же сигналим счетным семафором, переходим к соотв. задаче, которая это семафор ждет и выгребает из этой же очереди байты.
Нужно защищать указатели (голова/хвост) очереди от прерывания.

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

[Forger]

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

Еще как происходит - я контролирую переполнение и исчерпание очереди (соотв. ловушки/логи)!
Если в задаче в процессе извлечения свежего байта из очереди пришел еще один новый байт,
который нужно быстро положить в ту же очередь, то без соотв. критических секций получим что угодно, обычно получаем HF.
Поэтому эти две вещи нужно изолировать - пока достаем байт из очереди (в задаче), временно запрещаем прерывания от того, кто наполняет эту очередь.

Именно это я и описал выше.
У меня очередь сделана в виде шаблона, всего один параметр - тип данных.
При создании экземпляра очереди ей передается ссылка на класс Interrupt, в котором есть два обязательным метода disable и enable.
Для каждой очереди он может быть свой, поэтому запрещаются лишь те прерывания, которые конфликтуют с конкретным экземпляром очереди.

Семафор это головная боль ОС.

При чем тут это?
Я лишь привел пример с осью, как наиболее универсальный.
Но кто не пользуется осью, могут просто поллить некий флажок в основном коде, а в прерываниях его взводить или инкрементировать.
Способ оповещения основного кода в данном случае не имеет никакого значения. Отклоняемся от темы )))

[Шаманъ]

При чем тут это?
Я лишь привел пример с осью, как наиболее универсальный.
Но кто не пользуется осью, могут просто поллить некий флажок в основном коде, а в прерываниях его взводить или инкрементировать.
Способ оповещения основного кода в данном случае не имеет никакого значения. Отклоняемся от темы )))

Это как раз причина по которой у меня с ОС не происходит, а с "неким флажком" происходит. Поясняю:

Если работа задачи, которая извлекает данные из очереди управляется семафором через ОС, то "недополнения" очереди возникнуть просто не может - задача блокируется и ожидает когда появятся данные. Поэтому указатель "хвоста" в полной безопасности.

Теперь про голову - данные из UART выгребаем в прерывании, в этом же прерывании увеличиваем счетчик семафора и добавляем в очередь. Чтобы избежать переполнения очереди достаточно проверить счетчик семафора. Вот собственно и все. Счетчик семафора это проблема ОС, остальное (очередь и указатели на голову/хвост) в полной безопасности.

Если интересно, как сделана у меня в ОС работа с семафорами, то через те же LDREX/STREX Правда это если не касаться вопросов переключения задач и системных вызовов, но то уже точно другая тема.

[Forger]

Это как раз причина по которой у меня с ОС не происходит, а с "неким флажком" происходит. Поясняю:

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

Приоритет SVC - 0.
Пользовательские прерывания 1~14.
Системный таймер, и таймер реального времени =15.

Поменять шило на мыло?
По вашей логике получится, что пока этот приоритетный SVC не отработает, ни одно более важное аппаратное прерывание не пройдет.
SVC с таким высоким приоритетом, вызываемые из других менее приоритетных прерываний по сути временно задирает их собственный приоритет, который был "ниже плинтуса", отбирая "право голоса" у более приоритетных прерываний.
На лицо - инверсия приоритетов. С чем боролись на то и напоролись. Ни чем не лучше глобальной критической секции (запрет/разрешение всех прерываний).

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

[Шаманъ]

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

От же ж...ну как Вам еще объяснить. Читайте внимательно и думайте:
1. Указатель на голову (куда добавляются данные) он используется только в прерывании которое добавляет данные, только там, и больше нигде.
2. Указатель на хвост (откуда вычитываются данные) он используется только в задаче которая читает данные, только там, и больше нигде.

Синхронизация делается семафором, как и защита от переполнения/недополнения. К семафору есть доступ и у задачи, и у прерывания, но он делается через ОС.

Теперь понятно? Если нет, то перечитайте пожалуйста еще раз, ну или несколько раз - не знаю как объяснить иначе...

[Forger]

От же ж...ну как Вам еще объяснить. Читайте внимательно и думайте:

Я про Фому, а он - про Ерему ...

Ясен пень, что голова и хвост изменяются в разным местах - один в фоне задач, другой - в перрывании, но !
Чтобы проверить переполнение/исчерпание, нужно контроллировать в непрерывном куске кода ОБА указателя/индекса.
Это можно делать только там, где производите изменение этих самых указателей/индексов - в прерывании и в фоне задач.
В прерывании это не проблема - защищать ничего не нужно, достаточно лишь не класть в буфер новые данные и кинуть соотв. сообщение/исключение.
А в фоне задачи нужно защищать обращение к ОБОИМ указателям в некой критической секции, иначе невозможно контроллировать подобные аварийные события.
Если этого не делать, то буфер может быть переполнен/исчерпан так, что об этом невозможно будет узнать.

Также реализуется обратная ситуация - задача кладет данные в буфер, взводит нужное прерывание и уже в соотв. обработчике буфер выгребается и отправляется во вне.
Чтобы положить данные в буфер в фоне задачи, нужно обращаться в непрерывном куске кода к ОБОИМ указателям. Поэтому тут нужна критическая секция или что-то подобное.

Синхронизация делается семафором...

Точно, я про Фому, а он - про Ерему )))

[Шаманъ]

Чтобы проверить переполнение/исчерпание, нужно контроллировать в непрерывном куске кода ОБА указателя/индекса.

Нет. Достаточно проверить состояние семафора.

А в фоне задачи нужно защищать обращение к ОБОИМ указателям в некой критической секции, иначе невозможно контроллировать подобные аварийные события.
Если этого не делать, то буфер может быть переполнен/исчерпан так, что об этом невозможно будет узнать.

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

Про прерывание Вы и сами написали. Так кто там про Фому

Также реализуется обратная ситуация - задача кладет данные в буфер, взводит нужное прерывание и уже в соотв. обработчике буфер выгребается и отправляется во вне.
Чтобы положить данные в буфер в фоне задачи, нужно обращаться в непрерывном куске кода к ОБОИМ указателям. Поэтому тут нужна критическая секция или что-то подобное.

Да не нужно - достаточно семафора.

P.S. Может быть Вы не так понимаете что такое семафор. У меня это объект синхронизации задач, который может принимать значения от 0 до некоторого MAX. Счетчик семафора показывает доступность ресурса (в данном случае кол-во данных в очереди). Задача может запросить конкретное кол-во данных или диапазон (от и до) - если нужное кол-во доступно, то задача получит запрошенное кол-во данных, если нет, то будет приостановлена, пока не будет доступно запрошенное кол-во данных.

[Forger]

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

Не, это - уже бесполезный спор.

[Шаманъ]

Не, это - уже бесполезный спор.

Конечно, ибо то, о чем я пишу работает

ОК поставим вопрос по-другому, каким образом может быть переполнен буфер в задаче, которая из него только читает?

[Forger]

Конечно, ибо то, о чем я пишу работает

И самолеты летают. Но иногда, увы, падают

ОК поставим вопрос по-другому, каким образом может быть переполнен буфер в задаче, которая из него только читает?

Если она только читает, то буфер со временем просто переполнится, чтобы избежать этого, из буфера нужно не просто читать данные, но и изменять соотв. указатель.
При заполнении буфера (в прерывании) нужно сравнивать ОБА указателя.
Если это прерывание возникнет между чтением данных в задаче и изменением соотв. указателя, то будет беда. Обнаружить ее крайне сложно.


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

Я делал это несколько иначе, использовал счетчик свободного места, вообще не сравнивая указатели. Это получается несколько быстрее, но отъедает немного места в памяти.
Обращение к этому счетчику и изменение соотв. указателей, должно быть непрерывным. Иначе - HF

[jcxz]

Я делал это несколько иначе, использовал счетчик свободного места, вообще не сравнивая указатели. Это получается несколько быстрее, но отъедает немного места в памяти.
Обращение к этому счетчику и изменение соотв. указателей, должно быть непрерывным. Иначе - HF

Вот как раз со счётчиком - это плохая реализация, так как обязательно требует критической секции.
Реализация кольцевого буфера на двух указателях (один - чтения, другой - записи) для своей работы не требует критических секций при условии, что есть только один процесс/ядро- писатель и только один процесс/ядро- читатель. И это справедливо только для этих процессов. Т.е. - не требуется ни для чего - ни для вычисления свободного места ни для вычисления уровня заполнения и т.п.
Если состояние кольца читается 3-ей стороной (процессом/ядром отличным от читателя и писателя), то для этого критическая секция нужна.
А в читателе и писателе - нет. Так как каждый из них модифицирует только один указатель, а второй указатель использует только на чтение.

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

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

[Forger]

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

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

Поясню.
Скажем в очереди остался всего один элемент.
Нужно туда положить еще один, он последний в отправляемом пакете.
Кладем его в голову очереди, далее должны сдвинуть указатель головы, но не успели - произошло прерывание передатчика.
В нем мы видим, что очередь непустая (сравнили два указателя), еще есть один элемент. Но всего один.
Отправляем его, сдвигаем хвост. Видим, что хвост и голова совпали - прекращаем передачу и формируем соотв. сообщение.
Возвращаемся из прерывания, сдвигаем голову вперед на один.
Ждем сообщения об окончании всей передачи, в том числе и этого последнего байта.
Успешно его дожидаемся, ведь передача была только что прекращена.
В итоге последний элемент данных не был отправлен.

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

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

[jcxz]

Понимаю, ситуация редкая и очень трудноуловимая, но она вполне возможна.

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

[Forger]

К работе кольца это отношения не имеет.

Да неужели?
Речь тут как раз про возвожность разорвать атомарную операцию записи в буфер обработчиком, который к этому же очереди и обращается.
Пусть заполнение буфера и передача обращаются к разным указателям, но как минимум факт исчерпания очереди требует чтения обоих указателей.
Поэтому операция записи по указателю и его инкремента должна быть атомарной.
Либо не использовать прерывания.

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

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

flush() в читающем процессе: Ring::flush() { rpos = wpos; } - однозначно очистка атомарна без всяких крит. секций

Нет, неатомарна - обычная операция чтение-модификация-запись. Может быть прервана прям посреди.
Или же прервать другое обращением к этим же полям в фоне задач.
Ее нельзя вызывать в фоне задач, пока активно и разрешено соотв. прерывание.

"Реальный код" не ограничивается только передачами по каналу связи. И далеко не везде нужен flush(). Даже скорей - редко где нужен. имха

Он нужен лишь при аварийных ситуациях, в штатном коде он действительно не нужен.
Я описал устройство, которое работает долго и без обслуги. Если повиснет и не сможет себя привести в норму самостоятельно, то беда будет (((