А как флаги делать в FreeRTOS? Например один поток после определённых действий выставил флаг, второй читает. Если флаг выставлен в "1", то второй поток выполняет действие, потом опять проверяет флаг, если в 1, то ещё раз действие и т.д.

В FreeRTOS не нашел флагов. можно с помощью костыля флаг в фрииртос организовать..... завести глобальную переменную типа bool и оградить к ней доступ через мютекс. А можно как-то по проще и элегантней это сделать?

А какой смысл в mutex'е? Заведите volatile-переменную, и пользуйтесь ей как флагом.

наверно можно и так.... операции чтение и запись - атомарные. но только каждый флаг будет в отдельной переменной. ......
просто портирую с uC/OS в FreeRTOS. в микроси есть флаги. Один поток в нужный момент выставляет флаги, 2-ой поток ждёт когда встанут(сбросятся) нужные флаги, т.е. 2-ой поток будет находится в блокированном состоянии до того, пока флаги не установятся. С volatile-переменной придется как-то в вайле с паузой проверять эту(эти) переменную(ные). или в отдельном потоке организовать проверку флагов и высылку события...... чё-то как-то всё сложно

Используйте семафоры и очереди, если нужно ожидать события.

а если нужно ждать несколько событий (флагов)?

Все равно очередь, просто с несколькими источниками.

там где при получении флага нужно его сбросить, так и делаю. но, чем отличается флаг от семафора? тем что один поток один раз выставляет флаг, а второй получая его может сбросить, а может не изменять.

получатель флага крутится в своем вайле, ждет флаг в блокировке. другой поток единожды выставил флаг, т.е. грубо говоря выставил "1" на порт EnabledTransmit, второй поток увидел что флаг стоит, т.е. ему разрешили работу и вышел из блокированного состояния. выполнил работу, проверил ещё раз флаг, ага, всё ещё стоит, значит ещё раз выполню работу. И так 2-ой поток выполняет одну и туже задачу до тех пор, пока первый поток не сбросит флаг в ноль.

В freertos есть подобие флагов - это двоичный семафор. Но второй поток прочитает его один раз и семафор(флаг) сбросится. Можно ли в freertos захватить семафор не уничтожая его в очереди? Бывает что один флаг ждут 2 потока. Если делать на семафорах придётся 2 семафора заводить.

xQueueReceive удаляет элемент из очереди, а xQueuePeek — нет.

эту старую тему нашёл поиском, т.к. тоже озадачился вопросом использования флагов в программе.
оказывается, Event Bits (or flags) and Event Groups: Available From FreeRTOS V8.0.0

Чтобы ожидать несколько событий сразу, надо объединить очереди, это есть и в v 7.*
Функции: xQueueCreateSet, xQueueAddToSet, xQueueSelectFromSet

Удивляюсь, что в такой распиаренной монстрообразной ОС до 8-й версии не было событий (флагов). Вот в Кейл РТОС - всегда были.

Упс. А что в ней монстрообразного? Наоборот, она очень маленькая. Флагов не было потому, что они не так уж и нужны. В SafeRTOS вообще кроме очередей ничего нет - и никто не плачет.

Keil CMSIS-RTOS:

Description Limitations

Defined Tasks Unlimited
Active Threads 250 max
Mailboxes Unlimited
Semaphores Unlimited
Mutexes Unlimited
Signals 16 per thread
Timer Callbacks Unlimited
Code Space < 5.0 Kbytes
RAM Space for Kernel 300 bytes + 128 bytes Main Stack
RAM Space for a Thread StackSize + 52 bytes
RAM Space for a Mailbox MaxMessages * 4 + 16 bytes
RAM Space for a Semaphore 8 bytes
RAM Space for a Mutex 12 bytes
RAM Space for a User Timer 20 bytes
Hardware Requirements SysTick timer or other hardware timer
Thread context switch time < 2.6 usec @ 72 MHz
Interrupt lockout time Not disabled

SafeRTOS http://www.highintegritysystems.com/safertos/rtos-features/

Typical ROM Requirements 6-15kB.
Typical RAM Requirements 500 bytes.
Typical Stack Requirements 400 bytes/task.

Разница между Minimal и Typical очевидна, не так ли?

Вижу только разницу между Maximal и Typical, и не в пользу последней. А вы?