Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

synchronisation 1 to N

Posted by Tomas Novak on November 5, 2009
Hi,
I will need to solve this problem: I will refresh HW (let's say digital imputs) through ISR and than I need to wake up several task, which wait for this refresh. It seems to me, that using mutex/binary semaphor will result in waking up only for 1 (highest) task. Am I right?

Could you suggest me how to solve this?

Tomas Novak

RE: synchronisation 1 to N

Posted by John W. on November 19, 2009
Have you looked aqt the tick hook mechanism?

RE: synchronisation 1 to N

Posted by Alex Svetek on November 19, 2009
I am also looking for a way to implement one-to-many and many-to-one
task synchronization. I guess it could be done with a combination of semaphores and event flags.

I am thinking about how to efficiently integrate event flags in FreeRTOS.
Richard, do you have any plans for this? Is something maybe already in the pipeline?

~Ales

RE: synchronisation 1 to N

Posted by Tomas Novak on November 19, 2009
It seems to me that "tick hook mechanism" is for another purposes. Could You please explain me your suggestion?

Events - that's it! But I think there is no events in FreeRTOS and I do not know any workaround for it. So, what to do?

Tomas


RE: synchronisation 1 to N

Posted by Samuel Tardieu on November 19, 2009
Indeed there are no barriers in FreeRTOS, but barriers can easily be implemented using semaphores and counters.

RE: synchronisation 1 to N

Posted by Richard on November 19, 2009
This is a topic that comes up here from time to time (as does 'timers', which is more appropriate for tick hooks).

There are two problems with talking about 'events':

- First there is no universal definition of what an 'event' is. People normally talk at cross purposes. People from a uCOS background will talk about events in the way uCOS does, but others will mean something completely different. For example, when porting a TCP/IP stack to FreeRTOS I was told it was impossible because FreeRTOS didn't support 'events', but I found during the exercise that they thought an event was simple a way of one task signalling another, or an interrupt signalling a task. All that was needed was a binary semaphore!
- The second problem is, if you do mean events in the same way uCOS does then I have never found an implementation that was suitably efficient for inclusion in FreeRTOS. Nowhere in FreeRTOS are linked lists walked while interrupts are disabled, or from within interrupts for that matter.

It would be great to have an elaborate bitwise event mechanism, but its not going to happen soon. If you want to have multiple tasks signal one task then you can use a queue with multiple writers and a single reader - then pass a structure on the queue to say where the message came from or what the data it contains represents.

Regards.

RE: synchronisation 1 to N

Posted by Tomas Novak on November 20, 2009
Hi Richard,

I understand that it is not quite easy to add new feature. But it seems to me that there is now "clever" workaroud for my project. As I wrote above, I need to signal from 1 ISR to unknown count of tasks. The finest way is to wait for event "HW updated". So, could you write (shortly) what is according to you "the best way" with current FreeRTOS?

Thanks in advance,

Tomas

RE: synchronisation 1 to N

Posted by Tomas Novak on November 20, 2009
Sorry, there should be
.... But it seems to me that there is no "clever" workaroud for my project. ....

One letter and quite big difference in meaning :-)

Tomas

RE: synchronisation 1 to N

Posted by Richard Damon on November 22, 2009
If I were to have an application that needed to send an "event" to many (possibly unknown number at compile time) tasks, what I would do was to have the interrupt use a single semaphore/queue to flag a distribution task, and each task that wants to be notified of the event register a semaphore/queue with that task. The distribution task waits for a signal from the interrupt, and passes it to the list of tasks that have registered they want to know of the interrupt. The distribution task should have a priority higher than any task that wants to be notified. Using a task avoids to distribute keeps down the length of time the system can't see new interrupts.

How to store the list of tasks to be notified can be done a number of ways depending on how well you know how many tasks may need to be notified

RE: synchronisation 1 to N

Posted by Tomas Novak on November 24, 2009
Hi Richard,
so you think it is better to use special distribution task instead of handling several semaphores inside ISR, don't you? I think (for simplicity) that handling a dynamic link list of binary semaphores (10 at maximum I asume) in ISR is possible, it will not take big long time, I hope.
Tomas

RE: synchronisation 1 to N

Posted by Adam Turowski on November 24, 2009
I agree with Richard, because the main requirement on any RTOS is its responsiveness. This depends on longest critical section. By distributting several semaphores from ISR you are increasing execution time of critical section, which affect whole system.

Having distribution task which runs on highest priority doen't compromise RTOS responsiveness regardless of amount of semaphores to be distributed. Distribution task execution time will be almost the same as ISR (task has overhead for context switch, but it is not big). The drawback is that this solution is slightly more complicated than pure ISR. But it is also much more generic.

I personally prefer distribution task solution, but it is up to you which solution you will use.

Regards,
Adam

RE: synchronisation 1 to N

Posted by Richard Damon on November 24, 2009
Running the list in the ISR will "work", assuming you can tolerate the additional interrupt latency in your system. If you do it in the ISR, since ISRs are critical sections, no other interrupt which needs to interface with FreeRTOS can occur (or none at all if your port doesn't support interrupt nesting). Doing the distribution in a task allows you to get the interrupt back online faster. While the distribution task should have higher priority than all the tasks it is activating, it might be lower than some other very high priority task that might be triggered by another interrupt.

If the list of tasks really is no more than ten, and you can afford interrupts being down for a bit, your concept of doing it in the interrupt may be acceptable. One thought is if you really can put a hard upper limit that low, it may make more sense for the list of semaphores to be stored in a static array with a counter for how many elements there are instead of a linked list.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists