kg7hf wrote on Monday, December 18, 2017:

I may have something configured wrong, but it appears that certain stream buffer functions require notifications. This normally isn’t a problem since you can just not have stream_buffer.c in the compilation. Where it becomes an issues in in mpu_wrappers.c when MPU_xStreamBufferSend() and MPU_xStreamBufferSendFromISR(). It seems that maybe these stream_buffer functions should be wrapped with a configuration of some sort so to not be included in the build if notifications are not supported.

Error: no definition for “xTaskNotifyStateClear” [referenced from function _xStreamBufferSend …\stream_buffer.o]
Error: no definition for “xTaskNotifyWait” [referenced from function _xStreamBufferSend …\stream_buffer.o]
Error: no definition for “xTaskGenericNotify” [referenced from _xStreamBufferSend …\stream_buffer.o]
Error: no definition for "xTaskGenericNotifyFromISR [referenced from _xStreamBufferSendFromISR …\stream_buffer.o]

Again, I could potentially have something configured incorrectly on my end. I’ve built on two different compilers and two different target devices with the same result though.


rtel wrote on Monday, December 18, 2017:

I have added the following to stream_buffer.c:

#if( configUSE_TASK_NOTIFICATIONS != 1 )
     #error configUSE_TASK_NOTIFICATIONS must be set to 1 to build 

and at the moment I think stream_buffer.c needs to be built in order to
use the MPU port, just like event_group.c needs to be built in order to
use the MPU port - unless you set your linker to remove unused symbols.

kg7hf wrote on Tuesday, December 19, 2017:

Hi Richard,
Thanks for confirming this for me. yes, both seem to need to be built, but I don’t see they are explicitly needed for MPU support. I think a better long term fix would be to create a new config, something like configUSE_STREAM_BUFFERS and configUSE_EVENT_GROUPS, although the event groups didn’t give me any build troubles like the stream buffers did,

rtel wrote on Tuesday, December 19, 2017:

The idea with the stream buffers was that if you wanted to use them you
just included the file, rather than having to set a #define. Similar to
when you use the software timers, you include the timers.c file.
However when you use timers you do also have to set the configUSE_TIMERS
constant to 1 (or whatever the constant’s name is, might have that
wrong). I will consider doing the same for stream buffers, but I’m not
sure about it as, unlike with timers, there is nothing inside the kernel
itself (tasks.c) that needs to be different if stream buffers are used.
When software timers are used the kernel needs to know to create the
timer task.

dragonflight1 wrote on Thursday, January 31, 2019:

I realize this is an old post, and given no one else has commented …, but I would like to add a vote to making stream buffers guarded by configUSE_xxx
I have lots of FreeRTOS projects (>20 including old ones) and after many attempts at various mechanisms for managing them all I have settled on common directories for the various versions I use, and so it really makes sense to just have FreeRTOSConfig.h select what I use for each project.

Of course it is simple enough for me to add the guarding (which I have done), but it makes sense to me that this would be generally useful