call statements - use them or lose them?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I've been toying around with PIC processors for awhile and I've always
written CALL statements.  It's nice to have repeatable functions and it
makes the code easier to read.

Recently my CPU crashed and after hours of research, checking over
hardware, etc., I discovered that it actually ran out of stack space.
I suspect that I had too many levels of call statements (more than 10
deep at times).  I took out a few and fixed it.

The other day I came across a message that said to "never use CALL
statements" in assembly.  The reason is, you're relying on memory
reads/writes and memory on PICs can and will fail leading to hours of
troubleshooting and/or strange operation (kind of like my experience).

Should this be a major concern?  Should I remove the CALL statements
and just use sloppy GOTOs instead?  Or was the author overboard?


Re: call statements - use them or lose them?
Hello,


Quoted text here. Click to load it

Thats true if...
 
Quoted text here. Click to load it

you have practically no memory limitations...
 
Quoted text here. Click to load it

but you should use it to avoid duplication of code.
 
Quoted text here. Click to load it

Using gotos would result in much more code, which may not fit into your
EEPROM/FLASH. So use subroutines when code is duplicated, but not for
nested structuring of your code. It may still be feasable to use one
level for structuring.

Regards, Kurt
--
Kurt Harders
PiN -Präsenz im Netz GITmbH
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
On 5 Jan 2006 07:41:18 -0800 in comp.arch.embedded, "Pokey"

Quoted text here. Click to load it

I haven't messed with PICs for a while, but...

Quoted text here. Click to load it

OK


IIRC, most of the PIC16 family only have 8 levels of stack, including
interrupts.  Structuring your code with call/ret isn't a really good
option.

Quoted text here. Click to load it

If a function is called from only one location, it probably makes
sense to goto rather than call it (and goto rather than ret at the end
of the function).  

Or simply write it in-line.  This will save even the goto
instructions, though it may make the code harder to read.  The C
compiler I used (CCS) would do this automatically -- even though the C
code indicated a function was being called, the code was plunked
in-line at the machine code level..

But calling utility functions, functions that are called from more
than one location, is a serious win.  It not only saves memory, it
simplifies maintenance by eliminating duplicated code.

Quoted text here. Click to load it

Overboard.

The "reason" given is nonsense.  Memory can fail in any device, and if
you can't trust your memory to hold an address long enough to return
to the right place, you can't trust it to do simple arithmetic either.
Following his advice would mean abandoning the interrupt mechanism as
well, or avoiding jump tables (which are the only means of
implementing tables of constants in the PIC).

Regards,
                                        -=Dave

--
Change is inevitable, progress is not.

Re: call statements - use them or lose them?

Quoted text here. Click to load it

When you are using a PIC with limited stack space, you have to check
for yourself that you are not calling too many levels deep.  You
cannot program as if you were writing for a PC when you do embedded
systems programming.  It is worth noting that if you use C, the CCS
compiler (and probably most others too) will analyze the calling tree
and report the depth of stack used.  Also, a C compiler will often
optimize away a call by replacing it with a goto or by placing the
called function inline.



-Robert Scott
 Ypsilanti, Michigan

Re: call statements - use them or lose them?

Quoted text here. Click to load it

Yow!

Quoted text here. Click to load it

YES!

If memory reads/writes on PICs are not reliable, then you
bloody well better be concerned.

Quoted text here. Click to load it

If memory reads/writes aren't reliable it really doesn't matter
what sort of code you write.  Might well just fill the code
space with NOOPs and call it done.

--
Grant Edwards                   grante             Yow!  It's so OBVIOUS!!
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?

Quoted text here. Click to load it

Yes indeed. What are you (the OP) talking about?
If your micro can't read and write it's own memory, you're pretty well
screwed no matter what kind of code you write...

Bob


Re: call statements - use them or lose them?
On Thu, 5 Jan 2006 10:11:19 -0800, the renowned Bob Stephens

Quoted text here. Click to load it

Many a PIC can't read or write its own code memory, being Hahvahd and
all.  


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
On Thu, 05 Jan 2006 19:48:34 -0000, the renowned Grant Edwards

Quoted text here. Click to load it

;-) Well, it's not in the data memory space.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
On Thu, 05 Jan 2006 15:23:54 -0500, Spehro Pefhany

Quoted text here. Click to load it
___
Here's a snippet from the datasheet for the 16F688 PIC:

From page 19 of 16F688 datasheet:

"2.3.2 STACK
The PIC16F688 family has an 8-level x 13-bit wide
hardware stack (see Figure 2-1). The stack space is
not part of either program or data space and the stack
pointer is not readable or writable. The PC is PUSHed
onto the stack when a CALL instruction is executed or
an interrupt causes a branch. The stack is POPed in
the event of a RETURN, RETLW or a RETFIE
instruction execution. PCLATH is not affected by a
PUSH or POP operation.
The stack operates as a circular buffer. This means that
after the stack has been PUSHed eight times, the ninth
push overwrites the value that was stored from the first
push. The tenth push overwrites the second push (and
so on).

Note 1: There are no Status bits to indicate stack
overflow or stack underflow conditions.
2: There are no instructions/mnemonics
called PUSH or POP. These are actions
that occur from the execution of the
CALL, RETURN, RETLW and RETFIE
instructions or the vectoring to an
interrupt address."

Looks like it's located in Netherland and can't be seen or touched.
Jest watch your CALLS and INTS, Matey.  ARGGGH!

Re: call statements - use them or lose them?

Quoted text here. Click to load it

The nice thing about this feature is that it does not matter from
where you call a subroutine, when you return you always return
to the same address :-)

Regards
  Anton Erasmus

Re: call statements - use them or lose them?

Quoted text here. Click to load it

"For the ultimate in deterministic behavior..."

--
Grant Edwards                   grante             Yow!  Eisenhower!! Your
                                  at               mimeograph machine upsets
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
On Thu, 05 Jan 2006 21:01:18 -0000, the renowned Grant Edwards

Quoted text here. Click to load it

If you prohibit recursion then some stuff like that might actually be
possible.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
Quoted text here. Click to load it

If you are just toying around, why are you using CPUs with  a lot of
limitations?
Waste of time...
A CPU with a stack and 512-1024 byte of SRAM will be virtually unlimited for
assembly CALLs.

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?
Hello,


Quoted text here. Click to load it

All this is true for Atmel ATMega too. And the C development is much
cheaper and has a vera nice IDE: eclipse.

Regards, Kurt
--
Kurt Harders
PiN -Präsenz im Netz GITmbH
We've slightly trimmed the long signature. Click to see the full one.
Re: call statements - use them or lose them?


Quoted text here. Click to load it

Eclipse baffles me. There are thousands of downloadable items, but
there is no obvious distinction between complete standalone programs vs
plugins or what-have-you. You have to know the secret code name
identifying whatever project you're interested in, and guess from the
written-by-cognoscenti documentation what else is required.

I was told it's a great IDE for working on embedded C projects, but
after downloading a couple of hundred megabytes of files, I've yet to
get it to do anything at all. Typical of Java software, really.


Site Timeline