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

[alvol]

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

[Dima_G]

RTOS?

[MrYuran]

Посмотрите доку на scmRTOS, очень толково написано. А потом, попробовав немного, можно уже определяться.
FreeRTOS помощнее, там можно комбинировать вытесняющую и кооперативную многозадачность. Но и жрёт побольше.

[_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

[alvol]

Посмотрите доку на scmRTOS, очень толково написано.

Угу, спасибо, углубился в изучение

[AlexOr]

Как-то возможностей конечного автомата--уже мало

А точно, что Вы умеете их делать (готовить)?
Один знакомый программер высокого уровня как то сказал примерно следующее:
На КА можно сделать все и гораздо проще, чем на ОС, только надо немного иначе мыслить.

ЗЫ%
Вы не любите собак?! Да Вы просто не умеете их готовить....

[ukpyr]

Один знакомый программер высокого уровня как то сказал примерно следующее: На КА можно сделать все и гораздо проще, чем на ОС, только надо немного иначе мыслить.

это в случае небольшого количества задач и состояний. Если их много, программа превращается в трудноподдерживаемую мешанину из switch/case, обработки таймеров и т.д.

[MrYuran]

Один знакомый программер как то сказал ...

Сильно зависит от задачи.
Операционка включает в себя обычно не только планировщик, но и некоторые средства межпроцессного взаимодействия типа эвентов, сообщений, очередей, мутексов и др.
Воспроизвести всё это в виде "рассыпухи" непросто.
Да и Sleep(), к примеру, или WaitForEvent() выглядит намного нагляднее нагромождения таймеров и проверок флагов

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