Memory Limt

[adrian]

Hi I am compiling a program on a 16f1783 in GCBasic.
My program was working fine until I created a new variable.

The program compiles fine with the variable defined or commented out, but when defined other variables become corrupted and unpredictable. When commented out the program is stable. if I change the variable name it makes no difference (i.e I am not using a system variable name etc.)

The variable is not used anywhere in the program. I was about to add new code all I literally did was add the variable.

I have changed to a larger capacity chip 16f1788. But it makes no difference.

Is there a point where variables run out of space, and the stack overflows into the variable memory area, or is there a code boundary limit beyond which GCbasic cannot exceed.

Thanks

Adrian

[Anobium]

We can help.

I have seen this a long time ago. I mean two years ago.

Please post your code.

What version of the compiler? Date of gbasic.exe.

[edorul]

Hello,

I've exactly the same problem.

To answer to your previous questions :

• date of "gbasic.exe" = 2016-02-24

• my code is the following (note: the problem occurs when I add "DefinedCounterValue" and/or "ActualCounterValue"):

#chip 18f1330,8

#define DISPLAY_SELECT      PortA.0
#define SWITCH_UP           PortA.1
#define SWITCH_DOWN         PortA.2
#define SWITCH_ONOFF        PortA.3
#define SWITCH_STARTSTOP    PortA.4

#define DEBOUNCE_TICKS      1875 ; ~30ms
#define PRESSED             1
#define RELEASED            0

Dir PortB Out
Dir DISPLAY_SELECT Out
Dir SWITCH_UP In
Dir SWITCH_DOWN In
Dir SWITCH_ONOFF In
Dir SWITCH_STARTSTOP In

Dim Debouncing as Bit ; 1 = switch just pressed (or released, need debouncing / 0 = switch already pressed (or released) for a long time, need no more debouncing
Debouncing = 0
Dim Switch_Up_Pressed as Bit ; used as boolean 0 = False, 1 = True
Dim Switch_Down_Pressed as Bit ; used as boolean 0 = False, 1 = True
Dim Switch_OnOff_Pressed as Bit ; used as boolean 0 = False, 1 = True
Dim Switch_StartStop_Pressed as Bit ; used as boolean 0 = False, 1 = True
Switch_Up_Pressed = 0
Switch_Down_Pressed = 0
Switch_OnOff_Pressed = 0
Switch_StartStop_Pressed = 0

; automatic increment/decrement of the pose value
Dim NeedAutomatic as Bit
NeedAutomatic = 0
#define MAX_CHANGE_STEP 4
Dim NextChange_Ticks(MAX_CHANGE_STEP) ; arrays are only bytes
NextChange_Ticks = 32, 16, 8, 4
Dim NextChange_Count(MAX_CHANGE_STEP) as Byte
NextChange_Count = 4, 6, 8, 4
Dim ChangeStep as Byte ; actual step for the change
ChangeStep = 1
Dim ChangeCount as Byte ; nb of time changes occur. if > NextChange_Count then change to the upper NextChange_Ticks
ChangeCount = 0

; 7 segments display
Dim Digit as byte
Dim Display(10) ; 0 = Allumé, 1 = éteint
Display(1) = b'00000100'
Display(2) = b'00001000'
Digit = 1
PortB = Display(Digit)

; counter pose value
Dim DefinedCounterValue as Word ; counter pose value defined with Up & Down switches: 1/10s * 10 (e.g. 15 = 1.5s, 150 = 15s)
Dim ActualCounterValue as Word ; actual counter pose value when ON: 1/10s * 10 (e.g. 15 = 1.5s, 150 = 15s)
DefinedCounterValue = 20 ; ### in final program it will be stored in EEPROM
ActualCounterValue = DefinedCounterValue

; Timer0: 16 bits + PS0_32 ~ 1s for TimerOverflow => 1 tick = 16µs
#define TMR0_16bit
InitTimer0 Osc, PS0_32 ; start the timer automatically

do
    ; switches just pressed
    if (SWITCH_UP = PRESSED) and (Switch_Up_Pressed = 0) Then
    Switch_Up_Pressed = 1
    Debouncing = 1
    NeedAutomatic = 1
    ChangeStep = 1
    ChangeCount = 0
    ClearTimer 0
  end if

    ; switches just released
    if (SWITCH_UP = REALEASED) and (Switch_Up_Pressed = 1) Then
    Switch_Up_Pressed = 0
    Debouncing = 1
    NeedAutomatic = 0
    ClearTimer 0
  end if

    ; handle debounce
  if (Timer0() > DEBOUNCE_TICKS) and (Debouncing = 1) Then
    Debouncing = 0
    if (Switch_Up_Pressed = 1) Then
        PortB = Display(Digit+1)
            Digit = (Digit + 1)%2
    end if
  end if

  ; handle automatic increment/decrement of the pose value
    if (NeedAutomatic = 1) Then
    if (Timer0() > NextChange_Ticks(ChangeStep)*1000) and (Debouncing = 0) Then
        if (Switch_Up_Pressed = 1) Then
        ; increment
        PortB = Display(Digit+1) ; ###temp
        Digit = (Digit + 1)%2 ; ###temp
      end if
        if (Switch_Down_Pressed = 1) Then
        ; decrement
        ; ### todo
      end if
      ChangeCount = ChangeCount + 1
      ClearTimer 0
            if (ChangeCount > NextChange_Count(ChangeStep)) Then
        ChangeCount = 0
        ChangeStep = ChangeStep + 1
        if (ChangeStep > MAX_CHANGE_STEP) Then
            ChangeStep = MAX_CHANGE_STEP
        end if
      end if
    end if
  end if
loop

Best regards,
Edorul

[Anobium]

Please send me a personal message. THis is is fixed in the current build. I will send you the pre-release version.

I have just test compiled, as follows.

20:46:41 G+Stool-COMPILE/ASSEMBLE, processing C:\GCB@Syn\G+Stools\makeHEX.bat
Source-File = C:\TEMP\memissue.gcb
Target-File = C:\TEMP\memissue.hex
6.3 Sec. Compiler Version: 0.95 2016-05-23 Program Memory: 352/4096 words (8.59%) RAM: 37/256 bytes (14.45%) Chip: 18F1330

Anobium

[edorul]

Hello,

Thanks for your reply.

But, I haven't a compilation problem. As said "Adrian" (the creator of this post): "The program compiles fine with the variable defined or commented out, but when defined other variables become corrupted and unpredictable."

Anyway, I'll try with the latest build. I'll send you a private message.

Best regards,
Edorul

[William Roth]

Hi edorul ,

As a test to help isolate the problem, please try changing all bit variables to byte variables and let us know if anything changes.

Also, please attach your ASM code so that we can analyze.

Thanks

William

[edorul]

Hello William,

I've tested with "Byte" variables instead of "Bit" ones, and I've the same strange behaviour.

As asked I join the ASM files (one with the "Bit" variables, the other with the "Byte" variables and the "gbc" file too).

Thanks :-)
Edorul

[William Roth]

Edorul,

Thank you, We will analyze these

Attached is a HEX file of your program for testing. Please program the PIC with this HEX and let us know the results. - William

Are only certain variables or variable types corrupted? if so, which ones?

[edorul]

Sorry but with this new "hex" file I have the same problem :-(

About weird behaviour, I've made some experiments and it seems that the problem comes from SWITCH_UP (=PortA.1): it is always detected as PRESSED (=1) even when the switch is released.
So it's not a variable problem but a port problem...

[William Roth]

I tested on 18F25K22 and PortA.1 works ok. I suspect that this is not a compiler problem but let's make sure other stuff is ok first.

1. Defined Constant "Released" is misspelled as REALEASED. Need to correct this first.

2. Check wiring. Make sure there is a 10K pulldown resistor on all switch pins that are active high.

3. Measure Voltage at PORTA.1. (Pin3) Does it change from 0V to 5V when button is pressed?

4. Review the use of braces in your code. Many are unnecessary

Example1: " If timer0 () > "
These braces are not necessary and should be simply "If timer 0 >"

William

Edit. Corrected spelling of "misspelled" :)

[edorul]

Hello William,

You've found the problem!!! It's just the misspell of "RELEASED" in the code which causes all my troubles (furthermore I've made the same misspelling when I've tested all my variables and ports) :-(

But it's weird that my code doesn't work as soon as I create a new variable... perhaps "REALEASED" was defined as 0x00 by default (as "RELEASED" is defined as 0x00, but on purpose) until the memory was rearanged when new variables were created ? And then it's default value has became something else than 0x00?????

Anyway thanks a lot for you help and I'm sorry to have wasted your time because of a misspelling error!!!!!
(Isn't it possible to add to "Great Cow Basic" an option to force the declaration of variables before their use? Something like in FreeBasic where you can place 'Option Explicit' at the program beginning in order to avoid implicit variables declaration)

Best regards,
Edorul

[William Roth]

Glad we have a resolution.

There is an #Option Explicit in the new compiler that Evan sent you. However it is "experimental" at this time and may return errors depending upon the source code.

To avoid implicit declarations, sometimes it may be a good practice to use DIM on all user variables and then to then write a value of zero to the variable. (Before the main loop runs).
Something like:

DIM Var1 as Byte : Var1 = 0
DIM Var2 as Word : Var2 = 0

Using DIM also enables the IDE to list the variables in the "Tree" pane. This helps to keep track of variables in user code.

William

[Chuck Hellebuyck]

If you use a variable in a statement, I thought GCB automatically set it up as a byte variable so no declaration was required. Only variables other than a byte needed to be declared. Or did that change?

[Anobium]

No change. We are working on new capability. #option explicit. Do not use till we announce it is supported. As of May 2016 it is not supported.

[William Roth]

While GCB will automatically set up a byte variable without DIM, I sometimes prefer to declare variables with "DIM as" at the beginning of code, or at the begining of a sub, so that I can look at the tree pane in the IDE and see what variables have been declared. I find that this makes it it easier to keep track of variables and to manage code, especially with large programs that use lots of variables.