lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] FreeRTOS :: LWIP xInsideISR == (portBASE_TYPE)


From: FreeRTOS Info
Subject: Re: [lwip-users] FreeRTOS :: LWIP xInsideISR == (portBASE_TYPE)
Date: Fri, 15 Nov 2013 08:59:12 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



> configASSERT(xInsideISR == (portBASE_TYPE) 0); (full code below). So im 
> asking why is that happened ?
> 
> I am rookie at these staff so be patient :)
> 
> If anyone can help :)
> 
> Full code:

<snip>

> if(pdTRUE == xQueueReceive(*pxMailBox, &(*ppvBuffer), ulTimeOut / 
> portTICK_RATE_MS)) {

I'm not sure which code you are basing your project on, or where the
xInsideISR variable is getting set, but if the code really is being
called from inside an interrupt then the assert is quite right to stop
you.  The line above (and several other lines in your post) have two
issues for use in an interrupt:

1) FreeRTOS maintains a separate API for use inside and outside
interrupts.  This is for several reasons, but in summary, it means you
don't need any special code when entering an interrupt, you don't need
to count nesting, and both the code intended for use in an interrupt and
outside of an interrupt can be optimised for their single purpose.  Only
FreeRTOS API functions that end in "FromISR" can be used in an interrupt.

2) It just makes no program flow/sequencing sense to define a block time
when you are inside an interrupt.


In any case, generally it is best to get out of the interrupt as quickly
as you can, and defer processing to a task.  The simple Ethernet driver
on the link below is an example of how that is done.  The interrupt uses
an xSemaphoreGiveFromISR() function to unblock a task, then requests a
yield if the task unblocked by the semaphore has a higher priority than
the task the interrupt interrupted.  That way, the code still runs as
the very next thing, as if it were actually executed in the interrupt,
but it is actually executed in a task.

http://goo.gl/iubh1m -> see the ETH_Handler() interrupt handler and the
prvEMACDeferredInterruptHandlerTask() task definition.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...





reply via email to

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