Как стать автором
Обновить

Комментарии 9

С этого момента "… А именно это и требуется для того, чтобы не пытаться срочно поднимать задачу, для которой только что случилось прерывание,… " можно дальше не читать.
Вот это по-нашему, по-большевистски: «Не читал, но осуждаю».
У STM32 есть прекрасный модуль прерываний NVIC. Этот модуль позволяет создать многозадачность с 16 уровнями приоритета, сами прерывания могут быть вложенными на все 16 уровней, и это прекрасно решает вашу задачу, еще и ресурсов ядра на планировщик не тратит.
Я Вам скажу больше. Можно сделать даже 128 уровней прерывания. Для этого есть
системный регистр AIRCR. Только не совсем понятно, зачем запихивать весь функционал в обработчики прерываний. Через три месяца я такой код сам перестану понимать.
Я часто практикую следующий метод:
  • в main команда " в сон";
  • вся логика в прерываниях от более чем 50 линий.

Звучит страшно, да. Однако на деле, при правильном подходе, выходит достаточно компактно и красиво. Главное красиво описать конечный автомат.
Конечно, если аккуратно делать и не пытаться нарушить законы физики, то
все получится. Но, иногда хочется написать так, чтобы еще раз можно было
использовать, когда время подожмет.
Ассемблерные куски, например, если предварительно не описать красиво (когда самому нравится) в виде блок-схемы, то отлаживать очень трудно.
Но, что не сделаешь ради любопытства.
Полезные идеи!..
Может CTM32 не тот процессор на котором потребуются подобные решения, но на МК более низкого уровня подобная реализация «Многозадачности» выглядит хорошим решением. Сам нечто подобное придумывал для ассемблерных программ на PIC микроконтроллерах младшего семейства. Очень помогало создавать решения, требовательные к временным параметрам.
Инструкции Cortex-M как раз для этого очень удобные и мощные. Чего стоит только автоматическое сохранение части регистров в стек при прерывании!
Обычно прерывания для обслуживания задач «строгого» точного времени: считать с входного буфера в кеш или передать из кеша в интерфейс.
Для задач «мягкого» режима всегда удобнее отложенное обслуживание в пределах допустимой реакции на события.
При таком распределении и овцы целы и… можно применять хоть цикл задач, хоть какую-то ОС.
Хотя вторая удобнее: гибче назначаются, изменяются приоритеты и легче разбивать код на не пересекающиеся подзадачи. В этом режиме затраты на переключение и обслуживание часто ничтожны с возможностью сопровождения и повторного использования участков кода в других проектах. На современных ARM микроконтроллерах (даже на M0 младших серий) времени на решения этих задач обычно с избытком, так что извертываться с оптимизацией кода под конкретную задачу имеет смысл если она влияет на работоспособность изделия (меньше потребление например или критические реакции) или когда затраты на такую оптимизацию дадут прирост в чем-то по равнению с временем потраченным на оптимизацию.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории