[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
signature.asc
Description: Digital signature