Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Организация асинхронных вычислительных процессов
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
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
Цитата(MrYuran @ May 12 2010, 09:20) *
Посмотрите доку на scmRTOS, очень толково написано.

Угу, спасибо, углубился в изучение
AlexOr
Цитата(alvol @ May 12 2010, 09:37) *
Как-то возможностей конечного автомата--уже мало


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

ЗЫ%
Вы не любите собак?! Да Вы просто не умеете их готовить....
ukpyr
Цитата
Один знакомый программер высокого уровня как то сказал примерно следующее: На КА можно сделать все и гораздо проще, чем на ОС, только надо немного иначе мыслить.
это в случае небольшого количества задач и состояний. Если их много, программа превращается в трудноподдерживаемую мешанину из switch/case, обработки таймеров и т.д.
MrYuran
Цитата(AlexOr @ May 31 2010, 08:56) *
Один знакомый программер как то сказал ...

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

Да и вообще, интересно глянуть на вытесняющую многозадачку с приоритетами, реализованную "напрямую".
Фактически, та же операционка и получится, только недокументированная, с потенциальными глюками и без поддержки.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.