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

[hound]

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

Код

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

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

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

[Bulya]

Таск имеет один поток выполнения.
Вам требуется либо два потока, либо два состояния.

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

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

Но зачем нужны увечные велосипеды, если можно использовать детерминированные подходы:
- два отдельных потока (если режимы независимы и между ними нужно переключаться, возобновляя прерванную работу);
- машина состояний (если переключение режима должно полностью прекратить текущую работу).

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