FreeRTOS v10 and MessageBuffers

Kernel
1

sergiomartin wrote on Wednesday, March 28, 2018:

Hi,
I have ported one of my applications that used FreeRTOS 8 to FreeRTOS 10.
My application used queues but now I want to use MessageBuffers to test them, but when I compile:

unknown type name 'MessageBufferHandle_t'
If I define typedef void * MessageBufferHandle_t; in my app the MessageBuffers functions are not Linked:

undefined reference to 'xMessageBufferReceive'
undefined reference to `xMessageBufferSend'
undefined reference to `xMessageBufferSpacesAvailable'
undefined reference to `xMessageBufferCreate'.

If I compile my old app with FreeRTOS everything works fine, so I think that the FreeRTOS v10 port is fine.

FreeRTOS/include is included. Do I need to include something else to use MessageBuffers?

These are the FreeRTOS compiled files:

FreeRTOS/src/croutine.c
FreeRTOS/src/event_groups.c
FreeRTOS/src/list.c
FreeRTOS/src/port.c
FreeRTOS/src/queue.c
FreeRTOS/src/tasks.c
FreeRTOS/src/heap_2.c
FreeRTOS/src/timers.c
FreeRTOS/src/stream_buffer.c

Do I miss something else?

Do I need to include some define in FreeRTOSConfig.h to enable MessageBuffers?

Thanks

2

sergiomartin wrote on Wednesday, March 28, 2018:

hi,

I forgot to include “message_buffer.h” , just include “stream_buffer.h”

Now the only error occurs linking this function :

 undefined reference to `xMessageBufferSpacesAvailable'

Thanks

3

sergiomartin wrote on Wednesday, March 28, 2018:

Sorry my mistake is `xMessageBufferSpaceAvailable’ without “s” in Space(s)

Thanks

4

rtel wrote on Wednesday, March 28, 2018:

It should only be necessary to build stream_buffer.c, which you appear
to be doing, and then include FreeRTOS.h then message_buffer.h at the
top of the C file that calls the message buffer API - so I’m not sure
why it is not working. Did you copy all the V10 files? Including the
headers and port layers, etc.?

5

sergiomartin wrote on Thursday, March 29, 2018:

hi,

Reading About MessageBuffers:
NOTE: Uniquely among FreeRTOS objects, the stream buffer implementation (so also the message buffer implementation, as message buffers are built on top of stream buffers) assumes there is only one task or interrupt that will write to the buffer (the writer), and only one task or interrupt that will read from the buffer (the reader). It is safe for the writer and reader to be different tasks or interrupts, but, unlike other FreeRTOS objects, it is not safe to have multiple different writers or multiple different readers. If there are to be multiple different writers then the application writer must place each call to a writing API function (such as xMessageBufferSend()) inside a critical section and use a send block time of 0. Likewise, if there are to be multiple different readers then the application writer must place each call to a reading API function (such as xMessageBufferRead()) inside a critical section and use a receive block time of 0.

In my App I can’t dissable interrupts, so I can’t use critical sections I assume that I can use multiple different writers if I protect them with a mutex (only from Tasks not from Interrupts), am I right?

Thanks

6

rtel wrote on Thursday, March 29, 2018:

The main restriction is that only one writer could be blocked waiting
for space to become available at any given time. So if the writers used
a block time of 0, then I think you are good with a mutex. If block
times were non-zero, and more than one writer tried to enter the blocked
state because the message buffer was full, then you would have a problem.

7

sergiomartin wrote on Tuesday, April 03, 2018:

hi,

Is there the possibility of adding messages to the front of the buffer as in the queues (xQueueSendToFront)?

Thanks

8

rtel wrote on Tuesday, April 03, 2018:

Not at the moment. It would be quite a complex addition too as messages can be of different length.