caxapa.ru :: Нет, текущий приоритет (приоритет обрабатываемого в данный момент прерывания) снизить нельзя. Тиритицки (не проверял) можно изменить значение приоритета в NVIC и программно взвести (через NVIC) то же прерывание еще раз. Тогда по выходу из текущего обработчика мы снова перезайдем в тот же обработчик, но уже на новом (более низком) уровне приоритета. Но тогда при наступлении нового события мы не смодем его гарантированно быстро обработать, потому что приоритет уже понижен и

LightElf (14.10.2025 18:14, просмотров: 176) ответил il-2 на Там ниже еще LightElf пример привел, связанный с приоритетами. Все, теперь врубился до конца. Но текущий приоритет можно снизить (наверное) в NVIC. Если так, то можно обойтись без программных прерываний (подпрограммами). Можно, но сложно :-)

Нет, текущий приоритет (приоритет обрабатываемого в данный момент прерывания) снизить нельзя. Тиритицки (не проверял) можно изменить значение приоритета в NVIC и программно взвести (через NVIC) то же прерывание еще раз. Тогда по выходу из текущего обработчика мы снова перезайдем в тот же обработчик, но уже на новом (более низком) уровне приоритета. Но тогда при наступлении нового события мы не смодем его гарантированно быстро обработать, потому что приоритет уже понижен и

смысл схемы не очень ясен. Использование PendSV (или какого-то неиспользуемого прерывания) как раз хорошо решает проблему: быстрая реакция на событие за счет высокого приоритета основного прерывания и относительно неспешная обработка в дополнительном. Использую такое на CH579 с его удивительным Ethernet ;-)

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- Тут: Nikolay_Po(978 знак., 14.10.2025 20:45, ссылка)
  - BASEPRI, насколько я помню, маскирует прерывания с приоритетом ниже указанного. На уже активное прерывание он не влияет. ARM пишет про него такое: LightElf(591 знак., 14.10.2025 22:58, +1)
    - Хмм... Сейчас вернулся к развитию проекта на Cortex-M3. Смотрю - у меня вовсю меняется BASEPRI и часто, даже большую часть случаев - из кода прерывания, во время нахождения в прерывании. Таким образом, решаю задачу временного поднятия приоритета для обеспечения атомарности обращения к общим ресурсам. Но всегда меняется только в сторону повышения приоритета, в сторону маскирования более приоритетных прерываний. И работает. - Nikolay_Po(02.01.2026 19:56)
    - Спасибо! Особенно за вторую цитату. Получается, оно может работать, но при разработке ядра и контроллера прерываний, эту ситуацию не прорабатывали и никто ничего не гарантирует. - Nikolay_Po(15.10.2025 16:06)
      - Предположу, что на разных ядрах (M0, M3, M7, M33, etc) оно может себя вести по-разному. Например во всяких там навороченных M7 NVIC может быть реализован совсем не так, как на простеньких M0. - LightElf(15.10.2025 18:48)

ARM, RISC-V контроллеры