Hi Sylvian,
I think I have found proof that the tcpip_input is not a blocking call. If
I break in my low_level_input, the function that will call
return netif->input(p,netif);
the isr is not in the function stack
[image: Inline image 1]
(this is a snippet of CCS TI IDE)
and actually stepping i
Sorry press sent by mistake
On the other hand I think the port is not calling tcpip_input from the ISR
context, I will still implement the change to eliminate a unknown. This is
how I start my code in SYSBIOS:
(these are what I think are the relevant pieces to the conversation)
Create and call t
Thanks Jeff, Simon, Sylvain,
Please bear with me since I'm a little bit out of my comfort zone.
Sylvian first suggestion is to not called tcpip_input from the interrupt
and provided a suggestion that is probably safer in the case of SYSBIOS
having or not a different context between ISR and other
On 07/08/2016 05:23 AM, Simon Goldschmidt wrote:
I know what's behind technically, with that question I'd rather meant what's
the big deal for an OS
to make this difference? It knows about which task is currently running and
which got runnable,
so it's not a big deal to know it's in interrupt c
Custom pools is a feature implemented after 1.4.1. Will be in 2.0.0
release.
Try to add the following lines from
memp.h (in 2.0.0) at the top
, maybe this will help you
:
/* run once with empty definition to handle all custom includes in
lwippools.h */#define LWIP_MEMPOOL(name,num,size,desc
On 7/7/2016 3:00 PM, Sushain Razdan wrote:
Hi,
Thanks for your reply ! Sorry for replying so late
I am currently using lwip version 1.4.1 and this version doesn't have
the Marco LWIP_MEMPOOL_DECLARE as used in httpd.c in the latest
version, Also I found that memory management is quite differen
Sylvain Rochet wrote:
>> 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 [..] if the receiving task have a
> higher priority than t
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
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
Hi,
On Fri, Jul 08, 2016 at 10:14:32AM +0200, Simon Goldschmidt wrote:
> Sylvain Rochet wrote:
> > You can't call tcpip_input() from an interrupt, this is a blocking
> > message passing, it can block.
>
> It's not: tcpip_input/tcpip_inpkt calls sys_mbox_trypost(), which does
> not have to be blo
Sylvain Rochet wrote:
> You can't call tcpip_input() from an interrupt, this is a blocking
> message passing, it can block.
It's not: tcpip_input/tcpip_inpkt calls sys_mbox_trypost(), which does not have
to be blocking but should return != ERR_OK if the queue is full (drop input
packets). Howeve
Hi Jaime,
On Thu, Jul 07, 2016 at 07:00:11PM -0500, Jaime Fernandez Hoffiz wrote:
> Hi Sylvain,
>
> I think I actually use tcpip_input but please correct me if I'm doing
> something wrong
>
> this is how I add the netif:
>
> Inside my callback if I change from ethernet_input to tcpip_input I ca
12 matches
Mail list logo
