> From: lwip-users [mailto:address@hidden
> On Behalf Of Sylvain Rochet
> Sent: Tuesday, 10 May 2016 18:59
> On Tue, May 10, 2016 at 10:14:32PM +0000, Greg Smith wrote:
> > From: lwip-users
> > [mailto:address@hidden On Behalf
> > Of Sylvain Rochet
> > >
> > Sorry -- I seem to have forgotten the " 't " while I was typing. :-)
> > ...sio_write() can'T be passed directly to pppos_create()... It
> > definitely does not work and throws all sorts of compiler errors, as
> > you would expect (and hope). Because of that, I already had to change
> > my functions around. So getting rid of needing sio_write (as you
> > discussed below) isn't a big deal -- and is welcome.
> Oh!, that's fun because with a simple cast it will actually work (as long as
> your don't need the sio ptr), that's not something I should recommend but given
> signatures involved here there is no reason that could not work :-)
Yeah, I don't think I would recommend that, either. But certainly a fun (ab)use of C! :-)
> > > Of course it is, PPP is not using the SIO API anymore for, humm,
> > > almost a year. There is not a single reference to SIO in the whole
> > > PPP code
> > That said, sio.h is still included in ppp.c, ppp.h, and pppos.h.
> > I guess I beg to differ here, per the above files including sio.h.
> > That's why I thought it might still be needed. (Compiler errors when
> > I removed sio.h from my project.)
> > Once I took those #includes out (and removed sio.h from my project),
> > everything compiled OK. Hopefully it will run, too. :-)
> > Is that something you can remove from the source files before official
> > release? It would make things much more clear!
> Good catch!, I just removed them.
> > However, now that I've removed the extra call to sio_write(), I'd
> > still like to be able to pass arguments to the ppp_output_cb function.
> > In pppapi_pppos_create(), there is only one void *ctx_cb parameter. I
> > assumed that was for arguments to the link status callback. But either
> > way, how can I pass separate parameters to each callback function? (I
> > originally wanted to use this so I can compile lwIP as a library and
> > pass in another function pointer to an application-level call-back to
> > keep lwIP one more level decoupled from my main app. I figured
> > another way to do it for my application, but it may be useful to
> > others down the road?)
> Humm, the context is for all callbacks. That could be useful but saving RAM is
> the main lwIP goal, before code size, and before performance.
> On most of the targets I use at work we are always reaching out of memory
> condition wayyyyy before out of flash condition so more code to reduce RAM
> usage (such as using bitfields in place of bool) is always welcomed :-)
Oh, I'm there, my friend. I'm just starting to glue in lwIP into my main application. (So far, I've just been using a very minimal test app.) And I'm already worried about running out of RAM. Being in the embedded arena myself, I am very aware of using bitfields to save space, along with lots of other teeny-tiny tweaks to save a byte here or save a byte there.
Along those lines, if you have any suggestions to reduce footprint -- besides not compiling in options I don't need, like ARP, etc. -- I'd love to hear them. I don't fully understand even some of the basic options in lwIP, like how MEM_SIZE, MEMP_NUM_PBUF, MEMP_NUM_UDP_PCB all interact and how they affect overall system performance and functionality. So I think I'm going to be spending much of the next several days learning these options and fighting to get RAM back. :-)
> > > (except in the documentation maybe to tell that we are not using it
> > > anymore :p).
> > Speaking of documentation, the "how to convert from 1.4.x to 1.5.x" is
> > a pretty good guide. But I wish the info on Wikia were updated.
> > There are some things still referring to 1.3.x, I think, and some
> > empty (or nearly empty) info pages. Once 2.0 gets released, do you
> > know if there is going to be any effort to get that documentation
> > updated, too?
> I don't know, but not by me. Given the number of advertising, trackers, and
> customer interaction scripts running in Wikia, I am not going to subscribe
Oh, yes! Totally agree. I hate having to go to Wikia for any reason. Unfortunately, that's where Savannah sends you for documentation (including license info.)
(And I'm also not volunteering to documentation... :-) )
> Furthermore I like backups. No. I love backups. Documentation inside lwIP in
> text files properly versioned by Git means there is backups everywhere. If
> Wikia lose their data, all the documentation stored there is probably lost,
> that's not acceptable. Another thing why embedded documentation is great, when
> you download the release then it comes with the documentation that apply to the
> release you downloaded, while a wiki is for a version you usually don't even
Right there with you on backups -- and, better, version control! I like documentation within the source, too. And reading a wiki (or random Google searches) does usually provide information about versions that don't apply anymore. ...First world problems... :-)
While I do like the documentation that is within lwIP, it doesn't always do a great job of explaining detail on certain things, like options. As stated above, the comment for MEMP_NUM_PBUF, for example, doesn't tell me a whole lot about what it does or how to determine a good value for _me_. But, such is life. (My code isn't much better, sadly.)
> (By the way, I changed 1.5.x to 2.0.x in the documentation, thank you for the
> hint ;-) ).
You are welcome!
This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com