А как флаги делать в 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, и не в пользу последней. А вы?

Для Кейла это как раз Minimal.
Ну и потом: под задачу RTX требует 52 байта + стек. FreeRTOS, если отключить чисто отладочные фишки, 40 байт на задачу плюс стек. Где меньше?
Читаем мануал: Stack size used by RTX kernel is configured in STARTUP.S. Minimum size is 128 bytes, however 256 bytes is recommended when interrupts are used.
То есть RAM Space for Kernel 300 bytes + 128 bytes Main Stack превращается в 300+256, если ориентироваться не на рекламу. Сравниваем с FreeRTOS Typical RAM Requirements 500 bytes и все становится не так однозначно.
Дальше ковырять мне просто лениво. Уверен, со всеми прочими параметрами Keil ровно такая же ерунда. Берется вырожденный случай, никому не нужный, и подается как великое достижение.

Как это "как раз Minimal"? Если стоит знак меньше, то это значит, что больше не будет, а меньше - возможно. Что-то у вас логика не так работает.
И я считать не хочу. Я вижу, что написано, мне достаточно. Причем, я же привел пример урезанной SafeRTOS. А FreeRTOS несколько больше будет, верно?
Меня устраивает Keil, а FreeRTOS не нужна. Я посмотрел бы еще на самое мелкое что-нибудь. Минималист.
А стек задачи - вообще не поддается принудительной установке. У меня из функции в функцию скачет программа, сколько стека выест...? В отладчике вижу в процентах, что весь не съел, вот и хорошо.
Конкретно - от 128 до 320 байтов, 5 задач, по умолчанию задал 256 байтов. Включена проверка переполнения, если переполнение наступит, загорится светодиод.

Поздравляю Вас от всей души.
Непонятно только зачем заходить в форум по FreeRTOS, чтобы об этом рассказывать

На сарае написано неприличное слово, но внутри таки лежат дрова.

Нет. Зависит от того, какие примитивы будете использовать. Обойдесь функционалом, имеющимся в SafeRTOS - будет также или меньше.

Посчитать не пробовали? Рекомендую, помогает.