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:
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.
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.
Hm. Thank you very much for the answer! Am I doing something wrong ?
I dont see any staff used from FreeRTOS here. My sources are from FreeRTOS Plus Demo 2. There is used LwIP as for example. Do I need some to adjust ? Thank you for replay.