Tamas Rudnai wrote:
> Nope :-) I have to admit that in some cases the stack is worse in the
> way that it is quite hard to calculate the usage by hand. In the
> worse case the stack overwrites RAM area that was used for static
> data - for example the stack is built from the top RAM to towards the
> bottom, while the static variables or heap is from the bottom to the
> top, and in worse case the stack can grow that much that it
> overwrites some data from the static or heap area. Considering this
> it is better to use a more predictable method, like this "static
> stack".

Both are completely predictable and use the same size if you assume the
worst case.  In no case do you need a dynamic stack that exceeds a "static
stack" in size if it was properly derived by analysing the worst case path
of the call tree.

The point was that due to program logic, the worst case call tree may never
occur, and therefore a smaller runtime stack is in theory possible.  I agree
with Wouter that I would not normally want to take the risk of missing a
runtime call tree case.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist