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

Wed Dec 17 17:49:07 UTC 2014

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.gutson at 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.diaz at 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.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
>>
>>
>
> --
>
> 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/04460b04/attachment-0002.html>