I see the following content in the manual, are these two paragraphs contradictory? Manual P365 If there are to be multiple different writers then the application writer must place each call to a writing API function (such as xStreamBufferSend()) inside a critical section and use a send block time of 0. Manual P59 FreeRTOS API functions must not be called from within a critical section.

Both those statements are in my mind a bit simplified. First, Streambuffers don’t need a critical section, but do need some form of protection that you NEVER have multiple tasks trying to read or write the buffer at a given time. A critical section is one simple way to do this, having a Mutex protect the access should also work (and that gets around the need for 0 block time. Second, the limitiation isn’t so much that they can’t be called from a critical section, but that no FreeRTOS API call should block or attempt to change the running task inside a critical section. (some ports actually don’t have a problem with it, but some do).

First ,thank you much! But before that, I used Mutex protected, but every time I call the function (such as StreambufferSend) very slow, almost once every second. So i check the manual .

What is it you are trying to do? Stream buffers are designed to have one reader, and one writer. If you use them in that scenario then you don’t need any protection. If you want to go outside of their intended use then consider a queue instead, but with some understanding, you may be able to have multiple readers or multiple writers with a critical section or a semaphore, but you must then never attempt to block on the stream buffer (hence comment about having a block time of 0). If you lock a semaphore and then block, the semaphore will remain locked. If you enter a critical section and then attempt to block, you won’t switch to another task, and your application will have run-time logic errors (task that is technically in the blocked state is still actually running).

OK, I have know it, thank you.