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

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.


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