caxapa.ru :: А у меня требуется реакция не дольше чем за 20мкс по паре интерфейсов сразу. Обработка блока данных - намного дольше и должна быть приоритетнее кода пользовательского режима. В принципе, как предположил товарищ il-2, можно не выходя из текущего высокоприоритетного прерывания, после снятия флага запроса прерывания, понизить текущий приоритет выполнения кода, изменив значение BASEPRI и вызвать подпрограмму обработки.

Nikolay_Po (Вчера, 13:02, просмотров: 69) ответил Eddy_Em на Ну так у меня в случаях, где нужна реакция в пределах миллисекунды, обычно один прогон суперлупа длится куда меньше.

А у меня требуется реакция не дольше чем за 20мкс по паре интерфейсов сразу. Обработка блока данных - намного дольше и должна быть приоритетнее кода пользовательского режима. В принципе, как предположил товарищ il-2, можно не выходя из текущего высокоприоритетного прерывания, после снятия флага запроса прерывания, понизить текущий приоритет выполнения кода, изменив значение BASEPRI и вызвать подпрограмму обработки.

Будет даже компактнее и быстрее. Спасибо за идею. При случае применю.

Ответить

- Сильно сомневаюсь что это сработает, но это на уровне ощущений. Прерывание обрабатывается в Handler Mode, а BASEPRI (насколько я понимаю) влияет только на Thread Mode. - LightElf(Вчера, 18:37)
  - Хмм... Жаль, меня пока не интересует ARM, на данный момент работаю с RISC-V QingKe4F от WCH. Nikolay_Po(211 знак., Вчера, 20:58)
    - Про RISC-V ничего сказать не могу. У ARM регистр BASEPRI позволяет запретить более приоритетные прерывания, но не позволяет разрешить менее приоритетные. Выше писал, что, по отзывам, вроде бы можно понизить приоритет текущему прерыванию, но в доке ARM это отдельным пунктом не рекомендуется делать. - LightElf(Сегодня, 00:40)

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