lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCPIP and MAC thread task priorities


From: Sylvain Rochet
Subject: Re: [lwip-users] TCPIP and MAC thread task priorities
Date: Mon, 27 Feb 2017 13:24:39 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

Hi,

On Mon, Feb 27, 2017 at 11:50:26AM +0000, Noam Weissman wrote:
> Hi All,
> 
> This comes from my own experience with STM micro that has Cortex-M core 
> Running with FreeRTOS. It does apply to STM9 etc...
> 
> TCP main task priority should be high priority. It should not be the 
> highest priority but it should not be lower than other tasks that 
> consume lots of time share.
> 
> The most misunderstood issue is interrupt priority levels in Cortext-M 
> and FreeRTOS.
> 
> First of all: A lower number in Coretex means a higher priority while 
> in FreeRTOS a higher number Means a higher priority.
> 
> Secondly Cortex use a nesting interrupt and a smart level... Assume 
> you set an interrupt to level 2 and try to run some critical section 
> code from RS232 but that RS232 has an interrupt level set at 5.
> 
> What happens is that the interrupt 2 (higher) will never be masked 
> because the issuer of the Critical section runs at a lower interrupt 
> level.
> 
> FreeRTOS has lots of sections like this one:
> 
>   portENTER_CRITICAL();
>   {   
>      // some code
>   }   
>   portEXIT_CRITICAL();
> 
> 
> If you set your interrupt level to be higher priority than the 
> FreeRTOS timer tick that part will never Be masked and your critical 
> section will not work as expected.

I don't understand any of this, portENTER_CRITICAL/portEXIT_CRITICAL 
proper implementation is to disable *ALL* interrupts, therefore having a 
critical section which is not enforced for whatever reason can't happen 
at all.

By the way, FreeRTOS is not supposed to run with nested interrupts, you 
have to put all OS calls from interrupts (i.e. *FromISR() functions) in 
a critical section.

Sylvain

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]