Everything works fine but I somehow feel uncomfortable as I couldn’t find an answer to my question in the subject. In other words: is there good reason for a function xSendEventStructToIPTaskFromISR()not to exist?
The tread you referred to gives the answer, that function needs to be created by the user if they want it, and is fairly simple to write.
The likely reason to not have the FromISR version of that function is that this ISR would be doing more than is good to be done in an ISR, at least in the mind of the person who wrote that code, and thus they are pushing people to using the deferred ISR method which doesn’t need the FromISR version.
Nothing says you can’t decide differently and make your own. That is one of the points of Open Source code.
The tread you referred to gives the answer, that function needs to be created by the user if they want it, and is fairly simple to write.
As stated in my post I have created such a function and it works (no exhaustive tests done yet).
The likely reason to not have the FromISR version of that function is that this ISR would be doing more than is good to be done in an ISR, at least in the mind of the person who wrote that code, and thus they are pushing people to using the deferred ISR method which doesn’t need the FromISR version.
Agreed. I’m fully aware of the fact that the a more complex (larger) ISR would take more time execute.
First reason for not using a deferred task is a comment found in the Embedded Ethernet Porting document:
… however for additional speed use BufferAllocation_1.c to perform the entire operation in the interrupt handler.
…
Second reason is that I can’t see any benefit (besides the shorter ISR fo course) using an additional task to, for example, transfer a received frame from the network interface to the IP stack.
With a deferred task, the following steps would be executed for a received frame:
ISR sends receive event to deferred task
deferred task uses xSendEventStructToIPTask() with eNetworkRxEvent to inform FreeRTOS IP stack
the FreeRTOS IP stack processes the received frame
The deferred task just operates as kind of middleman or forwarder between ISR and IP stack.
The biggest reason for having shorted ISRs is that it allows you to assign priorities to the work. Work done in an ISR is by definition done before any work in a task. Processing network packets isn’t always (in fact often isn’t) the highest priority work for a system. Thus, deferring the work means that work can be placed lower in priority to something else that might be very urgent.
If I may, I’d like to add that high network traffic load (eg broadcast storms or DoS attacks) may efficively stall the device when the ISR takes most of the processing load. Separating processing between ISRs and tasks may help in fine tuning load balancing and safety (some certifications require a device to recover from network disturbances).
And if I also may add: @RAc and @richard-damon describe exactly why “FromISR” is only used to wake up the prvEMACDeferredInterruptHandlerTask().
There is an old function pxNetworkBufferGetFromISR(), defined in BufferAllocation_1.c I don’t know of any driver using it. Allocating a new network buffer is a complex non-reentrant operation.
So my preferred Interrupt Service Routine will only read and clear an interrupt status register, and defer the processing to a normal task.
If your zero copy driver wants to wakeup the IP-task, I would let the ISR make an intermediate step and wakeup the deferred interrupt handler by calling TaskNotifyFromISR().
however for additional speed use BufferAllocation_1.c to perform the entire operation in the interrupt handler.
I read this recommendation before. It is possible, and it might speed-up things a little bit, but I’m afraid that the cons are bigger that the pros.