Keil RTX-kernel и прием/передача по UART, Как лучше организовать взаимодействие? Опции

[Shein]

Доброго времени суток!
Есть проект с использованием RTX-kernel. Нужно организовать прием/передачу данных по UART. Т.к. скорости маленькие 4800/9600, то хочется снизить время бесполезного простоя системы в ожидании готовности приемника или передатчика - есть масса другой работы по обработке данных. Вот раздумываю как это сделать правильнее, красивее, с точки зрения RTOS.

С приемом, в общем, более-менее понятно. Включены прерывания по приему символа (ПДП пока не используется) и в обработчике принятый символ через mailbox отправляется задаче обрабатывающей прием.

Передачу, на данный момент сделал так:
Разрешил прерывания по готовности передатчика, в обработчике прерывания устанавливается событие "передатчик готов", а уже задача, ответственная за передачу, по этому событию пишет данные в буфер UART'a.
Минусы: обработчик прерывания один. Поэтому, когда нет данных для передачи, но идет прием, обработчик прерывания вызванный приемником, ставит и событие готовности передатчика (бит в статусе USART TXRDY ведь установлен). При этом получается что будет установка уже установленного события. Есть ли тут криминал, не знаю. В доках по этому поводу ничего не нашел.

Рассматривал вариант организации передачи тоже через mailbox. Во-первых мне показалось это излишним усложнением. во-вторых, обработчик прерывания вызывается при освобождении передатчика. А если данные появились позже?

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

В общем, интересно, кто какие подходы использует?

Не думаю что это имеет значение, но на всякий случай, контроллер AT91SAM7X...

[serbor]

Тоже приценивался к этой операционке. А что она работает только как раунд-робин? Мне показалось, что там есть возможность вытеснения.

[Shein]

Тоже приценивался к этой операционке. А что она работает только как раунд-робин? Мне показалось, что там есть возможность вытеснения.

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

[sinc_func]

В подобной задаче я ориентируюсь на такой вариант
-использование FIFO UARTa (для LPCxxx) должно дать временной буфер где-то в 15-30 ms,
что много больше чем типичный tick,
- под обслуживание UARTa выделяется чисто отдельная задача с круговым опросом
статуса UARTa по приему, статуса по передаче и связью с кучей других задач через
выделенный mailbox(ы)...и никаких прерываний,
- такую пробную версию я сделал на Round-Robin-е - впечатление- приятное ..
- при отсутсвии каких-то "шевелений" в статусах этой задачи и необходимости чего-то
"окучивать" - эта задача просто отдает активный статус через os_tsk_pass() другой задаче

Конечно, это простое решение можно покритиковать - но это простое решение

[Shein]

- при отсутсвии каких-то "шевелений" в статусах этой задачи и необходимости чего-то
"окучивать" - эта задача просто отдает активный статус через os_tsk_pass() другой задаче

The os_tsk_pass function passes control to the next task of the same priority in the ready queue. If there is no task of the same priority in the ready queue, the current task continues and no task switching occurs.

Нсколько я понял из описания, задаче с меньшим приоритетом os_tsk_pass управлени не отдаст. Кто-нить проверял как оно на практике?
Round-robin не пользую.

[sinc_func]

Нсколько я понял из описания, задаче с меньшим приоритетом os_tsk_pass управлени не отдаст. Кто-нить проверял как оно на практике?
Round-robin не пользую.

У себя в задачах я ориентируюсь пока только на Round-robin
(не хочется напрягаться и тянуть без должной мотивации систему приоритетов)