[juvf 17]

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

 

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

[aaarrr 69]

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

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

[juvf 17]

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

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

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

[aaarrr 69]

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

[Grape 0]

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

[aaarrr 69]

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

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

[juvf 17]

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

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

 

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

 

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

[RCray 0]

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

[kovalio 0]

эту старую тему нашёл поиском, т.к. тоже озадачился вопросом использования флагов в программе.

оказывается, Event Bits (or flags) and Event Groups: Available From FreeRTOS V8.0.0

 

[gridinp 3]

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

Функции: xQueueCreateSet, xQueueAddToSet, xQueueSelectFromSet

[ViKo 1]

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

[LightElf 0]

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

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

[ViKo 1]

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.

[LightElf 0]

Keil CMSIS-RTOS:

Code Space < 5.0 Kbytes

RAM Space for Kernel 300 bytes + 128 bytes Main Stack

RAM Space for a Thread StackSize + 52 bytes

 

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 очевидна, не так ли?

[ViKo 1]

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

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