Monday, May 21st 2018, 3:27am UTC+2

You are not logged in.

  • Login
  • Register



Date of registration: May 21st 2012

Posts: 39

Location: Pretoria, South Africa

Occupation: Electronic/embedded engineer


Thursday, May 24th 2012, 9:18pm

embOS and serial communication

Hello everyone,

I am very new to using an RTOS, I have been using super loops up to now. I have a question on how how to go about implementing a packet driven communication scheme in an RTOS environment. I need a few pointers to get me going.

I will be using an NXP Cortex-M device, and I am thinking of using either the FIFO or DMA capabilities of the UART. I am uncertain about what the most practical and efficient way will be to handle this process in an RTOS.

My current thinking is to have the UART interrupt once the FIFO is 14/16 full or a time-out occurs, then the interrupt will pass these values to a communication packet processing task. I'm not sure if a queue or a binary semaphore would be the best choice here. This task(or another) will pack these bytes into a buffer and process the packet once the correct amount of bytes has been received and the packet verified using a checksum. The packets will be of a variable size. From here the packet will then need to be processed - a decision made as to what to do, and how to respond to the source of the packet. Should this be another task, or the same task?

Later on, I require to have similar packets also coming in from another UART or USB, and processed in a similar way. So in the near future I will also need to add functionality to handle packets from more than one source, and route packets from one source to the other.

For now I really need some pointers on how to best implement the interrupt routines with the tasks in the RTOS.

Thanks in advance,


Super Moderator

Date of registration: Nov 14th 2007

Posts: 271


Friday, May 25th 2012, 12:12pm

Hello Simon,

the common way is to keep your interrupt routine as short as possible and to do the work in a task.
You could revceive in your Uart interrupt rouine one byte and put it in a mailbox.
A uart receive task could wait for new data from this mailbox. If there is no new data the task is suspended
and comsumes no CPU load. Binary semaphore makes no sense here. You could also use a queue instead
of the mailbox, but the mailbox is faster.

It depends on your application if you want send the complete protocol to another task or to handle
it in the uart receivce task.

Best regards,

Similar threads