[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is

From: Brian Stull
Subject: Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times
Date: Fri, 30 Oct 2015 09:42:26 -0400

Thank you Sylvain.

I'm not sure I'm comfortable with LWIP to make the changes that you mentioned 
but I'll look at it more closely. 

With the current implementation, if I wait in the sio_write() function until 
the data is transmitted, this is going to hold up the LWIP stack (which I'm 
guessing is not good).

Let me explain my current implementation of sio_write() and you can tell me if 
it seems wrong. I have concerns with holding up LWIP but I don't see an easy 
way around it. No matter how many buffers I have LWIP could eventually fill 
them up I would think... then what should happen?

My current sio_write() implementation:
1. I have a dedicated buffer to send sio serial data from. 
2. When sio_write() is called, I check to see if the UART is available to send. 
3. If the UART is available, I'm copying the data into my dedicated buffer and 
starting the UART write. I then return "len"
4. If the UART is NOT available, I'm waiting until it is free then I'm going 
back to step #3. 

So, basically, I can queue up one sio_write packet then I start having to 


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Sylvain Rochet
Sent: Thursday, October 29, 2015 3:24 PM
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) 
is called multiple times

Hi Brian,

On Thu, Oct 29, 2015 at 11:55:50AM -0400, Brian Stull wrote:
> After a little more debugging this morning I'm thinking this problem 
> is related to some timeout/retry mechanisms of the PPP stack and how 
> I've implemented my sio_write function.
> In my sio_write function, if the UART is busy (sending previous 
> sio_write
> data) when the function is called I am returning "0". Which, I believe 
> is the proper operation. If I put in a 1ms delay when this happens 
> instead of just returning "0" immediately I am seeing this problem go away.

There is currently no tx queue in the PPP stack at the serial level, your 
sio_write() function MUST queue or write the data to the serial port. Worse, 
there is no framing information passed with sio_write() so you never know if it 
is safe to drop the data, which could be in a middle of a packet.

Anyway, adding the feature would be very welcomed. Basically we'll need to keep 
a pbuf list of pbuf which are not completely sent (with a sio.h configurable 
value of how big the queue can grow) and wait for a call to 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]