Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Compiler still NOT working for long programs

MBB
2012-09-16
2013-05-30
  • MBB
    MBB
    2012-09-16

    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.

     
  • ic-beau
    ic-beau
    2012-12-09

    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 ….

    BASPROGRAMSTART
    ;Call initialisation routines
                call INITSYS
    

    …and INITSYS looks something like this at the very end of the compiled.asm file …

    INITSYS
    ;movlw b'11001111'
                    movlw B'11001111'
    ;option
                    option
    ;PORTA = 0
                    clrf       PORTA 
    ;PORTB = 0
                    clrf       PORTB
                    retlw    0
    

    … 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 …

    BASPROGRAMSTART
    ;movlw b'11001111'
                    movlw B'11001111'
    ;option
                    option
    ;PORTA = 0
                    clrf       PORTA 
    ;PORTB = 0
                    clrf       PORTB
    

    … 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.  

     
  • Max
    Max
    2013-04-10

    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 ?

     
  • Max
    Max
    2013-04-23

    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 :)