Re: [lwip-devel] new user - Some remarks

[Mike Kleshov]

> with MicroC/OS-II. As you may know, this PIC18 family is really really
> limited in terms of resources, and that's why i'm working to understand all

If I'm interpreting the PIC18 product lineup correctly, the maximum
RAM size available is between 3 and 4 Kbytes. Lwip will not give you
any advantage over less capable TCP/IP stacks with so little RAM.
Perhaps, you should consider uIP.

>   - first, i have to do back through the ARP code, but i faced some troubles
> with an 8-bit data which was left-shifted by 8 when building the ARP
> packet... In case integer promotion is enabled, no problem. But when such an
> option is cleared, then this becomes a bug. Does this sounds good to you ?

Lwip is written for ANSI C conforming compilers. It doesn't make sense
to try and adapt it to compilers with integer promotion switched off.
Besides, it would only affect low-end 8-bit devices, and they are
hardly capable enough for lwip anyway.

>   - also, and this is only a suggestion : i would like to get your opinion
> on the following idea : would it make sense to provide some macros such as
> eth_if_mem_read() and eth_if_mem_write() when building the packet in lwip
> functions ? I'm thinking about some higher-level rework of memory, just to
> provide one more way to allocate/deallocate memory for the stack, but inside
> the controller memory itself. Maybe (and probably) these allocations in the
> controller memory are not judicious for all memory allocations (depending on
> the data access frequency, controller interface speed,...) but it can help
> people with strong resources constraints (usually RAM) to use controller's
> memory as a working memory instead of a transmission memory only. Makes
> sense ?

I'm not sure I understand what this means.
Yes, lwip is trying to be 'lightweight' in terms of memory footprint.
But it's not trying to squeeze every last byte possible. It sounds
like what you are suggesting is taking the memory saving idea to the
extreme. At some point source code will become unreadable and less
memory-constrained users will suffer from the extra code. It's just
not worth it.
Again, you should look at uIP.