But that test doesn't use c++ nor use exceptions, but you will see this problem if you do a objdump over the binaries.
On Wed, Dec 17, 2014 at 2:47 PM, Daniel Gutson < daniel.gut...@tallertechnologies.com> wrote: > > Maybe it's worth to mention the 20k or so EH-related buffers? > I think they go away when building the STL without EH and RTTI support, > right? > > On Wed, Dec 17, 2014 at 2:44 PM, Marcos Díaz < > marcos.d...@tallertechnologies.com> wrote: >> >> That particular test I could see it uses like four tasks. The problem we >> had in the past is that the predefined size for the stack for each task was >> set to 4k for our architecture (arm cortex m3). We proposed a patch in >> order to make the default stack size for each bsp configurable. Im not sure >> if it has been submitted >> >> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER >> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER >> >> #define CONFIGURE_MAXIMUM_TASKS 4 >> >> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE >> >> #define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE) >> >> #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION >> >> this is extracted from the "system.h" file of ticker test. >> >> If your objective is to have that test working, i suggest to tune the >> minimum stack size in this file. >> If you want to know a little more, I suggest that you make a objdump and >> see what global objects are using more RAM and where did they come from. >> >> On Wed, Dec 17, 2014 at 1:36 PM, Daniel Gutson < >> daniel.gut...@tallertechnologies.com> wrote: >>> >>> We were able to downsize RTEMS to about 9k for the LPC1768. >>> Marcos, could you give a hint? >>> >>> On Wed, Dec 17, 2014 at 1:34 PM, Joel Sherrill < >>> joel.sherr...@oarcorp.com> wrote: >>>> >>>> >>>> >>>> On December 17, 2014 8:00:50 AM PST, Hesham Moustafa < >>>> heshamelmat...@gmail.com> wrote: >>>> >Hi all, >>>> > >>>> >I am working on reducing RTEMS size to fit into <32KB as every Epiphay >>>> >core has only 32KB of local memory. I was able to get hello and >>>> >minimum samples with aggressive size reduction by manually removing >>>> >un-needed code. Currently I only use libcsupport, sapi, score, rtems >>>> >built for cpukit only, and for each, some source code files were >>>> >removed. No IO, no FS, no barrier, event, managers are included. >>>> >>>> Our minimum is where it is because no one has provided lower >>>> requirements. Some of the things you dropped out could be addressed by >>>> initialization being more like a constructor table that is automatically >>>> built based on dependencies. This was/is the sequenced initialization >>>> project. I don't know the state of it. >>>> >>>> Try turning on per section methods and data like the SPARC bsps. This >>>> saves memory. >>>> >>>> >>>> Defining which features are part of 'nanoRTEMS' is a big part of this. >>>> Then those requirements can drive dropping things not covered by sequenced >>>> initialization and finer tuning. >>>> >>>> Using printk saves a lot of memory. >>>> >>>> >And I >>>> >added -Os flag. However when building ticker, the .text area overflows >>>> >the 32KB local memory by about 8KB. >>>> > >>>> >The question is, what are the very basic mandatory sources/libraries >>>> >and/or managers that are enough to build ticker? >>>> >>>> Some of that is stack size in ticker. Look at the ticker variants in >>>> examples-v2 >>>> >>>> >Regards, >>>> >Hesham >>>> >_______________________________________________ >>>> >devel mailing list >>>> >devel@rtems.org >>>> >http://lists.rtems.org/mailman/listinfo/devel >>>> >>>> --joel >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>>> >>> >>> >>> -- >>> >>> Daniel F. Gutson >>> Chief Engineering Officer, SPD >>> >>> San Lorenzo 47, 3rd Floor, Office 5 >>> Córdoba, Argentina >>> >>> Phone: +54 351 4217888 / +54 351 4218211 >>> Skype: dgutson >>> LinkedIn: http://ar.linkedin.com/in/danielgutson >>> >> >> >> -- >> >> ______________________________ >> >> <http://www.tallertechnologies.com> >> >> >> Marcos Díaz >> >> Software Engineer >> >> >> San Lorenzo 47, 3rd Floor, Office 5 >> >> Córdoba, Argentina >> >> >> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 >> >> Skype: markdiaz22 >> >> > > -- > > Daniel F. Gutson > Chief Engineering Officer, SPD > > San Lorenzo 47, 3rd Floor, Office 5 > Córdoba, Argentina > > Phone: +54 351 4217888 / +54 351 4218211 > Skype: dgutson > LinkedIn: http://ar.linkedin.com/in/danielgutson > -- ______________________________ <http://www.tallertechnologies.com> Marcos Díaz Software Engineer San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452 Skype: markdiaz22
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
