scmRTOS: если в одном из процессов "быстрый цикл", то все остальные процессы загибаются Опции

[haker_fox]

Здравствуйте!
Такая вот проблема. Использую ОС scmRTOS на ATmega16. Создано два процесса. Первый: работа с USART, второй - с ЖКИ. Проблема: если во втором процессе применить цикл вида

Код

while(PINB & (1 << KEY0));

, то первый процесс не работает. Если цикл исправить на такой

Код

            while(PINB & (1 << KEY0))
                Sleep(50/OS_SWITCH_TASK);

то все ок. В этом цикле мы ждем нажатия некой кнопки и в это время первый процесс не работает. При нажатии на кнопку (т.е. когда происходит выход из цикла), первый процесс начинает абсолютно нормально работать.
Сложилось впечатление, что если в задаче (процессе) применен бесконечный цикл, то все остальные процессы "падают" до тех пор, пока это цикл не прекратится. Доку перечитал. Не нашел никаких комментариев на эту тему. Сам сообразить, в чем дело, не могу. Прошу помощи у бывалых. Заранее спасибо!
Детали:
МК ATmega16, кварц 16MHz
Время тика ОС 4.096 мс (TCCR0 = 0x04;)
Версия ОС 1.10
Компилятор WinAVR 20060421

На всякий случай прикладываю некоторые файлы своего проекта.

Прикрепленные файлы

 WAKE_RTOS.rar ( 45.6 килобайт ) Кол-во скачиваний: 92

 

[amusin]

"cпустя минут 10 после запуска все накрылось."

Посмотрел ваш код, вложенный в первое сообщение.
В задаче TUserLoop после выхода из цикла while счетчик команд попадет в новый цикл - for (;;) и из него уже не выйдет. Причем, т.к. вы установили приоритет этой задачи выше, чем у задачи обработки пакета по uart, то последняя не получит управление, если внутри методов класса Lcd нет вызовов системных методов.

В scmRTOS вызовом sleep (wait etc) вы позволяете ("разрешаете") менее приоритетным _задачам_ сделать их работу. Планировщик, если надо, отберет у задачи управление и без ее "разрешения".
В кооперативных ОС вызовом sleep (wait etc) вы отдаете управление _планировщику_, без этого перепланирование невозможно.

PS. Заметил, что вы шлете каждый принятый символ в задачу. Этот подход вполне "законен", но не лучший. На каждый принятый символ производится вызов шедулера, время работы которого измеряется десятками микросекунд. При высоких скоростях обмена по uart процессор только и будет заниматься тем, что "щелкать" контекстом. Поэтому, для уменьшения расходов времени на перепланирование, следует принимать пакет в буфер в ОЗУ, а по окончании приема - семафорить в задачу или посылать ей указатель на принятое сообщение (если есть очередь сообщений). Разгребать пакет в задаче.
Насколько я понял, у вас протокол wake. Так вот, протокол уровня serial line (байт-стаффинг, фрейминг) разумно перенести в ISR приема по uart, а разбор команды (если она принята корректно) вести в задаче.

Сообщение отредактировал amusin - Dec 13 2006, 14:38

[IgorKossak]

... На каждый принятый символ производится вызов шедулера, время работы которого измеряется десятками микросекунд. ...

При частоте кварца 8МГц - примерно 14мкс.
Не так уж и много.