Searching \ for '[PIC]: More than 9 stacks on the 16F877' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'More than 9 stacks on the 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: More than 9 stacks on the 16F877'
2002\07\30@131636 by Robert E. Griffith

flavicon
face
I have read several places – CSS C documentation, and a book on PICs, that
you should not allow the number of stacks use by a program running on a
mid-range PIC (like the 16F877 I am using) to grow to more than 9, but
neither place says why.  Whenever I have a bug that I have a hard time
tracking down, I beat my stack usage back down to 9, but so far, that has
never been the cure – I eventually find some other source for the problem.
Now I cannot fit all my features into the program unless I allow the stacks
to climb to 11 (9 main + 2 intr).  Am I asking for trouble by allowing this?

I am just beginning to understand how the (simulated) stack on the PIC
works.  The compiler reports about 75% (85% worst case) RAM usage.  So isn’t
it allocating variable space for all 11 stacks and finding that it occupies
only 85% available RAM?  Why is the depth of the stack important at all?

Thanks,

--BoBG

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\07\30@133004 by Dipperstein, Michael

face picon face
> From: Robert E. Griffith [.....bobKILLspamspam@spam@JUNGA.COM]
> Sent: Tuesday, July 30, 2002 10:16 AM
>
> I have read several places - CSS C documentation, and a book
> on PICs, that
> you should not allow the number of stacks use by a program
> running on a
> mid-range PIC (like the 16F877 I am using) to grow to more than 9, but
> neither place says why.  Whenever I have a bug that I have a hard time
> tracking down, I beat my stack usage back down to 9, but so
> far, that has
> never been the cure - I eventually find some other source for
> the problem.
> Now I cannot fit all my features into the program unless I
> allow the stacks
> to climb to 11 (9 main + 2 intr).  Am I asking for trouble by
> allowing this?

You may very well be asking for trouble.  The mid-range PICs have an 8 address
cyclic stack in hardware.  Every call pushes a return address on the stack.
Pushing the 9th call address on the stack overwrites the first address on the
stack.  If you never plan on returning from your first call, it's not a big
deal.  If you do plan on returning, you are asking for trouble.

If you have the instruction space I recommend that you write some of your
functions inline.  If you don't have the instruction space, think about using a
PIC18F452.

-Mike

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\07\30@133159 by Kieren Johnstone

picon face
It's a hardware stack, when you CALL an address the chip automatically
pushes the current address onto the stack, but the size is limited, maybe to
save chip space (??) but probably because implementing larger stacks
wouldn't be widely used (on such a small device)...

-Kieren

{Original Message removed}

2002\07\30@140609 by Dwayne Reid

flavicon
face
At 01:15 PM 7/30/02 -0400, Robert E. Griffith wrote:
>I have read several places ­ CSS C documentation, and a book on PICs, that
>you should not allow the number of stacks use by a program running on a
>mid-range PIC (like the 16F877 I am using) to grow to more than 9, but
>neither place says why.

The stack is hardware and is 8 levels deep.  Warning: it is NOT 9 levels: only 8 levels deep!

>   Whenever I have a bug that I have a hard time
>tracking down, I beat my stack usage back down to 9, but so far, that has
>never been the cure ­ I eventually find some other source for the problem.
>Now I cannot fit all my features into the program unless I allow the stacks
>to climb to 11 (9 main + 2 intr).
>Am I asking for trouble by allowing this?

Yep - burn and crash time

>I am just beginning to understand how the (simulated) stack on the PIC
>works.  The compiler reports about 75% (85% worst case) RAM usage.  So isn’t
>it allocating variable space for all 11 stacks and finding that it occupies
>only 85% available RAM?

Again - the stack space is a set of dedicated hardware registers.  They are not related to user RAM in any way.

>   Why is the depth of the stack important at all?

Um . . . you really need to study the data sheet for the device you are working with.  But in a nutshell, the stack stores the return addresses for your subroutines.  It can only store 8 addresses.

dwayne

--
Dwayne Reid   <.....dwaynerKILLspamspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2002\07\30@164400 by Sid Weaver

picon face
For Robert Griffith

You might be able to get away from your problem by using "goto" at the end of
your subroutines instead of "return".  You would have to create special
labels for the goto, but they don't take up much room  - just a thought.

Sid

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\07\30@231815 by Robert E. Griffith

flavicon
face
Thanks to everyone who responded.  I am getting it now.  The simulated
stack(s) area that CCS C creates to store function parameters is completely
separate from mechanism to save the return IP.  The PIC's real stack it only
8 instruction words long and is only used to save the IP - not parameters.
I was assuming that the code that CCS generates explicitly saves the IP in
the same area that it puts aside for function parameters.  It did not seem
that efficient, but then again this whole 'no parameter stack' thing seems
pretty foreign to me.

In light of what I now know, it seems strange that CCS would create a
program that can use 13 stacks with out a warning.  It is good that it
allows you to create the code because you might be dealing with it in some
way, but it should at least call it to your attention.

--BobG

P.S. Dwayne, I refer to the 16F877's data sheet often, but it's sometimes
hard to get the larger context of a problem from the data sheet.  You may be
surprised to find out that many other uP's implement the call stack
differently than the PIC.  I am also reading a book on PIC architecture, and
will no doubt get to the stack soon:)

{Original Message removed}

2002\07\31@041720 by Wouter van Ooijen

picon face
> The stack is hardware and is 8 levels deep.  Warning: it is
> NOT 9 levels: only 8 levels deep!

The 9 levels might come from confusion with the SX, which has (in native
mode) 8 levels + one level for the interrupt (which is not execatly the
same as 9 levels: without interrupt you are still limited to 8 levels).

Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\07\31@131133 by Barry Gershenfeld

face picon face
Are you being careful to differentiate between "number of stacks"
and "entries in a stack"?  The PIC has just the one stack, but
you seem to be telling us CCS will create multiple stacks
by managing its own stack pointers.   Which is fine except I
have the CCS manual here and a search on the word "stacks"
turns up nothing.  A search on "stack" just talks about the
hardware stack.  So I guess I have to ask which compiler
this is.  CCS-C? for the 16- series?   Can you give us a
phrase from the book or a page number?

I don't think I can even get at the return addresses, the
PIC being of Harvard architecture and all that.

By the way, the statement I found in bhe book was "less
than 9", not "more".

Barry


At 11:16 PM 7/30/02 -0400, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\07\31@140153 by Dwayne Reid

flavicon
face
At 11:16 PM 7/30/02 -0400, Robert E. Griffith wrote:

>P.S. Dwayne, I refer to the 16F877's data sheet often, but it's sometimes
>hard to get the larger context of a problem from the data sheet.

I didn't mean to suggest otherwise - its just that the data sheet details
all that info in one place rather than you having to get it all in bits and
pieces.  And I agree - it is a *lot* of information to digest.

>  You may be surprised to find out that many other uP's implement the call
> stack
>differently than the PIC.

Not really - the first machine I ever programmed was the 6800, followed by
most of its variants, DEC's PDP11 and a variety of other small micros.  The
only reason I switched to the PIC was because I got burned by Motorola's
parts allocation problems one too many times.  Haven't done a design based
upon a Motorola micro since . . .

dwayne

--
Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\07\31@141038 by Robert E. Griffith

flavicon
face
I was being loose with my terminology - I guess as a result of being in that
fuzzy state where understanding was just occurring.

1) I have a hard time not calling the space where C function parameters are
stored the 'stack'.  I now believe that CCS C just reserves global RAM
locations for parameters and that it is not a stack at all.  (I guess I
should call RAM locations "registers", but that is something else which is
hard for me to do) I assume that they do some call analysis to determine
when they can reuse a location for parameters from different functions.

2) When I used the term "number of stacks", I was really referring to
"number of stack frames".  I thought I was using the terminology of CCS's
list file, but when I went back just now to look, I see that I was
misinterpreting it.  It lists, "Stack: 9...".  Because does not explicitly
state "Stack levels: 9..." or "Stack entries: 9...", I interpreted that as
PIC terminology for the same thing.  I guess they were just being brief
(nothing wrong with that)

I understand now, that "stack frame" does not apply to the PIC (at least
with CCS).

--BobG

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...