pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 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 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 4 minutes ago, piroman said: TIM6 всё-таки произойдёт сразу после, или нет и следующей строке кода ничего не грозит? Не произойдёт. Но можете для уверенности (хотя для Cortex-M3 это и не нужно) добавить барьер синхронизации, команду : ISB. P.S. А чего на асме пишите?) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 1 minute ago, haker_fox said: Не произойдёт. Но можете для уверенности (хотя для Cortex-M3 это и не нужно) добавить барьер синхронизации, команду : ISB. P.S. А чего на асме пишите?) А DSB не хватит? На асме я пытаюсь оптимизировать некоторые функции :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shaft45 0 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 (изменено) · Жалоба 6 minutes ago, shaft45 said: Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание А зачем? Я прерывание временно отключаю (на десяток команд) и оно мне потом нужно будет. Да и бесполезно флаги проверять до запрета прерывания - они ж после проверки могут появиться Изменено 2 апреля, 2020 пользователем piroman Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 15 minutes ago, piroman said: А DSB не хватит? Честно говоря, я не очень в этом вопросе разбираюсь. Я, мне кажется, погорячился. Здесь барьеры не нужны. Вы ведь не обращаетесь потом к NVIC, например. 6 minutes ago, shaft45 said: Убедитесь, что флаги (ожидающие) в нуле, прежде чем деактивировать прерывание Их нужно чистить после отключения прерывания, а иначе почистил, а оно в этот момент возникло. Смысла нет. Нужно сразу отключать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 (изменено) · Жалоба 5 minutes ago, haker_fox said: Честно говоря, я не очень в этом вопросе разбираюсь. Я, мне кажется, погорячился. Здесь барьеры не нужны. Вы ведь не обращаетесь потом к NVIC, например. Их нужно чистить после отключения прерывания, а иначе почистил, а оно в этот момент возникло. Смысла нет. Нужно сразу отключать. Мне кажется какой-то барьер тут всё-таки нужен. Команда обращения к памяти strh R2,[R3,#0x0C] может выполняться несколько тактов и, думаю, где-то между этими тактами может проскочить прерывание, которое запрещаем Изменено 2 апреля, 2020 пользователем piroman Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 35 minutes ago, piroman said: Мне кажется какой-то барьер тут всё-таки нужен. Если ваша следующая часть программы после запрета прерывания расчитывает на то, что они уже выключены, то да, думаю, что барьер нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 130 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 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 182 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 4 часа назад, piroman сказал: Существует ли вероятность, что прерывание TIM6 всё-таки произойдёт сразу после, или нет и следующей строке кода ничего не грозит? Существует. Запрещаете прерывания Вы в периферии (таймере). А если он уже сформировал запрос прерывания (ещё необслуженный), то этот запрос уже защёлкнулся в NVIC. И тогда прерывание произойдёт как только будет: снят глобальный запрет прерываний && снята маска прерывания с данного вектора NVIC && текущий приоритет прерывания понизится ниже чем у вектора этого таймера. Чтобы не произошло, нужно маскировать вектор прерывания через NVIC. Ну или очищать ждущее прерывание после его запрета в периферии. Т.е.: 1) запрет в периферии; 2) DMB; 3) очистка в NVIC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 1 hour ago, Arlleex said: Однако буфер записи может быть в реализации системного уровня (конкретная периферия МК), DSB и прочие не помогут. Поможет только второй доступ к памяти с таким же атрибутом (например, чтение того же регистра после его записи). Спасибо. Наверное, тогда быстрее (т.к. NVIC часть ядра) и правильнее будет запретить прерывание через NVIC->ICER... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 182 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 2 минуты назад, piroman сказал: Наверное, тогда быстрее (т.к. NVIC часть ядра) и правильнее будет запретить прерывание через NVIC->ICER... Быстрее. Только через ICER - это не запрет, а маскирование. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба 1 minute ago, jcxz said: Быстрее. Только через ICER - это не запрет, а маскирование. А какая разница? Суть то одинаковая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 182 2 апреля, 2020 Опубликовано 2 апреля, 2020 · Жалоба Только что, piroman сказал: А какая разница? Суть то одинаковая. Разница в том что запрос на прерывание (если он был) продолжает храниться в pending-регистрах. И активируется сразу после размаскирования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pyroman 2 2 апреля, 2020 Опубликовано 2 апреля, 2020 (изменено) · Жалоба 7 minutes ago, jcxz said: Разница в том что запрос на прерывание (если он был) продолжает храниться в pending-регистрах. И активируется сразу после размаскирования. С таким же успехом можно написать - "И активируется сразу после разрешения". И даташит указывает "Interrupt set-enable registers (NVIC_ISERx)". Где вы тут увидели, допустим, unmasked? В конце концов, не придирайтесь к словам :) Изменено 2 апреля, 2020 пользователем piroman Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться