Is there small size Ethernet stack STM32F107?

[iharihar]

Posted on December 30, 2009 at 06:18

Is there small size Ethernet stack STM32F107?

[iharihar]

Posted on May 17, 2011 at 13:35

I took a look lwIP stack application note

and found out that its mandatory modules size is 50 Kb SRAM. This is very many because total SRAM size STM32F107 - 64K. Could anybody point to whatever small size Ethernet stack? iharihar

[st3]

Posted on May 17, 2011 at 13:35

uIP ?

http://www.sics.se/~adam/uip/index.php/Main_Page

[akaiser9]

Posted on May 17, 2011 at 13:35

If due to some strange reasoning you decide to put everything in RAM, you need 50KB: ''This makes lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM.''

But the mentioned 50KB apparently were taken from the memory footprint of the demonstration code shown in some application note for the STM32. However given the author's quote above, I'm not sure whether STs demo was minimized or more likely tuned according to the controller's ressources.[ This message was edited by: prx on 27-12-2009 10:22 ]

[st3]

Posted on May 17, 2011 at 13:35

Quote:

lwIP stack ... mandatory modules size is 50 Kb SRAM.

Really? that sounds a bit excessive! Where, exactly, did you read that? (give a link)

[tomas23]

Posted on May 17, 2011 at 13:35

Hi, depends on what you want embedded in the stack, but few 1.5kB buffers and total of 5-15 kB should be enough in these small stacks (those without buffers for resending the windowed and lost packets and without re-assembling and reordering features)

[iharihar]

Posted on May 17, 2011 at 13:35

for ''St7'' link -

http://www.st.com/stonline/products/literature/an/16620.pdf

there wrote: ''10 buffers of 1500 bytes that constitute the lwIP pool of buffers. These parameters are defined in the lwipopts.h file by PBUF_POOL_SIZE (10) and PBUF_POOL_BUFSIZE (1500) 20 Kbytes dedicated for the lwIP's heap and defined in the lwipopts.h file by MEM_SIZE 6 buffers of 1520 bytes dedicated to the Ethernet driver and defined in the ethernetif.c file. There is no special rule to follow when setting the number of buffers, the heap size and the other parameters, because they mainly depend on the application itself. The number of buffers and the heap size allocated to the application depend on the application’s performance, simultaneous connection requirements and available RAM. Increasing these parameters (number of buffers and heap size) boosts the application performance and connectivity but reduces the amount of available RAM. Conversely, decreasing these parameters increases the available RAM space but limits the application performance and connectivity. The memory allocation defined in lwipopts.h is provided as an example and should be tailored to meet your application’s requirements. To ensure the robustness of the final application and to guarantee proper functioning in the worst case, you have to make sure that the application is tested in a network environment similar to the one to which the device is to be linked.'' Is there any understandable way to calculate optimum size SRAM for stack?

[st3]

Posted on May 17, 2011 at 13:35

Quote:

Is there any understandable way to calculate optimum (sic) size SRAM for stack?

Did you actually read the text that you quoted? It said,

Quote:

There is no special rule to follow when setting the number of buffers, the heap size and the other parameters, because they mainly depend on the application itself.

[tomas23]

Posted on May 17, 2011 at 13:35

Oh yes,

a) (some, but rare) compilers generate call tree with stack usage, b) you allocate enough stack, fill it with some recognizable pattern, run your application under VERY INTENSIVE testing, and check how much stack content has been overwritten. Then you add safety margin and limit your stack preset to such measured value, c) you know your application very well and can calculate the stack usage yourself

[st3]

Posted on May 17, 2011 at 13:35

I think he was talking about ''stack'' as in ''TCP/IP Stack'' - rather than the processor ''stack'' memory used for call, return, parameter passing, etc...?