caxapa.ru :: Ну так у меня в случаях, где нужна реакция в пределах миллисекунды, обычно один прогон суперлупа длится куда меньше.

Eddy_Em (Сегодня, 11:57, просмотров: 43) ответил Nikolay_Po на Отлично! Значит, тебе удаётся так продумать структуру программы и разделить её на куски, что защищать секции выполнения поднятием приоритета не приходится.

Ну так у меня в случаях, где нужна реакция в пределах миллисекунды, обычно один прогон суперлупа длится куда меньше.

А если в суперлупе могут быть длинные блокирующие операции (скажем, на 1-2мс), разбиваю критическую на части: что-то быстренько в прерывании делается, а остальное уже в суперлупе...

Например, управление 8 шаговиками: в прерываниях таймеров инкрементируется счётчик микрошага и считаются шаги, стоп обрабатывается. А обработка рампов и концевиков - уже в суперлупе.

eddy-em.livejournal.com github.com/eddyem

Ответить

- А у меня требуется реакция не дольше чем за 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 контроллеры