Thanks Sergio,
Yes, I will spend sometime with the docs.
"I call netif_add() passing ethernet_input() as my input function; then I call
my_netif->input() from the same and only context the other lwIP functions run,
no interrupts, because this is NO_SYS=1"vAm I correct?
Yes, I modified this imp
Perhaps you might spend some quality time with the docs
[me ~]$ more /src/include/lwip/netif.h
/** Whether the network interface is 'up'. This is
* a software flag used to control whether this network
* interface is enabled and processes traffic.
* It is set by the startup code (for static IP
Hi All,
To close the loop on my original question maybe it can help another rookie
like me.
My goal was to set my ethernet device so that it will act as a cable,
received packets from the netif, modulates them, send them over a cable,
have another device demod, the exact same packet, and last tra
On 07/09/2016 12:10 PM, goldsi...@gmx.de wrote:
Jeff Barlow wrote:
I think you will find that ChibiOS does much the same. The reasoning
as I understand it is to keep ISR code paths as short as possible to
minimize latency in hard real time systems.
Without knowing ChibiOS in detail, I'd be int
Jeff Barlow wrote:
I think you will find that ChibiOS does much the same. The reasoning
as I understand it is to keep ISR code paths as short as possible to
minimize latency in hard real time systems.
Without knowing ChibiOS in detail, I'd be interested in knowing what
would be the actual pe
Jaime Fernandez Hoffiz wrote:
the isr is not in the function stack
Inline image 1
(this is a snippet of CCS TI IDE)
This indicates your "low_level_input" is already called from
tcpip_thread, not from isr. In that case, it's actually OK to call
"ethernet_input" (or passing it to netif_add). I
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
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
Hi Sylvian,
I think I actually use tcpip_input but please correct me if I'm doing
something wrong
this is how I add the netif:
// netif_add(&netif, &laddr, &netmask, &gw, 0, arm9emac_init,
arm9emac_low_level_input);
// netif_add(&netif, &laddr, &netmask, &gw, 0, arm9emac_init,
ethernet_input);
n
Thanks Sylvain
I will try today with tcpip_input and move to use the raw api. Thanks.
Sent from my iPhone
> On Jul 7, 2016, at 14:35, Sylvain Rochet wrote:
>
> Hi Jaime,
>
>> On Thu, Jul 07, 2016 at 02:21:22PM -0500, Jaime Fernández wrote:
>>
>> Can the raw api be used with an OS or is it e
Hi Jaime,
On Thu, Jul 07, 2016 at 02:21:22PM -0500, Jaime Fernández wrote:
>
> Can the raw api be used with an OS or is it exclusively for none os
> implementations ?
That's properly documented inside lwip/doc/rawapi.txt AFAIK.
It can be used, but all raw API calls must be from the TCPIP threa
Hi Jaime,
On Thu, Jul 07, 2016 at 02:21:22PM -0500, Jaime Fernández wrote:
>
> Typo, I meant NO_SYS = 0.
You can't use ethernet_input function with !NO_SYS, this function is not
thread safe and part of the lwIP "raw" API, you have to use tcpip_input
instead.
Sylvain
signature.asc
Descriptio
Typo, I meant NO_SYS = 0. I think this is an issue with my eMac Config not
lwip. I'm going to try the enet echo for the omapl138, which is part of the TI
starterware.
My expectation is that the eMac RX callback or interrupt should break with
broadcast packets or for example if I ping the devic
Hi,
On Wed, Jul 06, 2016 at 02:01:26PM -0500, Jaime Fernández wrote:
>
> NO_SYS = 1, I'm using TI sysbios kernel.
> My laptop NIC is configured to ip= 192.168.10.1, sm = 255.255.255.0,
> gw= empty. My board netif is configure to ip=192.168.10.3, same subnet
> and gw=192.168.10.1.
>
> I have n
Sergio,
Thank you for your kind reply. Anything the mail list can suggest will help. It
could easily be a routing configuration
NO_SYS = 1, I'm using TI sysbios kernel.
My laptop NIC is configured to ip= 192.168.10.1, sm = 255.255.255.0, gw= empty.
My board netif is configure to ip=192.168.
I don't have a clue on the sysbios port nor the time to google it.
Looks like you have a routing problem, a connection problem, a who knows
problem.
arm9emac_rx_callback is clearly not an lwIP callback, you´d better ask
your vendor if you are unsure about that.
If you need further help (and no o
Hi,
Hope this will be a very simple question. I'm developing a modem. I already
have lwip running a tcpecho where I modulate the data not the whole packet.
I'm leveraging the arm9 SYSBIOS port from 1.4. Since modems are usually in
layer 1 I'm trying to write my application at a lower level than ne
25 matches
Mail list logo
