Организация асинхронных вычислительных процессов, как лучше организовать это на МК Опции

[alvol]

Добрый день. Есть некоторая задача: работать на МК с модулем, скажем блутус, который имеет свой набор команд (запросы, подтверждения выполнения команды, идентификаторы событий). Кроме всего прочего нужно общаться и с другой периферией(иногда аналогичной ) и выполнять прочие действия.
Суть проблемы: как правильно организовать обработку асинхронных процессов, различных по длительности и при вариативности результата этих действий?
Реализовывал несколько конечных автоматов, в которые входил раз за проход, проверял что изменилось, за нек промежуток времени, реагировал, менял состояния и переходил к следующему конечному автомату.
Теперь этого не хватает. Потому как при работе с модулем накапливается огромное количество всевозможных состояний, различных переходов от состояния к состоянию и приходится реагировать на события, которые накапливаются параллельно (скажем опрос окружения, работа с несколькими конечными точками), отдавать запросы и ожидать подтверждений в несколько этапов.
Как-то возможностей конечного автомата--уже мало (слишком много состояний и большая вариативность возможных вариантов развития), а про организацию простых операционных систем--пока не имею представления.
Возможно кто-то натолкнет на правильные идеи? На что нужно обратить внимание при организации подобных программ?

[_Pasha]

Почему-то мне кажется, что Ваша задача на 100% решается простейшей кооперативной многозадачкой. Protothreads
Модифицировать ее можно таким образом, чтобы все сопрограммы выполнялмсь внутри одной функции. Пример для GCC

Код

void *thread1(void *pc);
//..................................
void *threadN(void *pc);
void idle(void)
{
do{ static void *pc=NULL; pc = thread1(pc);}while(0);
//..............................................................................
do{ static void *pc=NULL; pc = threadN(pc);}while(0);
}

Для исключения рекурсивного вызова сопрограммы надо предусмотреть ее блокировку. Тогда у Вас появится возможность в циклах ожидания вызывать эту idle() - стек расходуется, но это уже разумный компромисс.
В общем, чем более бедненький МК, тем больше преимуществ у Protothreads