cancel
Showing results for 
Search instead for 
Did you mean: 

StreamBuffers in AzureRTOS

Davide Dalfra
Associate III

Hi Folks

I am doing some test to see if it worth to start using AzureRTOS on a new system we're going to develop.

I have a serial stream coming from a device (RTCM stream) that need to be read by a MCU and then sent over a UDP stream.

The UDP/Net part is (almost ok), while i'm struggling a bit to port a uart manager i wrote in the past for FreeRTOS.

The uart from the device is a bit tricky and i receive frequently fragmented packet that need to be reassembled to be correctly decoded by a parser.

With FreeRTOS i used to do that with stream-buffers or queues , where UART DMA RX isr pushes in half and cplt events the received bytes on the streambuffer (or queue).

If the amount of received bytes was not hit by the half or cplt event i have a last-byte timeout timer that when triggered just push the remaining bytes on the same streambuffer.

As example, the uart receiveve was launched with size=64 in circular mode.

Every half or cpltd events 32 bytes was sent to the streambuffer, and let's say that if 6 byte was received , those 6 were sent to the streambuffer after 10ms (last_byte_timeout, managed by checking dma rx counters).

I tried the queue approach on AzureRTOS but unfortunately the queue element size seems to be maximum 16 bytes which can't be used for my purpose.

I do see some post on MS KB that are talking about passing reference by pointer but this would means adding another abstraction layer to the system.

Does in AZ RTOS exist something similar to StreamBuffers or a way to use queues with a higher element size?

Thanks

Davide

10 REPLIES 10

Hi Davide,

yours is an interesting ideas. In the past, working also with FreeRTOS, I had different use cases where I need to exchange messages bigger than 64 bytes. If your API are generic it will be interesting to give a look, maybe integrate it in a application framework. 

Another thing that make me curious is when you write "cmsis-os api based". It is not clear to me if you are using CMSIS-OS in your project, and, if yes, why?

In any case, it is nice to read that you fix your issue and your are moving forward with STM32 ;)

Best regards,

Stefano