lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] stm32 ethernet interrup priority


From: Erkan Ersoy
Subject: Re: [lwip-users] stm32 ethernet interrup priority
Date: Mon, 22 Aug 2016 12:00:07 +0000 (UTC)

Thank you Noam;

Somethings are confusing but i think i get it 

So I shouldn't use priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY value which is 5 by defult.
cortexM3 have priority 0 to 255 but ST uses 0 to 15. 
Confusing part is ST used those defines

#define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

those values are 
configKERNEL_INTERRUPT_PRIORITY : 240
configMAX_SYSCALL_INTERRUPT_PRIORITY: 80

but they never used those defines so they used only values above 5 without defines. Those defines stay there idle.

I use 6 for ethernet interrupt and 7 for USART interrupt now it seems work fine


On Monday, August 22, 2016 11:51 AM, Jan Menzel <address@hidden> wrote:


Hi Erkan!
    Despite interrupt priorities, system freezes are usually an indication
for badly designed interrupt handlers. Interrupt handler shall only do
necessary things and execute as fast as possible. In some designs I've
see interrupt handler do as little as only wakeup a task that to do the
actual work.
    Next, FreeRTOS splits the available interrupt priorities into two
classes. In the lower one RTOS functions may be executed like waking up
a task or sending data using a queue, while in the higher class RTOS
functions are not allowed. The lower class interrupts are sometimes
blocked by certain RTOS functions and hence provide less precise
response behaviour. The higher class is never blocked and therefore
executes immediately if there is no other interrupt of same of higher
priority currently active. The classes are defined by
"configMAX_SYSCALL_INTERRUPT_PRIORITY"
    Finally, systemtick handler is usually running at lowest priority. All
it does is count ticks, watch for sleeping tasks and cycle tasks of same
priority. If that does not happen for you, you're back at the beginning,
badly designed interrupt handlers...

    Jan

On 20.08.2016 11:54, Erkan Ersoy wrote:
> Hello;
>
> I am trying to implement usart interrupt to my project
>
> So iread freertos stm32 interrupt warnings and set i lilk that
>
> /* Enable the Ethernet global Interrupt */
> NVIC_InitStructure.NVIC_IRQChannel = ETH_IRQn;
> NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority =2;
> NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
> NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
> NVIC_Init(&NVIC_InitStructure);
>
> //USART 5 interrupt
> NVIC_InitTypeDef NVIC_InitStruct;
> NVIC_InitStruct.NVIC_IRQChannel = UART5_IRQn;
> NVIC_InitStruct.NVIC_IRQChannelCmd = ENABLE;
> NVIC_InitStruct.NVIC_IRQChannelPreemptionPriority =
> configMAX_SYSCALL_INTERRUPT_PRIORITY;
> NVIC_InitStruct.NVIC_IRQChannelSubPriority = 1;
> NVIC_Init(&NVIC_InitStruct);
>
> But I begin to have system freezes so i changed it like that
>
> /* Enable the Ethernet global Interrupt */
> NVIC_InitStructure.NVIC_IRQChannel = ETH_IRQn;
> NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority =
> configMAX_SYSCALL_INTERRUPT_PRIORITY;
> NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
> NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
> NVIC_Init(&NVIC_InitStructure);
>
> //USART 5 interrupt
> NVIC_InitTypeDef NVIC_InitStruct;
> NVIC_InitStruct.NVIC_IRQChannel = UART5_IRQn;
> NVIC_InitStruct.NVIC_IRQChannelCmd = ENABLE;
> NVIC_InitStruct.NVIC_IRQChannelPreemptionPriority =
> configMAX_SYSCALL_INTERRUPT_PRIORITY;
> NVIC_InitStruct.NVIC_IRQChannelSubPriority = 1;
> NVIC_Init(&NVIC_InitStruct);
>
> Now I don't have a problem. The diffference is ethernet interrupts. I
> didnt have a problem until i added the usart interrupt. And I look at
> ST's freertos examples they set it to 2.
>
> is there something wrong with my current code that will cause problem in
> the future?
> (I will move UART5 task to USART1 after I finish writing functionality)
>
> Thank you

>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users




reply via email to

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