This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targetswith 128KiB RAM.


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001344

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #20 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-16 01:28:19 BST ---
First, as per bug 1001586 (specifically:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001586#c5 ), I would have
thought the buffer sizes could be smaller: 10240+16+maybe a little more just in
case.

As for the general idea with this patch, I think it is unwise to use fixed
constant sizes for stacks. It's doomed, especially once you involve other, more
stack hungry, architectures than ARM or Cortex.

To get smaller stacks I would suggest starting from
CYGNUM_HAL_STACK_SIZE_MINIMUM, and adding on some numbers of multiples of
CYGNUM_HAL_STACK_FRAME_SIZE plus an extra constant to roughly cover the stack
local variables in the call frame you think you are likely to get, and then add
some more for safety. You can do it so that the numbers you get come out as the
fixed constants you've already determined work for you on the Kinetis, but it
at least means it's more likely to continue to work on other targets. You may
find CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT useful to better inform your
decisions.

Alternatively start from CYGNUM_HAL_STACK_SIZE_TYPICAL and reduce it, but I
think that's a bit riskier, as there's no fixed idea of what is typical, in a
way that makes it easy to reduce.

But I wouldn't just say e.g. "4096", because that's never going to be portable
- for some targets it's excessive, for others it may be too small. The problems
you are seeing with the synth target are probably a symptom of this.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]