First of all, wonderful compiler! in just a few days it has seriously multiplied my pic-coding skills. But I think I found a minor bug - GC Basic's internal assembler for PIC18F chips won't properly assemble code past location 0x8000 (at least not using option bootloader to offset the code). If I specify -a:"gpasm -i file.asm" instead the code runs fine. Test case…
Dir PORTB.1 out
testloop:
Set PORTB.1 on 'test LED
wait 1 s
Set PORTB.1 off
wait 1 s
goto testloop
Make option bootloader 0x7000 and the code works fine with the internal assembler. I'm using GC Basic under Linux, compiled with a fairly recent free basic. I'm not asking for a fix (using gpasm totally solves the issue), but since it affects one of my projects and I have to include a note to use gpasm instead of gcasm figured I'd be a good hacker and report the issue. First of all need to confirm that the issue is reproduceable and not a freebasic or other bug, if it is reproduceable then a potential "fix" might be to simply document to use gpasm 0.13.7+ for code that goes past 0x8000 (but of course it's more fun to really fix it provided the fix has little chance of breaking other stuff).
As to why such a huge bootloader offset - I made a bootloader using GC Basic (!), needed to locate at 0xB000. Existing bootloaders don't do it for me, I wanted one that was menu-driven and lets me load plain hex over serial so I wrote one.
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After more investigation I isolated the problem… when emitting hex code, if the start address of a line is >32768 it emits a type 04 record (change address) to switch to high address 0001… oops. The fix is easy…
In assembly.bi look for the comments " 'Add high address? ", occurs in two places,
in the next two lines after each of the comments replace "FRA" with "(FRA - 32767)".
Recompile with freebasic.
This is only needed if compiling code for a chip with a large address space, such as the PIC18F2525. For very large programs might want to also change the number in "Dim As String Prog(20000)" to something larger.
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello gcbasic folks,
First of all, wonderful compiler! in just a few days it has seriously multiplied my pic-coding skills. But I think I found a minor bug - GC Basic's internal assembler for PIC18F chips won't properly assemble code past location 0x8000 (at least not using option bootloader to offset the code). If I specify -a:"gpasm -i file.asm" instead the code runs fine. Test case…
#chip 18F2525, 8
#config OSC = INT, BODEN = OFF, WDT = OFF, MCLRE = OFF, LVP = OFF
#option bootloader 0x8000
Dir PORTB.1 out
testloop:
Set PORTB.1 on 'test LED
wait 1 s
Set PORTB.1 off
wait 1 s
goto testloop
Make option bootloader 0x7000 and the code works fine with the internal assembler. I'm using GC Basic under Linux, compiled with a fairly recent free basic. I'm not asking for a fix (using gpasm totally solves the issue), but since it affects one of my projects and I have to include a note to use gpasm instead of gcasm figured I'd be a good hacker and report the issue. First of all need to confirm that the issue is reproduceable and not a freebasic or other bug, if it is reproduceable then a potential "fix" might be to simply document to use gpasm 0.13.7+ for code that goes past 0x8000 (but of course it's more fun to really fix it provided the fix has little chance of breaking other stuff).
As to why such a huge bootloader offset - I made a bootloader using GC Basic (!), needed to locate at 0xB000. Existing bootloaders don't do it for me, I wanted one that was menu-driven and lets me load plain hex over serial so I wrote one.
Terry
Hello again,
After more investigation I isolated the problem… when emitting hex code, if the start address of a line is >32768 it emits a type 04 record (change address) to switch to high address 0001… oops. The fix is easy…
In assembly.bi look for the comments " 'Add high address? ", occurs in two places,
in the next two lines after each of the comments replace "FRA" with "(FRA - 32767)".
Recompile with freebasic.
This is only needed if compiling code for a chip with a large address space, such as the PIC18F2525. For very large programs might want to also change the number in "Dim As String Prog(20000)" to something larger.
Terry