I am Testing a long program with lots of variables (more than 100) and it didnt work as espected.
Looking for the cause i see that all variables are inserted in alfabetic order in generated asm, then the SysVariables can be in 2º memory bank when there are a lot of user variables.
The problem is that SysVariables are not banked (banksel variable) in the generated asm, it looks like the banking routine of compiler only aplies to user variables, then if a SysVariable is allocated at 2º memory bank the program will not work properly.
I solved it just adding a "z" at the beginig of my variables, for example for "my_var" i used "zmy_var", then all the system variables are allocated at low adresses (Bank0) and then all my variables begining with "z", this solution worked, confirming that's the problem.
The solution to this issue could be allocating first the system variables and then the user's ones or including system variables in banking compiler's routine... or any other, i don't know wich can be the best one..
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok... i did a small test program with lot of variables to be sure where is the problem, and the banking is not the problem... the banksels are there.
Then i have not idea where is the problem, but when system variables are in Bank1 the program doesn't work properly.
this is the the code i tried, just a simple word division, the result should be = 1
First with just a few variables it works OK:
_______________________________________________________________________
#chip 16F876a, 8 'modelo de pic y velocidad de reloj
But the same thing with a lot of variables, does not wor ok, the result is 2 instead of 1, if i use diferent values for divided variables the results are for example: 1000/2 = 32000 instead of 500.
______________________________________________________________________
#chip 16F876a, 8 'modelo de pic y velocidad de reloj
dim my_var1 as word
dim my_var2 as word
dim my_var3 as word
dim my_var4 as word
dim my_var5 as word
dim my_var6 as word
dim my_var7 as word
dim my_var8 as word
dim my_var9 as word
dim my_var10 as word
dim my_var11 as word
dim my_var12 as word
dim my_var13 as word
dim my_var14 as word
dim my_var15 as word
dim my_var16 as word
dim my_var17 as word
dim my_var18 as word
dim my_var19 as word
dim my_var20 as word
dim my_var21 as word
dim my_var22 as word
dim my_var23 as word
dim my_var24 as word
dim my_var25 as word
dim my_var26 as word
dim my_var27 as word
dim my_var28 as word
dim my_var29 as word
dim my_var30 as word
dim my_var31 as word
dim my_var32 as word
dim my_var33 as word
dim my_var34 as word
dim my_var35 as word
dim my_var36 as word
dim my_var37 as word
dim my_var38 as word
dim my_var39 as word
dim my_var41 as word
dim my_var42 as word
dim my_var43 as word
dim my_var44 as word
dim my_var45 as word
dim my_var46 as word
dim my_var47 as word
dim my_var48 as word
dim my_var49 as word
dim my_result as word
Hey Santiago, I think your first assumption is correct in that GCBasic is not handling the bankselect properly is correct. Notice in the assembly if you compile an array, that the assembly will start at the top of memory bank (i.e. highest register address) and work backwards. When addressing an array register, GCBasic will use a 'bankisel'. In your example the system variables use the 'banksel', even though they are located in an upper memory bank.
If your code would allow using an array for your multitude of variables, then that would be a work around without having to force the variable names to the higher memory banks. Or you could use an 18fxxxx which has a flat memory addressing scheme (i.e. no banking), and compiles/executes your orignal code no problem. Having a 18f4620 around is a pleasure with GCBasic, and assures virtually no limitations on projects at hand.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is still a bug.
I just ran into this and put z's infront of all my variables and I can now add more DIM/Vari statements but nor sure how manyy more before it does it again. Probably just 96, once I push out of bank 1 GPR's.
I posted in help as I forgot to look here to see if anyone had a similar incident. Well this variable issue sounded just like mine.
I look in asm and sys items do not get banksel properly.
Beside switching to another chip (not happening).
Or doing all of them in an array (UGH!).
It there a fix planned, or another work around ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I thought it worked but alas it did not.
Moving/renaming alot of my vari to z allowed me to add more but after a few more my program goes haywire. Remove them and works great.
UGH!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No doubt you have found the 2k page barrier (i.e. program memory) for the 16f devices. If you missed it, Hugh has posted a new update zip just the other day, which is supposed to fix this. Try that, and post back on how that works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That made things totally WORSE.
Now none of my programs I compile will run.
They all compile no errors but do not run at all.
Get strange outputs, timers not working etc etc.
YIKES! This is not good!
This is a nightmare!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Heck of a note! Bummer, all the previous GCBasic updates have worked well. I can email an older update from 1/26/2009 as an attachment, if you failed to save the old one, or can't find it. It's been unpacked and takes up 1.23MB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kent, Hugh has not responded to my post about the new version not working. It calls sub-routines twice and the Serial quit working all together. I does not work even if you comment out the send call in the .asm file. I had to reinstall the last version! I hope Hugh gets on top of this.
Regards,Ed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also it was missing the compile.bat and the download.bat files.
I was able to go back to the previous version I had, as I actually saved it. Lucky me, so not all is lost. Whew! Thanks for the offer Kent I would have if I had not saved mine.
I understand these things can happen with updates and I am sure Hugh and you guys will work it out.
Just was a shock to update and then have it all fail.
Even the simplest program fails to run correct but compiles without errors. To many bugs now to even list.
Glad to see I was not the only one having issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The following are definitely GCBASIC bugs:
- The trouble that occurs when the SysCalcTempx variables are pushed into the second bank
- The duplicate sub calls
The first bug occurs because the various calculation routines assume that everything will be in bank 0. Because of the way that I've written them (using assembly bit test/skip instructions), the subroutines fail to work when GCBASIC inserts the bank selection code.
I've no idea what is causing the second bug, but given that the subroutine and function calling code has been completely rewritten since the last release it's not a surprise.
Unfortunately, I haven't any time to fix this immediately, but will endeavour to have a patch up by Sunday or Monday. Kent, could you please email me the last update and I'll put it back online?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K. even an 18f can have problems with ram banking. Mixing up program and ram banking, that's me! For those interested, here is a Microchip forum response that explains it. There are two relevant posts, with the one by Olin Lathrop being the best. http://www.microchip.com/forums/tm.aspx?m=376953&mpage=2&key=linker%2cram񜇤
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This bug will also affect 18Fs, but since 18Fs can access 256 bytes of RAM before any banking is needed there is a far slimmer chance of it causing trouble.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This version should keep all calculation and delay variables in the common RAM (the RAM that can be accessed without banking).
I've also dealt with the double call bug and a couple of interrupt problems. All the chip data files have been altered to include data about common RAM, so you'll need to download the full version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, now i'm very busy and have little time for PICs; i also have totally dismounted the robot to remake it; but i'll do some testing in simulator with the new update.zip and report any results.
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am Testing a long program with lots of variables (more than 100) and it didnt work as espected.
Looking for the cause i see that all variables are inserted in alfabetic order in generated asm, then the SysVariables can be in 2º memory bank when there are a lot of user variables.
The problem is that SysVariables are not banked (banksel variable) in the generated asm, it looks like the banking routine of compiler only aplies to user variables, then if a SysVariable is allocated at 2º memory bank the program will not work properly.
I solved it just adding a "z" at the beginig of my variables, for example for "my_var" i used "zmy_var", then all the system variables are allocated at low adresses (Bank0) and then all my variables begining with "z", this solution worked, confirming that's the problem.
The solution to this issue could be allocating first the system variables and then the user's ones or including system variables in banking compiler's routine... or any other, i don't know wich can be the best one..
Regards.
Ok... i did a small test program with lot of variables to be sure where is the problem, and the banking is not the problem... the banksels are there.
Then i have not idea where is the problem, but when system variables are in Bank1 the program doesn't work properly.
this is the the code i tried, just a simple word division, the result should be = 1
First with just a few variables it works OK:
_______________________________________________________________________
#chip 16F876a, 8 'modelo de pic y velocidad de reloj
#config HS_OSC, WDT_OFF, LVP_OFF, BODEN_OFF, PWRTE_ON
dim my_var1 as word
dim my_var2 as word
dim my_result as word
Dir PORTB Out
Dir PORTC Out
my_var1 = 1000
my_var2 = 1000
my_result= my_var1/my_var2
'to check the result in Port outputs:
PORTB = my_result
PORTC = my_result_H
goto $
______________________________________________________________________
But the same thing with a lot of variables, does not wor ok, the result is 2 instead of 1, if i use diferent values for divided variables the results are for example: 1000/2 = 32000 instead of 500.
______________________________________________________________________
#chip 16F876a, 8 'modelo de pic y velocidad de reloj
#config HS_OSC, WDT_OFF, LVP_OFF, BODEN_OFF, PWRTE_ON
dim my_var1 as word
dim my_var2 as word
dim my_var3 as word
dim my_var4 as word
dim my_var5 as word
dim my_var6 as word
dim my_var7 as word
dim my_var8 as word
dim my_var9 as word
dim my_var10 as word
dim my_var11 as word
dim my_var12 as word
dim my_var13 as word
dim my_var14 as word
dim my_var15 as word
dim my_var16 as word
dim my_var17 as word
dim my_var18 as word
dim my_var19 as word
dim my_var20 as word
dim my_var21 as word
dim my_var22 as word
dim my_var23 as word
dim my_var24 as word
dim my_var25 as word
dim my_var26 as word
dim my_var27 as word
dim my_var28 as word
dim my_var29 as word
dim my_var30 as word
dim my_var31 as word
dim my_var32 as word
dim my_var33 as word
dim my_var34 as word
dim my_var35 as word
dim my_var36 as word
dim my_var37 as word
dim my_var38 as word
dim my_var39 as word
dim my_var41 as word
dim my_var42 as word
dim my_var43 as word
dim my_var44 as word
dim my_var45 as word
dim my_var46 as word
dim my_var47 as word
dim my_var48 as word
dim my_var49 as word
dim my_result as word
Dir PORTB Out
Dir PORTC Out
my_var1 = 1000
my_var2 = 1000
my_result= my_var1/my_var2
PORTB = my_result
PORTC = my_result_H
goto $
Hey Santiago, I think your first assumption is correct in that GCBasic is not handling the bankselect properly is correct. Notice in the assembly if you compile an array, that the assembly will start at the top of memory bank (i.e. highest register address) and work backwards. When addressing an array register, GCBasic will use a 'bankisel'. In your example the system variables use the 'banksel', even though they are located in an upper memory bank.
If your code would allow using an array for your multitude of variables, then that would be a work around without having to force the variable names to the higher memory banks. Or you could use an 18fxxxx which has a flat memory addressing scheme (i.e. no banking), and compiles/executes your orignal code no problem. Having a 18f4620 around is a pleasure with GCBasic, and assures virtually no limitations on projects at hand.
Thanks kent.
The idea of using an array to store variables could be a good thing, i have to try it. Perhaps the ideal could be using several arrays...
Perhaps using 18f is the way to go to forget limitations.
I think it is still a bug.
I just ran into this and put z's infront of all my variables and I can now add more DIM/Vari statements but nor sure how manyy more before it does it again. Probably just 96, once I push out of bank 1 GPR's.
I posted in help as I forgot to look here to see if anyone had a similar incident. Well this variable issue sounded just like mine.
I look in asm and sys items do not get banksel properly.
Beside switching to another chip (not happening).
Or doing all of them in an array (UGH!).
It there a fix planned, or another work around ?
Ok, I thought it worked but alas it did not.
Moving/renaming alot of my vari to z allowed me to add more but after a few more my program goes haywire. Remove them and works great.
UGH!
No doubt you have found the 2k page barrier (i.e. program memory) for the 16f devices. If you missed it, Hugh has posted a new update zip just the other day, which is supposed to fix this. Try that, and post back on how that works.
Ok I went and dnld the new release.
Full release.
Made no changes to my code, compiled.
That made things totally WORSE.
Now none of my programs I compile will run.
They all compile no errors but do not run at all.
Get strange outputs, timers not working etc etc.
YIKES! This is not good!
This is a nightmare!
Heck of a note! Bummer, all the previous GCBasic updates have worked well. I can email an older update from 1/26/2009 as an attachment, if you failed to save the old one, or can't find it. It's been unpacked and takes up 1.23MB.
Kent, Hugh has not responded to my post about the new version not working. It calls sub-routines twice and the Serial quit working all together. I does not work even if you comment out the send call in the .asm file. I had to reinstall the last version! I hope Hugh gets on top of this.
Regards,Ed.
Ed, can only speculate on timing, Going by the update list, it sounded like a major overhaul so......?
Yes, major issues with new release.
Also it was missing the compile.bat and the download.bat files.
I was able to go back to the previous version I had, as I actually saved it. Lucky me, so not all is lost. Whew! Thanks for the offer Kent I would have if I had not saved mine.
I understand these things can happen with updates and I am sure Hugh and you guys will work it out.
Just was a shock to update and then have it all fail.
Even the simplest program fails to run correct but compiles without errors. To many bugs now to even list.
Glad to see I was not the only one having issues.
Hi all,
The following are definitely GCBASIC bugs:
- The trouble that occurs when the SysCalcTempx variables are pushed into the second bank
- The duplicate sub calls
The first bug occurs because the various calculation routines assume that everything will be in bank 0. Because of the way that I've written them (using assembly bit test/skip instructions), the subroutines fail to work when GCBASIC inserts the bank selection code.
I've no idea what is causing the second bug, but given that the subroutine and function calling code has been completely rewritten since the last release it's not a surprise.
Unfortunately, I haven't any time to fix this immediately, but will endeavour to have a patch up by Sunday or Monday. Kent, could you please email me the last update and I'll put it back online?
O.K. zipped up the folder and is on its way now. Best of luck, Hugh.
Thanks Hugh,
We know you will do your best!
GCB still rocks!
Thanks Kent, zmanta! This is the most major tidy up that GCBASIC has ever had but it needed to be done!
Also, http://gcbasic.sourceforge.net/update-nochipdata.zip is still the old version.
LOL, that link is broken.
But you can still get there by using the correct link.
http://gcbasic.sourceforge.net/newfiles/update-nochipdata.zip
You forgot the /newfiles/. ;)
Thought I would go and get copies of all files just to have a local copy available and found this link busted.
Zm
O.K. even an 18f can have problems with ram banking. Mixing up program and ram banking, that's me! For those interested, here is a Microchip forum response that explains it. There are two relevant posts, with the one by Olin Lathrop being the best.
http://www.microchip.com/forums/tm.aspx?m=376953&mpage=2&key=linker%2cram񜇤
This bug will also affect 18Fs, but since 18Fs can access 256 bytes of RAM before any banking is needed there is a far slimmer chance of it causing trouble.
I've posted a new version of http://gcbasic.sourceforge.net/newfiles/update.zip
This version should keep all calculation and delay variables in the common RAM (the RAM that can be accessed without banking).
I've also dealt with the double call bug and a couple of interrupt problems. All the chip data files have been altered to include data about common RAM, so you'll need to download the full version.
Thank you very much Hugh...
I'm sorry, now i'm very busy and have little time for PICs; i also have totally dismounted the robot to remake it; but i'll do some testing in simulator with the new update.zip and report any results.
Regards.