stream_buffer.c

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 streambuffer.c in the compilation. Where it becomes an issues in in mpuwrappers.c when MPUxStreamBufferSend() and MPUxStreamBufferSendFromISR(). 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 ..streambuffer.o] Error: no definition for “xTaskNotifyWait” [referenced from function xStreamBufferSend ..streambuffer.o] Error: no definition for “xTaskGenericNotify” [referenced from xStreamBufferSend ..streambuffer.o] Error: no definition for “xTaskGenericNotifyFromISR [referenced from xStreamBufferSendFromISR ..streambuffer.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. Paul

stream_buffer.c

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 
stream_buffer.c
#endif
and at the moment I think streambuffer.c needs to be built in order to use the MPU port, just like eventgroup.c needs to be built in order to use the MPU port – unless you set your linker to remove unused symbols.

stream_buffer.c

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 configUSESTREAMBUFFERS and configUSEEVENTGROUPS, although the event groups didn’t give me any build troubles like the stream buffers did,

stream_buffer.c

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.

stream_buffer.c

Richard, 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