call statements - use them or lose them?

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?

 

Hello,

Thats true if...

you have practically no memory limitations...

but you should use it to avoid duplication of code.

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

 

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

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.

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.

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

 

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

 

YES!

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

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.

 

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

 

And the call stack is in the "code" space???

 

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


Best regards,
Spehro Pefhany

 

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


Best regards,
Spehro Pefhany

 

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

 

"For the ultimate in deterministic behavior..."

 

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

This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

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


Best regards,
Spehro Pefhany

 

___
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!

 

I hadn't realised that the Netherlands had disappeared. Does this mean
that my sister-in-law and her dutch husband are now invisible?

;-) Ian

 

If you are just toying around, why are you using CPUs with a lot of

I guess I enjoy the PIC since it is only 14 pins, requires no external
oscillator, is fairly simple to program (only 35 op codes to learn), is
well documented, is well supported, it's fairly easy to get up and
running, the tools for it are free, and it's cheap.

I'm open to suggestions though. What do you have in mind?

 

Hello,

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

Regards, Kurt

 

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.