Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Best way to implement generic UART drivers?

Posted by Lars Ole Pontoppidan on July 2, 2009
Hello FreeRTOS forum!

I am in the process of designing a platform using FreeRTOS, and I am scratching my head about how to best implement the serial communication.

There are going to be as many as five UARTs live, and potentially communicating simultaneously. The baud rates are however not very high, typically 9600 baud, but I would like to have the opportunity to go faster one day. The chip is a HCS12XET256 with cpu clock = 73.7 MHz and 8 KB ram (without paging), and most time will be spend waiting for activity on UART(s).

I would like to have a modular design, such that I can hook my high level drivers to any of the UARTs.

My first thought was to simply implement the lowlevel UART drivers with FreeRTOS message queues. That would mean five transmit queues, and five receive queues that simply transfers the data bytes directly. I would get deferred processing and UART abstraction out of the box with minimum effort.

But then I read in the FreeRTOS book on page 89 that "passing individual characters through a queue is extremely inefficient ... and not recommended for production code" and I began thinking about other ways to implement the lowlevel driver.

In any case I need to have a buffer that the receive ISR can dump bytes in. And, in any case, I need to make the ISR let other tasks know that there is fresh data in the buffer. So if I roll my own receive buffer and use a semaphore for signalling (which is a minimal message queue), am I not back to the same amount of overhead as the original message queue idea?

Any comments would be appreciated :)

Best regards,
Lars

RE: Best way to implement generic UART driver

Posted by Richard on July 2, 2009
I'm not sure what is available on your HCS12, but an efficient way would be to have a DMA pass data to and from the UART and a circular buffer. Then have the DMA interrupt use a semaphore to unblock tasks when there is enough data to make it worth processing. If no DMA is present then hopefully there are at least some FIFOs.

The best approach to take is naturally dependent on the characteristics of your application, these are just suggestions.

Regards.

RE: Best way to implement generic UART drivers?

Posted by captnskydiver on July 8, 2009
I'm trying to use FreeRTOS port for PIC18F devices for past couple of weeks now. PIC18F65J50 has two UART's and code I wrote for low and high level drivers works with no problems on 19200 on both ports using queues in two stages.
First stage writes/reads single characters from Tx/Rx ISR to queue.
Second stage writes/reads strings (ended with CR/LF or just CR) from one queue to corresponding queue on the first stage.
One ISR and two separate tasks for handling asynchronous serial communication works fine on PIC18F with 48MHz internal clock (12MIPS).

Besides this there is USB driver task, IO processing task and work dispatcher task that coordinates everything. It works.

The only thing that really slows down development are some FreeRTOS internal "bugs" probably related to PIC port, i.e. taskYIELD not working, timeout in queuesend and queuereceive not working etc.

I have lost a lot of time assuming these, and some other things, work as expected.

Anyway, I might post code for UART driver when I get time, best thing is that it is not platform specific (except in 3-4 lines of code) since it relies entirely on FreeRTOS architecture.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner