caxapa.ru :: Что-то я читал, читал... понял наконец в чем тонкость. Но это все можно сделать и в подпрограмме - типа программного семафора, и заменить таки программное прерывание на вызов подпрограммы. Код подпрограммы должен быть реентрантный (по крайней мере до момента проверки семафора). С программным прерыванием конечно будет проще. Но если его нет, то можно при желании обойтись. Я с такими задачами не сталкивался.

il-2 (Сегодня, 06:51, просмотров: 29) ответил Nikolay_Po на См. в моём ответе Эдуарду:

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

Ответить

- Там ниже еще LightElf пример привел, связанный с приоритетами. Все, теперь врубился до конца. Но текущий приоритет можно снизить (наверное) в NVIC. Если так, то можно обойтись без программных прерываний (подпрограммами). Можно, но сложно :-) - il-2(Сегодня, 07:01)
  - Нет, текущий приоритет (приоритет обрабатываемого в данный момент прерывания) снизить нельзя. Тиритицки (не проверял) можно изменить значение приоритета в NVIC и программно взвести (через NVIC) то же прерывание еще раз. Тогда по выходу из текущего обработчика мы снова перезайдем в тот же обработчик, но уже на новом (более низком) уровне приоритета. Но тогда при наступлении нового события мы не смодем его гарантированно быстро обработать, потому что приоритет уже понижен и LightElf(308 знак., Сегодня, 18:14)
    - Тут: Nikolay_Po(978 знак., Сегодня, 20:45, ссылка)
  - Возможно, существуют задачи, где без "программных прерываний" не обойтись, но я сходу таковых придумать не смог. - Eddy_Em(Сегодня, 09:48)
    - Отлично! Значит, тебе удаётся так продумать структуру программы и разделить её на куски, что защищать секции выполнения поднятием приоритета не приходится. - Nikolay_Po(Сегодня, 11:19)
      - Ну так у меня в случаях, где нужна реакция в пределах миллисекунды, обычно один прогон суперлупа длится куда меньше. Eddy_Em(363 знак., Сегодня, 11:57)
        
        А у меня требуется реакция не дольше чем за 20мкс по паре интерфейсов сразу. Обработка блока данных - намного дольше и должна быть приоритетнее кода пользовательского режима. В принципе, как предположил товарищ il-2, можно не выходя из текущего высокоприоритетного прерывания, после снятия флага запроса прерывания, понизить текущий приоритет выполнения кода, изменив значение BASEPRI и вызвать подпрограмму обработки. Nikolay_Po(69 знак., Сегодня, 13:02)
        
        Сильно сомневаюсь что это сработает, но это на уровне ощущений. Прерывание обрабатывается в Handler Mode, а BASEPRI (насколько я понимаю) влияет только на Thread Mode. - LightElf(Сегодня, 18:37)
        
        Хмм... Жаль, меня пока не интересует ARM, на данный момент работаю с RISC-V QingKe4F от WCH. Nikolay_Po(211 знак., Сегодня, 20:58)

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