1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

call statements - use them or lose them?

Discussion in 'Embedded' started by Pokey, Jan 5, 2006.

  1. Pokey

    Pokey Guest

    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?
     
    Pokey, Jan 5, 2006
    #1
    1. Advertisements

  2. Pokey

    Kurt Harders Guest

    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
     
    Kurt Harders, Jan 5, 2006
    #2
    1. Advertisements

  3. Pokey

    Dave Hansen Guest

    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
     
    Dave Hansen, Jan 5, 2006
    #3
  4. Pokey

    Robert Scott Guest

    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
     
    Robert Scott, Jan 5, 2006
    #4
  5. 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.
     
    Grant Edwards, Jan 5, 2006
    #5
  6. Pokey

    Bob Stephens Guest

    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
     
    Bob Stephens, Jan 5, 2006
    #6
  7. And the call stack is in the "code" space???
     
    Grant Edwards, Jan 5, 2006
    #7
  8. Many a PIC can't read or write its own code memory, being Hahvahd and
    all.


    Best regards,
    Spehro Pefhany
     
    Spehro Pefhany, Jan 5, 2006
    #8
  9. ;-) Well, it's not in the data memory space.


    Best regards,
    Spehro Pefhany
     
    Spehro Pefhany, Jan 5, 2006
    #9
  10. 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
     
    Anton Erasmus, Jan 5, 2006
    #10
  11. "For the ultimate in deterministic behavior..."
     
    Grant Edwards, Jan 5, 2006
    #11
  12. 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
     
    Ulf Samuelsson, Jan 5, 2006
    #12
  13. If you prohibit recursion then some stuff like that might actually be
    possible.


    Best regards,
    Spehro Pefhany
     
    Spehro Pefhany, Jan 5, 2006
    #13
  14. Pokey

    Charles Jean Guest

    ___
    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!
     
    Charles Jean, Jan 6, 2006
    #14
  15. Pokey

    ian_okey Guest

    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
     
    ian_okey, Jan 6, 2006
    #15
  16. Pokey

    Pokey Guest

    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?
     
    Pokey, Jan 6, 2006
    #16
  17. Pokey

    Kurt Harders Guest

    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
     
    Kurt Harders, Jan 7, 2006
    #17
  18. Pokey

    larwe Guest

    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.
     
    larwe, Jan 9, 2006
    #18
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.