Hi, On Fri, Jul 08, 2016 at 10:55:31AM +0200, Simon Goldschmidt wrote: > Sylvain Rochet wrote: > > the problem here is that some OS have two > > differents API, one which must be called from interrupt context, and one > > from threads. This is the case at least for FreeRTOS: > > I know that. You could argue whether lwIP is the problem here or the > FreeRTOS API :-) > > Are there any other OSes doing it like that?
Yes. About locking, since it is what is behind the issue after all, Linux spinlock API have two (at least :p) different set of functions: - spin_lock_irqsave() / spin_unlock_irqrestore() - spin_lock() / spin_unlock() That's only one example which cames to my mind from what I used lately. > Is there actually a good reason to do so? What's the difference > between "tryPost" from ISR vs. from task? The main difference is that sending a message to a message box triggers an immediate context switch (context = program counter(PC), CPU registers (SRxx), stack pointer (SP), …) if the receiving task have a higher priority than the sender task. The problem is doing a context switch in interrupt context is forbidden because the hardware messed up the software-driven context when entering the interrupt. It means the OS have no clue in interrupt which task was currently running and have to wait the return from interrupt to let the hardware restore the saved context using the special return-from-interrupt call, then and only then it is possible to do the context switch. > In the end, it's a port limitation that you have to have an RX thread > when using FreeRTOS. Well, for my point of view, lwIP is missing sys port calls from interrupt context and at least a tcpip_input_from_isr() function, so, in my mind, lwIP is the problem. Sylvain
signature.asc
Description: Digital signature
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users