I'm using a PIC16F876 which has 8k words available.
My program goes across the page boundary from page 0 to page 1. I have a working program but if I add one or more lines of code the program stops working. The extra line of code could be as simple as a LOCATE / PRINT.
I've seen previous forum posts where this issue was caused by a GOTO inside a CALLed subroutine. Code changes were made to GCBASIC to fix it…. BUT I'm still having a similar problem.
I'm using version 0.9 14/2/2010.
Is there a new fix for this?
Alternately, as a short term fix, is there a command to force ALL code after my main program onto page 1 (ORG 2048).? This would keep all the CALLS and sub-internal GOTOs on the same page.
I've also seen the suggestion about adding some number of NOPs to force the paging. Is there a way to calculate how many NOPs to add.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using a different PIC … PIC16F54, but have run into a similar problem.
I think I have a fix that is relatively painless, but it does involve looking at the compiled.asm file and making a change.
I would just re-compile the GCBASIC.EXE but I haven't found a solution yet for a FreeBasic compiler that ends up producing a valid GCBASIC.EXE. (<-Another topic)
Aside from that, what I have found to be a culprit are the lines immediately after the BASPROGRAMSTART that call INITSYS. This in and of itself isn't too much trouble, but the location of INITSYS does create a problem. The GCBASIC compiler places it at the end of your program right off the bat so this particular section is the first to cross the page boundary when your program starts growing and since it's a call the PCL doesn't get advanced properly to represent the next page.
My solution is two parts, the first part is to manually move the contents within INITSYS to BASPROGRAMSTART so that the call never needs to happen in the first place.
… Then I re-run MAKEASM.BAT, and the change is made into the compiled.hex file
That particular fix would be relatively easy to change in the GCBASIC compiler, but as I indicated, that seems to be broken on my end at the moment.
The Second part of this FIX requires a little bit of inline Assembly to perform a computed jump when crossing a boundary.
It is important to keep track of ALL of your other GOTO, GOSUB, and CALL's If they cross the page boundary… you can determine this in the compiled.lst program … if they cross the boundary then the STATUS registers bits 5 and 6 must be updated prior to adding a computed jump to the PCL. This can be done using BCF or BSF with the STATUS register followed by an ADDWF PCL,1 Fortunately this only needs to happen when you cross from one boundary to the other and back…. Again, I think this could be handled in the compiler. BTW the STATUS bits 5 and 6 remap to the PC bits 9 and 10 for the particular processor that I am using. This is also the case with many other processors, but it's best to check the datasheet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the same problem : I am using a PIC 16F876A (8k) and when compiled program with code more than 4K it doesn't work anymore . Sometime with some NOP inside the program (random position) the program work again but it is not a good solution because is impossible to know where put them .
I am using the last compiler Version: 0.9 10/3/2013.
Are there FIX for this problem ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WONDERFULL : with last update (2013 apr 21) the compiled code bigger than 4k now on 16F876A works .
the problem with memory page allocation seems to be solved :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using a PIC16F876 which has 8k words available.
My program goes across the page boundary from page 0 to page 1. I have a working program but if I add one or more lines of code the program stops working. The extra line of code could be as simple as a LOCATE / PRINT.
I've seen previous forum posts where this issue was caused by a GOTO inside a CALLed subroutine. Code changes were made to GCBASIC to fix it…. BUT I'm still having a similar problem.
I'm using version 0.9 14/2/2010.
Is there a new fix for this?
Alternately, as a short term fix, is there a command to force ALL code after my main program onto page 1 (ORG 2048).? This would keep all the CALLS and sub-internal GOTOs on the same page.
I've also seen the suggestion about adding some number of NOPs to force the paging. Is there a way to calculate how many NOPs to add.
I am using a different PIC … PIC16F54, but have run into a similar problem.
I think I have a fix that is relatively painless, but it does involve looking at the compiled.asm file and making a change.
I would just re-compile the GCBASIC.EXE but I haven't found a solution yet for a FreeBasic compiler that ends up producing a valid GCBASIC.EXE. (<-Another topic)
Aside from that, what I have found to be a culprit are the lines immediately after the BASPROGRAMSTART that call INITSYS. This in and of itself isn't too much trouble, but the location of INITSYS does create a problem. The GCBASIC compiler places it at the end of your program right off the bat so this particular section is the first to cross the page boundary when your program starts growing and since it's a call the PCL doesn't get advanced properly to represent the next page.
My solution is two parts, the first part is to manually move the contents within INITSYS to BASPROGRAMSTART so that the call never needs to happen in the first place.
i.e. if BASPROGRAMSTART currently reads ….
…and INITSYS looks something like this at the very end of the compiled.asm file …
… I simple remove the INITSYS from the end of the compiled.asm and move the contents into the BASPROGRAMSTART so that it looks something like this …
… Then I re-run MAKEASM.BAT, and the change is made into the compiled.hex file
That particular fix would be relatively easy to change in the GCBASIC compiler, but as I indicated, that seems to be broken on my end at the moment.
The Second part of this FIX requires a little bit of inline Assembly to perform a computed jump when crossing a boundary.
It is important to keep track of ALL of your other GOTO, GOSUB, and CALL's If they cross the page boundary… you can determine this in the compiled.lst program … if they cross the boundary then the STATUS registers bits 5 and 6 must be updated prior to adding a computed jump to the PCL. This can be done using BCF or BSF with the STATUS register followed by an ADDWF PCL,1 Fortunately this only needs to happen when you cross from one boundary to the other and back…. Again, I think this could be handled in the compiler. BTW the STATUS bits 5 and 6 remap to the PC bits 9 and 10 for the particular processor that I am using. This is also the case with many other processors, but it's best to check the datasheet.
I have the same problem : I am using a PIC 16F876A (8k) and when compiled program with code more than 4K it doesn't work anymore . Sometime with some NOP inside the program (random position) the program work again but it is not a good solution because is impossible to know where put them .
I am using the last compiler Version: 0.9 10/3/2013.
Are there FIX for this problem ?
WONDERFULL : with last update (2013 apr 21) the compiled code bigger than 4k now on 16F876A works .
the problem with memory page allocation seems to be solved :)