FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [July 2013 Threads] Task Priority definePosted by vincent on July 31, 2013 Hi:
Is there a rule to define each task's priority ? eg, A task is used to collect data. B task digest the data. B priority should be higher than A task ?
in STM32 demo code with LWIP , I found that ethernet task priorty is lower than TCPIP task priorty . but i think that ethernet task is collecting input packet, TCPIP digest those packets, ethernet priority should be higher than TCPIP tas,, am I right ?
vincent
RE: Task Priority definePosted by Richard on July 31, 2013 There are no rules as such, you just need to make a judgement which is dependent on the application you are writing.
Using Ethernet as an example - what do you want the Ethernet to achieve? What are the resource constraints of the system?
If:
+ You want a received packets to be processed as quickly as possible, or
+ You have a limited number of network buffers, and must therefore free used buffers as quickly as possible so they can be reused by packets that arrive in the future
then...
Make the task that processes the TCP/IP stack (say task A) lower priority than the task that handles received packets (say task B). You can then see a scenario where:
Task A receives a packet and puts it through the TCP/IP stack. Task A sends the packet to Task B Task B is higher priority so preempts task A, so the packet is processed immediately Task B finishes with the packet, freeing up the buffer that contained the packet Task A runs again with the buffer that contained the packet it passed to task B already free and available for re-use.
Then consider a scenario where you don't have to worry about running out of buffers. In that case it might (depending on the application) be better to have task A higher priority than task B. That way if another packet comes in before task B has finished processing the first packet task A can run immediately to buffer the new packet with risk of it being lost. Then the new packet is already available for Task B when it has completed processing the first.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|