Quality RTOS & Embedded Software

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


Loading

xStreamBufferSend / xStreamBufferReceive effect on notification values

Posted by asund on January 16, 2018

Hi, I was looking to begin using the new StreamBuffer interface in the future, but the use of xTaskNotifyWait within xStreamBufferSend / xStreamBufferReceive looks problematic for integration with the rest of our system. We use task notifications to set a range of event flags, with the body of most tasks consisting of an infinite loop that blocks forever on a xTaskNotifyWait, followed by testing the bits in the notification value and performing actions if they're set. Sure, we could use global flags instead, but why bother if we have task notifications? Anyways, the stream_buffer.c xTaskNotifyWait calls appear to clear all notification value bits, even though the xTaskNotify calls don't set any bits. I can't really see any downsides to not clearing these bits and preserving this information for other parts of the system to use. Maybe I'm missing something? Sure, there are additional complications to sharing the task notifications this way: I'd probably have to use a loop and xTaskCheckForTimeOut to call xStreamBufferReceive until I have the desired number of bytes just in case one of my other task events were set during a read from a stream buffer, but I already have equivalent code for this in my UART drivers to handle waiting for any number of ISRs to finally receive the number of bytes I'm looking for.


xStreamBufferSend / xStreamBufferReceive effect on notification values

Posted by rtel on January 16, 2018

Are you suggesting having the stream buffers set and clear a single bit, rather than the entire event group. Would that work for you, assuming the bit didn't clash with a bit you were already using?


xStreamBufferSend / xStreamBufferReceive effect on notification values

Posted by asund on January 16, 2018

Hi Richard, thanks for the quick reply. I am suggesting that no bits be used. The implementation currently uses xTaskNotify with eNoAction to unblock the waiting task, conveying this information through ucNotifyState instead of ulNotifiedValue. The blocked tasks, however, call xTaskNotifyWait with a request to clear all bits in ulNotifiedValue on exit. Changing that to not clear any bits would permit the regular use of task notifications alongside stream buffers. As far as I can tell, the exception is eSetValueWithoutOverwrite, which wouldn't work because it uses ucNotifyState which would be modified by the stream buffer, but the others (like my use of eSetBits) would work fine. The stream state is checked again after unblocking, so there'd be no harm in receiving a notification outside of the stream buffer interface.


xStreamBufferSend / xStreamBufferReceive effect on notification values

Posted by rtel on January 16, 2018

Ok - I've made this change, but not checked it in yet as I need to test it and consider any unintended backward compatibility consequences.


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


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

Webinar

"OTA Update Security and Reliability" webinar presented by TI and AWS. Register here.


Careers

FreeRTOS and other embedded software careers at AWS.


Latest News

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.


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

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