Reducing RTEMS size to <32KB to fit in Epiphany local memories

[Marcos Díaz]

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.gutson at 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.sherrill at oarcorp.com>
> wrote:
>>
>>
>>
>> On December 17, 2014 8:00:50 AM PST, Hesham Moustafa <
>> heshamelmatary at 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 at rtems.org
>> >http://lists.rtems.org/mailman/listinfo/devel
>>
>> --joel
>> _______________________________________________
>> devel mailing list
>> devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141217/7509af68/attachment-0002.html>