Is there any chance that FRT will support event flags? I mean something like this #define SERIAL_DONE 0x01 #define ETHERNET_DONE 0x02 #define I2C_DONE 0x04 Flag EventFlag EventFlag = createEventFlag(); //task1 for(;;) {   eventWait(EventFlag, SERIAL_DONE + ETHERNET_DONE, falseClearFlags,);   /*   some stuff */ } //task2 for(;;) {   eventWait(EventFlag, I2C_DONE + ETHERNET_DONE, trueClearFlags,);   /*   some stuff */ } I believe this can be accomplished by combination of semaphores…however this form clear and simply understandable.

Event flags – hmm. This is something we have discussed several times here.  To recap in as fewer words as possible (difficult for me ;o) the problem with event flags is the effect they have on system responsiveness.  I have not yet come up with a fully featured implementation that does not require loops within critical sections – which is something FreeRTOS.org tries to avoid. Having said that I have talked to lots of people about event flags and it is clear that different people have very different definitions, some of which are more difficult to implement than others. I was thinking an event flag was a variable in which each bit represents an event.  Any number of tasks can pend on any combination of events.  So an event occurring would require each task that was pended on that event to be inspected to see if the bit combination was correct for the task to be unblocked.  The inspection could require lots of ORing and ANDing, and a loop through each pended task. It would be good to get other definitions.  Simpler implementations with less functionality might well be very possible without affecting system responsiveness. Regards.

Hi all. Hi Richard. I think that something that can be useful like event flags could be a implementation of customizable sockets in freertos. Richard… i’m thinking something like socket implementation in LWIP stack… My dream is the possibility to use a select function for EVENTS from some FreeRtos tasks AND network socket event… I know that it could be a difficoult job (i can try to give my contribution…) I think that if will be a general customizable socket in freertos, i will can to replace socket in lwip using a particular implementation (based on NetConn… as actual socket do… right Richard?) … i know… this post could be OOT….. but… i posted it only for opening a discussion! :O) Bye, Piero

Yes, you are right. I am now more familiar with search and I realized that FRT should be easy portable to the other microcontrollers than e.g. CortexM3. However I like events as are implemented in MicroC. I wanted only know … because maintain from kernel developer is better than checking new releases, studying important changes and patch. Thanks for reply

Hi Richard. I’m studying for my application, based on freertos+lwip stack, a method for tasks data exchange based on local loop available in lwip. This method will have an overhead on packet (i have to use udp or tcp) and on time (all packets are dispatched by a lwip core task and some additional code will be executed) BUT it could be possible to implement something like stream and MULTI IO SYNCHRONIZATION, using select function For application which needs networking, it could be an alternative method than queue, with the possibility to have MULTI IO SYNCHRONIZATION (some people asks for waiting_on_multiple_queue or waiting_on_events) It could be possible copy this implementation from lwip, simplify it and put it in freertos core (using scheduler as dispatcher) if lwip will be not available in application I want discuss with you about this, if you are interested you can write to me: pweb DOT ing AT gmail DOT com Bye, Piero

Hi Richard I want to add another post in this discussion. I remember another discussion here about WAIT on MULTIPLE Q (in two different way, OR of queue events or AND of queue events). I think that it could be an interesting features, and a possibility for have Event Flags: as the philosophy in freertos, all i based on queue; so, event flags could be a particular case of multiple queue. What do you think? PS: i want to try to understand to freertos kernel code in deep…. so, after, i hope to give some contribution for the future releases. Bye, Piero

I know this is a long dead thread, but I’ll give my two cents anyways (referring to msg https://sourceforge.net/projects/freertos/forums/forum/382005/topic/2284508?message=5322393 ) As you said hmm. But this loop would happen only when one of the events in the event flag occurs, not everytime there is a task switch, so it would not impact system responsiveness in general, it would slow down only the event mechanism. And usually there aren’t so many tasks waiting for the same event list, maybe 3 or 4 at a time. However there is another definition of the event flags (and easier to implement) would be this: There are no combination of evetns, and they do not actually hold any value (set or unset). But at any time the event “occurs”, all tasks waiting for it unblock. for example let the event be the arrival of a CAN Message.
Usually this message should be processed by only one thread, but sometimes more than one thread needs it. So in most cases only 1 thread is waiting on this event, but sometimes both.
When the Interrupt occurs, and the event is given a “push”, the threads waiting for it unblock, and first the one with the higher priority runs, and after that the one with lower priority. I Don’t think it would be very complex to implement, you actually need a list of the tasks waiting for the specific event. When a thread starts waiting it is put into blocked state and when the event is given a push, it is unblocked and put in runnable state. Is there any possibility for this to be implemented and integrated into FreeRTOS? Regards,
  Ákos Vandra

Note that for both definitions of “event”, it is actually possible to create a wrapper around the existing primitives to create the functionality, as long as you can change both ends of the current communication (and if the event was a new type of structure, you would need to do this anyway). To create the “event” that one signal may start multiple tasks, all you need to do is make the sending task signal multiple semaphores, and each task waits on its own, and possible add that when it goes to wait, it first “clears” the semaphore with a 0 delay wait so that it will wait for the next signal. If you don’t want to hard code which events to signal, you can create a generic version which builds a list of semaphores, with a function to signal all semaphores on the list. For the wait for one of a multiple queues, you can create an extra semaphore which you signal when any of the queue has something put on it (or removed if you are going to wait for space on a queue). Again, if you want to make a general version, you can build the appropriate lists which are processed when an “eventable” queue is accessed. There are some details to avoid race conditions that need to be addressed and may require some critical sections, and a wait for multiple queues will need to handle the case that a task waiting on multiple queue might get woken for data being available, but by the time it goes to actually get the data, it is gone (to some other task) and it might need to go back to the wait again.

I have an event task. A task triggering an event sends a message to events input queue, the event task -re-sends the event to the tasks waiting for events. This is trivial to code and works, but not very efficient. Fortunately, my application (user interface) is not very performance-critical.