* [ECOS] ecos mem footprint with HTTPD support @ 2009-07-15 10:37 Mandeep Sandhu 2009-07-15 11:06 ` [ECOS] " John Dallaway 0 siblings, 1 reply; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-15 10:37 UTC (permalink / raw) To: ecos-discuss Hi all, Just as I got a rough estimate of how much mem (worst case) my hello world app along with the rest of the ecos libs take, is there any sample prog which I can use to ascertain the runtime size of my app which uses the HTTPD pkg? Should I write some sample prog which makes use of the HTTP pkg to determine the size or are there example programs available which make use of this pkg? Thanks, -mandeep -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 10:37 [ECOS] ecos mem footprint with HTTPD support Mandeep Sandhu @ 2009-07-15 11:06 ` John Dallaway 2009-07-15 13:14 ` Sergei Gavrikov 2009-07-15 13:16 ` Mandeep Sandhu 0 siblings, 2 replies; 12+ messages in thread From: John Dallaway @ 2009-07-15 11:06 UTC (permalink / raw) To: Mandeep Sandhu; +Cc: ecos-discuss Hi Mandeep Mandeep Sandhu wrote: > Just as I got a rough estimate of how much mem (worst case) my hello world > app along with the rest of the ecos libs take, is there any sample prog which I > can use to ascertain the runtime size of my app which uses the HTTPD pkg? Note that the HTTPD package is intended for use with the eCos FreeBSD TCP/IP stack, not lwIP. The lwIP TCP/IP stack provides its own HTTP server test. Simply configure eCos for lwIP networking and then build eCos and the eCos tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the resulting "httpd" test executable file. John Dallaway -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 11:06 ` [ECOS] " John Dallaway @ 2009-07-15 13:14 ` Sergei Gavrikov 2009-07-15 13:18 ` Mandeep Sandhu 2009-07-15 13:16 ` Mandeep Sandhu 1 sibling, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2009-07-15 13:14 UTC (permalink / raw) To: John Dallaway; +Cc: Mandeep Sandhu, ecos-discuss John Dallaway wrote: > Hi Mandeep > > Mandeep Sandhu wrote: > > > Just as I got a rough estimate of how much mem (worst case) my hello world > > app along with the rest of the ecos libs take, is there any sample prog which I > > can use to ascertain the runtime size of my app which uses the HTTPD pkg? > > Note that the HTTPD package is intended for use with the eCos FreeBSD > TCP/IP stack, not lwIP. > > The lwIP TCP/IP stack provides its own HTTP server test. Simply > configure eCos for lwIP networking and then build eCos and the eCos > tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the > resulting "httpd" test executable file. To know its sizes and to peace a linker I use a trick (workaround for "section .bss is not within region ram" error). Let's call it "How much is The Fish". It is sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld it just multiply target's ram size on 16 :-) I run this 1-line sed script before to build the tests. The below is just an example (I have no target) ecosconfig new sam7ex256 lwip_eth ecosconfig tree make sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld make -C net/lwip_tcpip/current/ tests TESTS=tests/httpd text data bss dec hex filename 71240 5428 102808 179476 2bd14 httpd Ups... But, AFAIK, lwip's pbufs sucks RAM. Default number of pbufs is 60, its default size is 1K. 60x1K... Well, let's reduce amount of the buffers, i.e. import the below cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE { user_value 6 }; and rebuild the test text data bss dec hex filename 71240 5428 46648 123316 1e1b4 httpd It is something more interesting, but, I could break down the lwip networking. I do not know. To reduce text segment you can disable udp, raw ethernet support, etc., etc. (it's eCos). Hey, do not forget to revert ld script! It's easy if you use bash history sed -i '/ram.*LENGTH/s,0$,,' isntall/lib/target.ld And now, without jokes. Look at Adam Dunkel's uIP TCP/IP stack http://www.sics.se/~adam/uip/ and his invention, - Protothreads (Stackless Threads in C) http://www.sics.se/~adam/pt/ I have a dream to try eCos together with Adam's Protothreads. If it will allright, it will be possible to get unbeatable sizes for small memory footprint targets. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 13:14 ` Sergei Gavrikov @ 2009-07-15 13:18 ` Mandeep Sandhu 2009-07-15 13:53 ` Sergei Gavrikov 0 siblings, 1 reply; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-15 13:18 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: John Dallaway, ecos-discuss Wow Sergei! some telepathy you have...how'd you know I was about to post the error .bss error! :) seems like a std error? now back to reading your reply :) ..... On Wed, Jul 15, 2009 at 6:48 PM, Sergei Gavrikov<sergei.gavrikov@gmail.com> wrote: > John Dallaway wrote: >> Hi Mandeep >> >> Mandeep Sandhu wrote: >> >> > Just as I got a rough estimate of how much mem (worst case) my hello world >> > app along with the rest of the ecos libs take, is there any sample prog which I >> > can use to ascertain the runtime size of my app which uses the HTTPD pkg? >> >> Note that the HTTPD package is intended for use with the eCos FreeBSD >> TCP/IP stack, not lwIP. >> >> The lwIP TCP/IP stack provides its own HTTP server test. Simply >> configure eCos for lwIP networking and then build eCos and the eCos >> tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the >> resulting "httpd" test executable file. > > To know its sizes and to peace a linker I use a trick (workaround for > "section .bss is not within region ram" error). > > Let's call it "How much is The Fish". It is > > sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld > > it just multiply target's ram size on 16 :-) > > I run this 1-line sed script before to build the tests. > > The below is just an example (I have no target) > > ecosconfig new sam7ex256 lwip_eth > ecosconfig tree > make > sed -i '/ram.*LENGTH/s,$,0,' isntall/lib/target.ld > make -C net/lwip_tcpip/current/ tests TESTS=tests/httpd > > text data bss dec hex filename > 71240 5428 102808 179476 2bd14 httpd > > Ups... But, AFAIK, lwip's pbufs sucks RAM. Default number of pbufs is > 60, its default size is 1K. 60x1K... Well, let's reduce amount of the > buffers, i.e. import the below > > cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE { > user_value 6 > }; > > and rebuild the test > > text data bss dec hex filename > 71240 5428 46648 123316 1e1b4 httpd > > It is something more interesting, but, I could break down the lwip > networking. I do not know. To reduce text segment you can disable udp, > raw ethernet support, etc., etc. (it's eCos). > > Hey, do not forget to revert ld script! It's easy if you use bash > history > > sed -i '/ram.*LENGTH/s,0$,,' isntall/lib/target.ld > > And now, without jokes. Look at Adam Dunkel's uIP TCP/IP stack > http://www.sics.se/~adam/uip/ > > and his invention, - Protothreads (Stackless Threads in C) > http://www.sics.se/~adam/pt/ > > I have a dream to try eCos together with Adam's Protothreads. If it will > allright, it will be possible to get unbeatable sizes for small memory > footprint targets. > > > Sergei > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 13:18 ` Mandeep Sandhu @ 2009-07-15 13:53 ` Sergei Gavrikov 2009-07-15 14:05 ` Mandeep Sandhu 0 siblings, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2009-07-15 13:53 UTC (permalink / raw) To: Mandeep Sandhu; +Cc: John Dallaway, ecos-discuss Mandeep Sandhu wrote: > > seems like a std error? now back to reading your reply :) ..... That error is not surprise for small memory footprint targets. I hope you get it. That trick did not fit an external RAM on your board, It did deceive linker and then you can use `size' utility. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 13:53 ` Sergei Gavrikov @ 2009-07-15 14:05 ` Mandeep Sandhu 2009-07-15 14:17 ` Sergei Gavrikov 0 siblings, 1 reply; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-15 14:05 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: John Dallaway, ecos-discuss On Wed, Jul 15, 2009 at 7:27 PM, Sergei Gavrikov<sergei.gavrikov@gmail.com> wrote: > Mandeep Sandhu wrote: >> >> seems like a std error? now back to reading your reply :) ..... > > That error is not surprise for small memory footprint targets. I hope > you get it. That trick did not fit an external RAM on your board, It did > deceive linker and then you can use `size' utility. Yes, I suspected that much. But tell me, where does the linker get the RAM size constraint for the atmel board...i.e the sam7ex256? It must be configured somewhere...as part of a template...no? Couldn't we have "added" RAM there? BTW, your trick worked...I pretty much get the same numbers as you had shown... Before reducing PBUF pool size: arm-eabi-size test_install/tests/net/lwip_tcpip/v3_0/tests/httpd text data bss dec hex filename 71512 5440 102796 179748 2be24 test_install/tests/net/lwip_tcpip/v3_0/tests/httpd After reducing it to 6: arm-eabi-size test_install/tests/net/lwip_tcpip/v3_0/tests/httpd text data bss dec hex filename 71512 5440 46636 123588 1e2c4 test_install/tests/net/lwip_tcpip/v3_0/tests/http So this figure is not too different from the FreeRTOS numbers for similar app :)... ~/freeRTOS/FreeRTOS/Demo/lwIP_Demo_Rowley_ARM7$ ~/gnuarm/gnuarm-3.4.3/bin/arm-elf-size rtosdemo.elf text data bss dec hex filename 119096 2016 62736 183848 2ce28 rtosdemo.elf Do you think 256K RAM will be enough to run a similarly configured system (with additional USB device and SPI driver support) on ARM7 based embedded SoC? -mandeep > > > Sergei > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 14:05 ` Mandeep Sandhu @ 2009-07-15 14:17 ` Sergei Gavrikov 2009-07-16 8:54 ` Mandeep Sandhu 0 siblings, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2009-07-15 14:17 UTC (permalink / raw) To: Mandeep Sandhu; +Cc: John Dallaway, ecos-discuss On Wed, Jul 15, 2009 at 07:35:01PM +0530, Mandeep Sandhu wrote: > On Wed, Jul 15, 2009 at 7:27 PM, Sergei > Gavrikov<sergei.gavrikov@gmail.com> wrote: > > Mandeep Sandhu wrote: > >> > >> seems like a std error? now back to reading your reply :) ..... > > > > That error is not surprise for small memory footprint targets. I hope > > you get it. That trick did not fit an external RAM on your board, It did > > deceive linker and then you can use `size' utility. > > Yes, I suspected that much. But tell me, where does the linker get the RAM > size constraint for the atmel board...i.e the sam7ex256? It must be configured > somewhere...as part of a template...no? > > Couldn't we have "added" RAM there? > That is defined in plf mlt files. I guess here for your target hal/arm/at91/at91sam7s/current/include/pkgconf/mlt* [snip] > Do you think 256K RAM will be enough to run a similarly configured > system (with additional USB device and SPI driver support) on ARM7 > based embedded SoC? IMO, it will be possible, if you will use lwIP TCP/IP stack. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 14:17 ` Sergei Gavrikov @ 2009-07-16 8:54 ` Mandeep Sandhu 2009-07-16 9:10 ` Sergei Gavrikov 2009-07-16 18:30 ` John Dallaway 0 siblings, 2 replies; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-16 8:54 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: John Dallaway, ecos-discuss >> Couldn't we have "added" RAM there? >> > > That is defined in plf mlt files. I guess here for your target > hal/arm/at91/at91sam7s/current/include/pkgconf/mlt* > Ok will check that. Thanks. > [snip] > >> Do you think 256K RAM will be enough to run a similarly configured >> system (with additional USB device and SPI driver support) on ARM7 >> based embedded SoC? > > IMO, it will be possible, if you will use lwIP TCP/IP stack. I think I was wrongly calculating my RAM usage for the sample HTTPD app (using lwIP). When looking for the runtime RAM usage of my app+kernel...I should add the bss+data+rwdata (if any) sections...right? .text and .rodata will reside in the flash only. Am I correct in this assumption? Do all embedded systems work this way...i.e the code/text and rodata sections reside in the flash and rest is loaded into the RAM? Who maps these addresses? The linker script? Because with this calc, my RAM requirement gets reduced drastically. Also, any tips on how much space I should keep for expansion of the RW area's? Say my bss+data+rwdata comes to around 55KB...is it safe to go with a system with 64KB on-chip RAM? Is 9KB margin safe enough? thanks as always, -mandeep > > Sergei > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-16 8:54 ` Mandeep Sandhu @ 2009-07-16 9:10 ` Sergei Gavrikov 2009-07-16 18:30 ` John Dallaway 1 sibling, 0 replies; 12+ messages in thread From: Sergei Gavrikov @ 2009-07-16 9:10 UTC (permalink / raw) To: Mandeep Sandhu; +Cc: John Dallaway, ecos-discuss On Thu, Jul 16, 2009 at 02:24:33PM +0530, Mandeep Sandhu wrote: > I think I was wrongly calculating my RAM usage for the sample HTTPD > app (using lwIP). man size. By default format is short (Berkeley format). Try -Ax for size run and you will see all locations. For reading: man readelf, man objdump. MLT stands from Memory LayouT. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-16 8:54 ` Mandeep Sandhu 2009-07-16 9:10 ` Sergei Gavrikov @ 2009-07-16 18:30 ` John Dallaway 2009-07-17 8:24 ` Mandeep Sandhu 1 sibling, 1 reply; 12+ messages in thread From: John Dallaway @ 2009-07-16 18:30 UTC (permalink / raw) To: Mandeep Sandhu; +Cc: ecos-discuss Hi Mandeep Mandeep Sandhu wrote: > I think I was wrongly calculating my RAM usage for the sample HTTPD > app (using lwIP). > > When looking for the runtime RAM usage of my app+kernel...I should > add the bss+data+rwdata (if any) sections...right? Yes, for eCos applications built for ROM startup. There will also be a small area of RAM reserved for various vectors. > .text and .rodata will reside in the flash only. Am I correct in this > assumption? Yes, for eCos applications built for ROM startup. The Flash will also hold the original copy of the pre-initialised static data which is copied to RAM at startup (.data section). Note also that a few small fragments of _code_ are also relocated to RAM (eg low-level Flash I/O code). > Do all embedded systems work this way...i.e the code/text and rodata sections > reside in the flash and rest is loaded into the RAM? They should do when configured for ROM startup. > Who maps these addresses? > The linker script? Correct. > Also, any tips on how much space I should keep for expansion of the RW > area's? There is no expansion of the linker-defined sections. Thread-local variables are stored on the thread stacks. These stacks are typically allocated as static arrays. Some packages use their own statically-allocated memory pools. You must decide how large these stacks and memory pools need to be where necessary. If you must use malloc() and related functions, the eCos dynamic memory allocation package will allocate memory from the heap. The heap typically occupies all remaining RAM above the application code and data. Clearly, allocations from the heap are additional to anything known to the linker and reported by the "size" tool. > Say my bss+data+rwdata comes to around 55KB...is it safe to go with a > system with 64KB on-chip RAM? Is 9KB margin safe enough? You need no margin at all if you avoid dynamic memory allocation. I hope this helps... John Dallaway -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-16 18:30 ` John Dallaway @ 2009-07-17 8:24 ` Mandeep Sandhu 0 siblings, 0 replies; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-17 8:24 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-discuss > > There is no expansion of the linker-defined sections. Thread-local > variables are stored on the thread stacks. These stacks are typically > allocated as static arrays. Some packages use their own > statically-allocated memory pools. You must decide how large these > stacks and memory pools need to be where necessary. > > If you must use malloc() and related functions, the eCos dynamic memory > allocation package will allocate memory from the heap. The heap > typically occupies all remaining RAM above the application code and > data. Clearly, allocations from the heap are additional to anything > known to the linker and reported by the "size" tool. > >> Say my bss+data+rwdata comes to around 55KB...is it safe to go with a >> system with 64KB on-chip RAM? Is 9KB margin safe enough? > > You need no margin at all if you avoid dynamic memory allocation. > > I hope this helps... Thanks for clearing this. This does help a lot! Regards, -mandeep > > John Dallaway > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: ecos mem footprint with HTTPD support 2009-07-15 11:06 ` [ECOS] " John Dallaway 2009-07-15 13:14 ` Sergei Gavrikov @ 2009-07-15 13:16 ` Mandeep Sandhu 1 sibling, 0 replies; 12+ messages in thread From: Mandeep Sandhu @ 2009-07-15 13:16 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-discuss > The lwIP TCP/IP stack provides its own HTTP server test. Simply > configure eCos for lwIP networking and then build eCos and the eCos > tests for lwIP. Run "arm-eabi-size" (assuming an ARM target) on the > resulting "httpd" test executable file. Thanks for the tip John. But the test compilation is failing with the following error: make[1]: Leaving directory `/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_build/infra/v3_0' /home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld: address 0x219ae8 of /home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2 section .bss is not within region ram make: Leaving directory `/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_build' /home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld: address 0x219ae8 of /home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2 section .bss is not within region ram collect2: ld returned 1 exit status make[1]: *** [/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/diag_sprintf2] Error 1 make[1]: *** Waiting for unfinished jobs.... /home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld: address 0x21a4d8 of /home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp section .bss is not within region ram /home/mandeep/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/bin/ld: address 0x21a4d8 of /home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp section .bss is not within region ram collect2: ld returned 1 exit status make[1]: *** [/home/mandeep/ecos/sam7ex-lwIP/sam7ex-lwIP_install/tests/infra/v3_0/tests/cxxsupp] Error 1 make: *** [tests] Error 2 I have created a fresh config, choosing the at91sam7ex with iwIP template. The build passes, but the tests compilation is failing. The above errors are a little beyond me...but does it mean we've run out of RAM? Can I increase the amount of RAM in some config...for the sam7ex template? Thanks, -mandeep > > John Dallaway > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-07-17 8:24 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-15 10:37 [ECOS] ecos mem footprint with HTTPD support Mandeep Sandhu 2009-07-15 11:06 ` [ECOS] " John Dallaway 2009-07-15 13:14 ` Sergei Gavrikov 2009-07-15 13:18 ` Mandeep Sandhu 2009-07-15 13:53 ` Sergei Gavrikov 2009-07-15 14:05 ` Mandeep Sandhu 2009-07-15 14:17 ` Sergei Gavrikov 2009-07-16 8:54 ` Mandeep Sandhu 2009-07-16 9:10 ` Sergei Gavrikov 2009-07-16 18:30 ` John Dallaway 2009-07-17 8:24 ` Mandeep Sandhu 2009-07-15 13:16 ` Mandeep Sandhu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).