FreeRTOS for Atmel's SAM Cortex-M3 Switch between tasks

Question

I'm playing with FreeRTOS on an Atmels' Cortex-M3 mcu and I was wondering how can I switch from a current task to another irrespective of its priority. To be exact: I send data to one of mcu's USART port. I have enabled the RX interrupt and I wrote the appropriate UART_Handler. The handler fills a buffer one by one byte. When the handler reads '\n' I want to call the task which prints this buffer. How can I do this? I tried with taskYIELD but nothing worked. Any hint with this?

EDIT: I forgot to mention that I'm new in RTOS development. I haven't tried it before.

Answer 1

Send the task a signal, or notification, as FreeRTOS calls then.

But, you most likely wrote some interrupt layer now. You probably use queues or buffers to send the data to the task. Your task can also wait for the queue to contain data.
The queue code will contain the necessary flags to set the task pending.

Yield is something else in OS context. It basically means the task ends its given cpu time-slice early. So the next task is switched in. But this could very well be the same task if the design is poor.

Answer 2

You need to think about your task design. You said you have a task that prints and apparently you have another task the you're calling yield from. What is the purpose of this other task? When should each task run and when should each block? What should the relative priorities of the tasks be?

I'll take a guess based on almost no information. The printing task should run only when there is something to print otherwise it should block. The other task should run all the rest of the time, perhaps it is the idle or background task. In this case the background task should be low priority and the printing task should be higher priority so that the printing task can preempt the background task when there is something to print.

Use something like a semaphore or queue to signal when the printing task should run. If you've already built your own character buffer mechanism and the interrupt handler is checking for '\n' then a semaphore is probably good. The printing task should get/pend/block on the semaphore. The interrupt handler should set/post the semaphore when '\n' is received. Then the printing task will run and print the buffer.

Another design might be that when the interrupt handler gets the '\n' it sends the entire buffer to the printing task via a mailbox or queue. This would decouple the printing task from having to read/manipulate your buffer data structure.

Another design might be that the interrupt handler posts every character to a queue and the printing task pends on the queue and buffers characters itself until a '\n' is received. This would decouple the interrupt handler from the job of interpreting characters such as '\n'.