This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001344] Allow nc_test_slave for lwIP to compile for targetswith 128KiB RAM.
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Wed, 16 May 2012 17:03:39 +0100
- Subject: [Bug 1001344] Allow nc_test_slave for lwIP to compile for targetswith 128KiB RAM.
- Auto-submitted: auto-generated
- References: <bug-1001344-777@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001344
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1754|0 |1
is obsolete| |
--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-16 17:03:32 BST ---
Created an attachment (id=1759)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1759)
Reduce stack usage of nc_test_slave fix MAX_BUF 20110516
(In reply to comment #20)
> 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.
You're right, it may make difference with targets with small memory. My figures
for both buffer and stack sizes come from early experiments. I should have
revised them.
>
> 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.
>
Indeed, measurement often offers the best guess :) I just did it for Kinetis
target and here's the printout:
Stack: MINIMUM == 1360, TYPICAL == 3920
Stack usage:
IDLE thread: 340
Background load threads: 244 200 252 252 200
Main thread : 264
Looks like we have pretty much large margin with CYGNUM_HAL_STACK_SIZE_MINIMUM.
Then we might use the attached patch with minimal changes.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.