1:2 0 Call stack overflow

[ascomm]

1:2 0 Call stack overflow

What does it mean?

Code: Select all

/*   Fillarimittari
     Polkupyörän matka- / matka-aikamittari
      - PIC16F876 @ 8MHz
      - 2x16 LCD näyttö

*/

static unsigned CIRC = 2064;          // Renkaan ympärysmitta (mm)
static unsigned long TRIP = 0;             // Osamatka
static unsigned TIME = 0;             // Osa-aika
static float SPEED = 0;            // Nykyinen nopeus
static float TOPSPEED = 0;         // Huippunopeus

void alustus()
{

  Lcd_Init(&PORTB);
  Lcd_Cmd(Lcd_CLEAR);
  Lcd_Cmd(Lcd_CURSOR_OFF);
  Lcd_Out(1, 1, "-Fillarimittari-");
  INTCON.INTE = 1;                   // Enable INTE (RB0 external interrupt)
  INTCON.GIE = 1;
  &TRISB  = 0b00000001;               // RB0 is input
  &TRISC  = 0b00000000;
  PORTC = 0;
  Delay_ms(2000);
}

void interrupt()
{
  INTCON.INTF = 0;                    // clear INTF
  INTCON.INTE = 0;                    // disable external interrupts
  TRIP = TRIP + CIRC;
  PORTC = 2;
  INTCON.INTE = 1;                    // Enable INTE
}

void main(void)
{
  float TRIP2;
  char *txt;
  alustus();

  while (1)
  {
     Lcd_Out(1, 1, "23,6  19,4  56,8");
     TRIP2 = TRIP /100000;
     FloatToStr(TRIP2,txt);
     Lcd_Out(2, 1, txt);
  }

}

[rajkovic]

1:2 0 Call stack overflow

What does it mean?

this is part of help (pic specific chapter)

Nested Calls Limitations
Nested call represents a function call within function body, either to itself (recursive calls) or to another function. Recursive calls, as form of cross-calling, are unsupported by mikroC due to the PIC’s stack and memory limitations.

mikroC limits the number of non-recursive nested calls to:

8 calls for PIC12 family,
8 calls for PIC16 family,
31 calls for PIC18 family.

The number of allowed nested calls decreases by one if you use any of the following operators in the code: * / %. It further decreases by one if you use interrupt in the program.

If the allowed number of nested calls is exceeded, compiler will report stack overflow error.


When we developed floattostr we have P18 family in mind so did not pay attention on call depth in floattostr we will change this soon, for now you will not be able to use FloatToStr with P16 and interrupt in the same time. I suggest to use P18 because FloatToStr is very exspensive
in terms of code size and call stack depth


[/i]

[pizon]

Compared to PC, microcontrollers in general (especially PIC16 series) have VERY limited resources. You must measure your steps byte-by-byte, both in RAM (number of variables and their reuse) and ROM (amount of code, size of individual procedures and call depth) usage. In general, you should avoid using temporary strings,

Code: Select all

 Lcd_Out(2,1, "this is a temporary string")

, use as much of local variables as possible (instead of global ones), use smaller variables (unsigned short and char) whenever possible, allocate the arrays just as much as needed (don't oversize arrays "just in case"), avoid some exotic solutions (multi-dimensional arrays, bitfields and bit-oriented variables and operations, unions, complex structures, etc.) whenever possible, etc.

[ascomm]

Yes I know that PIC's are not PC's
I was quite surprised, though, how "expensive" floating point operations are
I'll have to look other means to process speed and meter data without using floating point variables and float divisions.

[pizon]

I was quite surprised, though, how "expensive" floating point operations are

FloatToStr() is by far the floating point-related function that consumes the highest amount of memory; it utilizes power(), log(), and several string manipulation functions "under the hood". We could have done it in a less memory-consuming way, but we wouldn't be able to cover the entire range.

I'll have to look other means to process speed and meter data without using floating point variables and float divisions.

Perhaps you could try the fixed-point arithmetics. You can work with them through the basic data types (unsigned int, unsigned long) and utilize all operations that are available for those types; the only thing that would be different is to split the integer part from the fraction at the end, since they need to be treated when converting such number to a string. You can see an example for this in the "onewire" example supplied with mikroC.