GCBASIC is putting "btsfc" at the end of one of the sysloops of the compiled code. I have no idea why, it's doing it on each compile today (but not lastnight). If i change the part of the code that is causing it, a totally different error pops up in the assembly file. I don't know why; but the error seems fixable from the assembly file.
How do I send my modified (only one line modifed) .asm file to MPASM like GCBASIC does?
If i use the MPASMWIN program that comes with MPLAB, it shoots out so many errors it's not even funny -- but when GCBASIC does the same file through MPASM, it only see's error on that one line.
Thank you. I'd post the code, but its 700 lines right now. Code has compiled with out asm errors until now, and almost no code has changed. I'm backtracking my steps, and I'll report my findings later. But right now, this seems like an easy, manual fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it's this ELSE in this IF statement causing the problem:
sub Set_Options(ReturningWithPHC)
'ReturningWithPHC = 0 when first entered. When EnterPHC gets the PHC and comes back to here, it will = 1 (if 1, that means code is GOOD!)
'indicate to user that they are in Options mode:
if ReturningWithPHC = 0 then
repeat 3
HPWM 1, Tone_Frequency, DutyCycle
wait 100 ms
pwmoff
wait 100 ms
end repeat
EnterPHC(0) 'Get PHC
'since key 1 and key 4 were pressed
'these caused the original error (but not when IF statement was commented out!)
wait until key_1 off
wait until key_4 off
else 'if ReturingWithPHC = 1 (code is good)
'start looking for options keypresses:
'Once PHC is verified, continue to set options:
'If here, that means PHC is verified already.
end if
end sub
And that's the code causing the problem. I have circumvented the problem, however, my original question stands. How the heck would I go about doing that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most likely you have hit 2048 word page limit for 'call', 'goto' instructions. You may try inserting the '#option lcall' instruction prior to main, hopefully that will work for you. Search for the lcall in forums will reveal previous posts on this.
If that doesn't work for you, you could try manually inserting the recommended work around by Microchip. This is explained in the memory organization section of the Microchip appnote PICmicro MID-RANGE MCU FAMILY.
Question 1: Program execution seems to get lost.
Answer 1:
When a device with more then 2K words of program memory is used, the calling of subroutines
may require that the PCLATH register be loaded prior to the CALL (or GOTO) instruction to specify
the correct program memory page that the routine is located on. The following instructions will
correctly load PCLATH register, regardless of the program memory location of the label SUB_1.
MOVLW HIGH (SUB_1) ; Select Program Memory Page of
MOVWF PCLATH ; Routine.
CALL SUB_1 ; Call the desired routine
:
:
SUB_1 : ; Start of routine
:
RETURN ; Return from routine
My lazy mans approach to this is using the 18f devices for larger programs (i.e. no paging limitation) :-).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. When i used the #option lcall my program doesn't work at all.
I found that setting one of my variables as a bit, instead of a byte, caused the previous problems with GCBASIC. But as my program continues to grow, I wonder about program size. How do I know how much space is being used on my PIC16F690 with my program?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your programmer window should give you an indication of how much program memory is used. On my PicKit 2, the unused program memory registers are shown as 3FFF, converting the hex row number gives me the memory used up to that point.
Your explanation of one too many If (or?)commands described the exact same unstable behavior I experienced with the paging problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wow, my program is right now (after a lot of optimization) at row 7F0 (2032 bytes) according to PICKIT 2. WOW thats close to the 2048 page limit.
However, my 16F690 has alot more memory, and I am trying to use that #option lcall. It's clearly adding a ton more code (by looking at the memory window in PICKIT2), however, it is not fixing anything??? It just makes my code not work at all.
With it like it is, my code becomes unstable. Am I not properly implementing that option?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GCBASIC is putting "btsfc" at the end of one of the sysloops of the compiled code. I have no idea why, it's doing it on each compile today (but not lastnight). If i change the part of the code that is causing it, a totally different error pops up in the assembly file. I don't know why; but the error seems fixable from the assembly file.
How do I send my modified (only one line modifed) .asm file to MPASM like GCBASIC does?
If i use the MPASMWIN program that comes with MPLAB, it shoots out so many errors it's not even funny -- but when GCBASIC does the same file through MPASM, it only see's error on that one line.
Thank you. I'd post the code, but its 700 lines right now. Code has compiled with out asm errors until now, and almost no code has changed. I'm backtracking my steps, and I'll report my findings later. But right now, this seems like an easy, manual fix.
it's this ELSE in this IF statement causing the problem:
sub Set_Options(ReturningWithPHC)
'ReturningWithPHC = 0 when first entered. When EnterPHC gets the PHC and comes back to here, it will = 1 (if 1, that means code is GOOD!)
'indicate to user that they are in Options mode:
if ReturningWithPHC = 0 then
repeat 3
HPWM 1, Tone_Frequency, DutyCycle
wait 100 ms
pwmoff
wait 100 ms
end repeat
EnterPHC(0) 'Get PHC
'since key 1 and key 4 were pressed
'these caused the original error (but not when IF statement was commented out!)
wait until key_1 off
wait until key_4 off
else 'if ReturingWithPHC = 1 (code is good)
'start looking for options keypresses:
'Once PHC is verified, continue to set options:
'If here, that means PHC is verified already.
end if
end sub
And that's the code causing the problem. I have circumvented the problem, however, my original question stands. How the heck would I go about doing that?
I am finding any use of Case Select or If statements in my program are causing problems such as:
ASM: Error[113] C:\PROGRA~1\GCBASIC\COMPILED.ASM 622 : Symbol not previously defined (SYSBITVAR0)
Is there a limit to program size in GCBASIC? Problems persist no matter what. Using latest version of GCBASIC.
Hello,
I do not use the MPASMWIN program, I use the MPLAB IDE. Maybe following my procedure below would give a different result.
Mark.
-------
I generate the .asm from the .gc file
Then I move the .asm into a short directory such as C:\tmp_compile_asm
Then ...
Start the MPLAB IDE (click on shortcut)
MPLAB
-----
MENU: Programmer, Select Programmer, PIC Start Plus
MENU: Programmer, Enable Programmer
(ignore Firmware notes output)
MENU: File Open ( Look in C:\tmp_compile_asm )
Choose: <program>.asm
Click: [Open]
Click on the Window for the <program>.asm to bring it into focus.
MENU: Project, Quickbuild <program>.asm
(watch for "BUILD SUCCEEDED")
MENU: Programmer, Program
(red LED on board will light up)
(watch for "Programming/Verification completed successfully")
Most likely you have hit 2048 word page limit for 'call', 'goto' instructions. You may try inserting the '#option lcall' instruction prior to main, hopefully that will work for you. Search for the lcall in forums will reveal previous posts on this.
If that doesn't work for you, you could try manually inserting the recommended work around by Microchip. This is explained in the memory organization section of the Microchip appnote PICmicro MID-RANGE MCU FAMILY.
Question 1: Program execution seems to get lost.
Answer 1:
When a device with more then 2K words of program memory is used, the calling of subroutines
may require that the PCLATH register be loaded prior to the CALL (or GOTO) instruction to specify
the correct program memory page that the routine is located on. The following instructions will
correctly load PCLATH register, regardless of the program memory location of the label SUB_1.
MOVLW HIGH (SUB_1) ; Select Program Memory Page of
MOVWF PCLATH ; Routine.
CALL SUB_1 ; Call the desired routine
:
:
SUB_1 : ; Start of routine
:
RETURN ; Return from routine
My lazy mans approach to this is using the 18f devices for larger programs (i.e. no paging limitation) :-).
Interesting. When i used the #option lcall my program doesn't work at all.
I found that setting one of my variables as a bit, instead of a byte, caused the previous problems with GCBASIC. But as my program continues to grow, I wonder about program size. How do I know how much space is being used on my PIC16F690 with my program?
Your programmer window should give you an indication of how much program memory is used. On my PicKit 2, the unused program memory registers are shown as 3FFF, converting the hex row number gives me the memory used up to that point.
Your explanation of one too many If (or?)commands described the exact same unstable behavior I experienced with the paging problem.
wow, my program is right now (after a lot of optimization) at row 7F0 (2032 bytes) according to PICKIT 2. WOW thats close to the 2048 page limit.
However, my 16F690 has alot more memory, and I am trying to use that #option lcall. It's clearly adding a ton more code (by looking at the memory window in PICKIT2), however, it is not fixing anything??? It just makes my code not work at all.
With it like it is, my code becomes unstable. Am I not properly implementing that option?