[pyroman 2]

movs    R2,#0
ldr     R3,=TIM6_BASE
strh    R2,[R3,#0x0C] ;TIM6_DIER = 0 - запрет прерывания TIM6
ldr     R0,[R1]

Приветствую.

Имею STM32F100 на частоте 24 МГц.

Запрещаю прерывание TIM6 командой

strh    R2,[R3,#0x0C]

Существует ли вероятность, что прерывание TIM6 всё-таки произойдёт сразу после, или нет и следующей строке кода ничего не грозит?

[haker_fox 60]

4 minutes ago, piroman said:

TIM6 всё-таки произойдёт сразу после, или нет и следующей строке кода ничего не грозит?

Не произойдёт. Но можете для уверенности (хотя для Cortex-M3 это и не нужно) добавить барьер синхронизации, команду : ISB.

P.S. А чего на асме пишите?)

[pyroman 2]

1 minute ago, haker_fox said:

Не произойдёт. Но можете для уверенности (хотя для Cortex-M3 это и не нужно) добавить барьер синхронизации, команду : ISB.

P.S. А чего на асме пишите?)

А DSB не хватит?

На асме я пытаюсь оптимизировать некоторые функции :)

[shaft45 0]

Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание

[pyroman 2]

6 minutes ago, shaft45 said:

Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание

А зачем? Я прерывание временно отключаю (на десяток команд) и оно мне потом нужно будет. Да и бесполезно флаги проверять до запрета прерывания - они ж после проверки могут появиться

Изменено 2 апреля, 2020 пользователем piroman

[haker_fox 60]

15 minutes ago, piroman said:

А DSB не хватит?

Честно говоря, я не очень в этом вопросе разбираюсь. Я, мне кажется, погорячился. Здесь барьеры не нужны. Вы ведь не обращаетесь потом к NVIC, например.

6 minutes ago, shaft45 said:

Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание

Их нужно чистить после отключения прерывания, а иначе почистил, а оно в этот момент возникло. Смысла нет. Нужно сразу отключать.

[pyroman 2]

5 minutes ago, haker_fox said:

Честно говоря, я не очень в этом вопросе разбираюсь. Я, мне кажется, погорячился. Здесь барьеры не нужны. Вы ведь не обращаетесь потом к NVIC, например.

Их нужно чистить после отключения прерывания, а иначе почистил, а оно в этот момент возникло. Смысла нет. Нужно сразу отключать.

Мне кажется какой-то барьер тут всё-таки нужен.
Команда обращения к памяти strh    R2,[R3,#0x0C] может выполняться несколько тактов и, думаю, где-то между этими тактами может проскочить прерывание, которое запрещаем

Изменено 2 апреля, 2020 пользователем piroman

[haker_fox 60]

35 minutes ago, piroman said:

Мне кажется какой-то барьер тут всё-таки нужен.

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

[Arlleex 131]

Architecture Reference Manual на ARMv7-M:

Цитата

A3.5.5 Device Memory

...

When a Device memory operation has side effects that apply to Normal memory regions, software must use a 
Memory Barrier to ensure correct execution. An example is programming the configuration registers of a memory 
controller with respect to the memory accesses it controls.

...

 

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

Даже если произойдет прерывание, оно сохранит регистры в стек и после извлечет обратно.

При этом прерывание по побочным эффектам равноценно инструкциям барьеров памяти.

 

Если есть доступ к памяти с атрибутом Normal (например, ОЗУ), то нужен барьер DSB.

На память с атрибутом Device (все I/O-регистры) не распространяется буфер записи.

Однако буфер записи может быть в реализации системного уровня (конкретная периферия МК), DSB и прочие не помогут.

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

[jcxz 184]

4 часа назад, piroman сказал:

Существует ли вероятность, что прерывание TIM6 всё-таки произойдёт сразу после, или нет и следующей строке кода ничего не грозит?

Существует. Запрещаете прерывания Вы в периферии (таймере). А если он уже сформировал запрос прерывания (ещё необслуженный), то этот запрос уже защёлкнулся в NVIC. И тогда прерывание произойдёт как только будет: снят глобальный запрет прерываний && снята маска прерывания с данного вектора NVIC && текущий приоритет прерывания понизится ниже чем у вектора этого таймера.

Чтобы не произошло, нужно маскировать вектор прерывания через NVIC. Ну или очищать ждущее прерывание после его запрета в периферии.

Т.е.:

1) запрет в периферии;

2) DMB;

3) очистка в NVIC.

[pyroman 2]

1 hour ago, Arlleex said:

Однако буфер записи может быть в реализации системного уровня (конкретная периферия МК), DSB и прочие не помогут.

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

Спасибо.
Наверное, тогда быстрее (т.к. NVIC часть ядра) и правильнее будет запретить прерывание через NVIC->ICER...

[jcxz 184]

2 минуты назад, piroman сказал:

Наверное, тогда быстрее (т.к. NVIC часть ядра) и правильнее будет запретить прерывание через NVIC->ICER...

Быстрее. Только через ICER - это не запрет, а маскирование.

[pyroman 2]

1 minute ago, jcxz said:

Быстрее. Только через ICER - это не запрет, а маскирование.

А какая разница? Суть то одинаковая.

[jcxz 184]

Только что, piroman сказал:

А какая разница? Суть то одинаковая.

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

[pyroman 2]

7 minutes ago, jcxz said:

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

С таким же успехом можно написать - "И активируется сразу после разрешения".

И даташит указывает "Interrupt set-enable registers (NVIC_ISERx)". Где вы тут увидели, допустим, unmasked?

В конце концов, не придирайтесь к словам :)

Изменено 2 апреля, 2020 пользователем piroman