TNKernel переход в другую часть таска Опции

[hound]

Добрый день, есть таск для работы с некоторым внешним устройством.
Устройство общается с МК по юарту, данные в прерывании складываются в буфер и очередьми отправляется в этот таск.
В таксе есть основной бесконечный цикл, в котором по очереди выполняются разные функции.
Т.е, грубо говоря:

Код

while (1) {
  func_1();
  func_2();
  func_3();
  func_4();
  func_5();  
}

Время выполнения каждой функции разное, примерно от 100мс до 1 сек.

Но само устройство может перейти в другой режим работы, для которого нужно будет выполнять уже другие функции. И устройство может перейти в этот режим в любой момент.
Когда устройство переходит в другой режим оно отправляет определенное сообщение МК. Это сообщение отлавливается в прерывании и дальше уже нужно заставить таск выйти из этого цикла и перейти в другой. Каким способ лучше подобное реализовать?
Проверка на наличии сообщения о переходе в другой режим при проверки очереди в каждой функции не вариант, т.к функций в основном цикле может быть намного больше и каждый раз делать проверку кажется лишним.

[hound]

Переход в другую задачу еще не совсем вариант, потому что это в этом "другом режиме работы" нужно девайсу отправить буквально одну команду.
Идеальным вариантом было бы при получении в прерывании уведомления о этом режиме, например, выставлять флаг и запускать сразу следующую итерацию цикла.
Перезапуск основной задачи тоже не вариант, т.к в начале этой задачи идет инициализация этого устройства и его первая перезагрузка, что в "разгаре" работы нельзя делать.

[Bulya]

Переход в другую задачу еще не совсем вариант, потому что это в этом "другом режиме работы" нужно девайсу отправить буквально одну команду.

Если нужно отправить одну команду и вернуться в основной режим, то нужно просто синхронно выполнить одну функцию с отправкой этой команды.
Но за "буквально" могут скрываться неприятные нюансы.

Идеальным вариантом было бы при получении в прерывании уведомления о этом режиме, например, выставлять флаг и запускать сразу следующую итерацию цикла.

Для того, чтобы при получении определенного сообщения завершить текущую итерацию, стек функций от корня итерации до чтения этого сообщения должен поддерживать код возврата, который обрабатывается как и любая нештатная ситуация и приводит к досрочному завершению текущей операции.

Сложно что-то советовать когда непонятны критерии выбора решения.
К чему такая экономия на задачах? Не хватает памяти? (При том, что судя по всему требуемый объем стека небольшой и легко прогнозируем.)

Если итерацию основного режима все-равно нужно прервать, то в ней так или иначе необходима обработка исключений.
А значит переключение режима должно эскалироваться как любая ошибка и приводить к началу новой итерации.
И там в самом начале итерации должен проверяться какой-то флаг и обрабатываться "другой режим".

А вообще нужно просто организовать задачу в виде стейт-машины. И все переключения режимов сразу станут штатными ситуациями.

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