Атомарная операция, STM32F10x Опции

[cz_nikita]

Как запрерить прерывания в STM32F10x?
Ну, и как разрешить прерывания в STM32F10x?
Нужно, для выполнения атомарной операции.

[MALLOY2]

scmRTOS содержит прекрасный класс-обертку на С++, реализующий вход/выход в/из критической секции.

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

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

[sergeeff]

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

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

[Dog Pawlowa]

...А если у вас используются, например, вложенные прерывания?

А объясните плз, что за неатомарные операции в 32-разрядном контроллере?
Это еще нужно извратиться, чтобы проблема возникла.

[Alex B._]

А объясните плз, что за неатомарные операции в 32-разрядном контроллере?
Это еще нужно извратиться, чтобы проблема возникла.

При чем тут 32-бита? А не атомарные - любое чтение-модификация-запись.

[Dog Pawlowa]

При чем тут 32-бита? А не атомарные - любое чтение-модификация-запись.

Да не любое. Банальная передача флага от одного "процесса" другому не требует атомарности. Ну опросит второй процесс флаг после чтения переменной из памяти первым процессом ? - ничего не изменится.
А вот инкремент переменной - требует. Поэтому разрядность влияет.

[Alex B._]

Да не любое. Банальная передача флага от одного "процесса" другому не требует атомарности. Ну опросит второй процесс флаг после чтения переменной из памяти первым процессом ? - ничего не изменится.
А вот инкремент переменной - требует. Поэтому разрядность влияет.

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

[sonycman]

Про разрядность так и не понял. У любой RMW архитектуры существует подобная проблема, вне зависимости от разрядности.

Но ведь всё просто.
К примеру, имеется ISR таймера с единственной инструкцией - counter++;
Если проц восьмибитный и counter имеет разрядность больше байта - перед чтением значения (в основном цикле) надо заходить в critical section, иначе, после чтения первого байта, может проскочить прерывание и второй байт будет изменён. Таким образом мы получим один байт от предыдущего значения счётчика, а второй и последующие - от нового.
Если разрядность проца 32 бита (а переменная counter в большинстве случаев не будет превышать такую разрядность), то считывать можно без всяких секций - проц в любом случае прочитает её целиком.

[Сергей Борщ]

Но ведь всё просто.

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

[sonycman]

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

Тогда тоже всё просто - critical section

[sergeeff]

Тогда тоже всё просто - critical section

Так вот именно про это выше по-русски и сказано : критическая секция, а не просто запрет/разрешение прерываний.

[sonycman]

Так вот именно про это выше по-русски и сказано : критическая секция, а не просто запрет/разрешение прерываний.

А кто спорит? Если задача не совсем простенькая, и прерывания в процессе динамически запрещаются/разрешаются в нескольких потоках, то нужно восстанавливать сохранённое значение PRIMASK/FAULMASK перед выходом из CS, а не просто тупо их разрешать.