Assembler errors

[charliecoutas]

Version 4.0.1.2 - 8 bit Positron

I just recompiled a large source that has been OK and hasn't changed, and I get two errors, both the same:

ASM ERROR : Error[115]Duplicate label("FSR0H" or redefining symbol that cannot be redefined)

Can somebody point me in the right direction please?

Charlie

[atomix]

https://protoncompiler.com/index.php/topic,642.0.html

[top204]

Microchip have now started adding "FSR0" as an SFR name, and the compiler's data files are semi-auto created from them, so what Microchip add, the PPI creator transfers to its files. With the earlier assembler programs, the new variable name would over-ride the previous one, but the newer assembler gives an error. The new assembler program is actually doing what the older assembler programs should have done and not allowed two equ directives with the same name.

This means if you have a program that has something like:

Dim FSR0 As FSR0L.Word

The assembler will give an error because the SFR name "FSR0H" may already exist because it is the high byte of "FSR0". Because Microchip have, foolishly, added "FSR0" as well as "FSR0L". But "FSR0" is not an official SFR and is not in any datasheets!!!

The thread atomix linked too is the answer to your question Charlie. Use a name for the variable that is different to what an SFR would be named. i.e. Add a preceding "w" etc...

Dim wFSR0 As FSR0L.Word

I was going to add extra bits and pieces in the assembler file for variable and label names when I first wrote the compilers, but I wanted the assembler listing to match, as close as possible, the BASIC code so people could learn assembler code by seeing the high level and low level languages with the same names etc. But Microchip keep changing their rules and names etc, so it can cause issues.

[charliecoutas]

Thanks Les, Atomix

I carefully changed the DIM FSR0 as FSR0L.word   to   Dim wFSR0 as FSR0L.word  and then both references to it from FSR0 =   to  wFSR0 =
and all hell has happened. I am now getting lots of assembler errors like: ASM ERROR  SYMBOL NOT PREVIOUSLY DEFINED (_PRINT_)
and (_GLCD_CURSOR_)  I am using the includes for the 1306 display.

[Edit] These errors now show because I have fixed the FSR0 error. But what is causing them???

[top204]

They look as though they are being caused because they are calling the library subroutine names that have changed since the library was created.

I'm not sure if it was on this forum or the previous forum, where this question was last asked and answered.

The library subroutine for Print is: "__print_" and for the GLCD cursor it is: "__glcd_cursor_".

Go through the 1306 code and make the changes. This is why I always try and get it through to users to create a detailed header text in the libraries for the compiler version used and any compiler internal calls they are using or commands they are disabling of the compiler's library routines etc...

Now that I have changed the compiler's internal names and symbols etc, to suit the new Mpasm assembler and the new assembler used for the brand new 18F16xxQ devices, the internal names will never need changing again.

[charliecoutas]

I've been through the two files for 11306 DEF and SUB, and my source, and there aren't any PRINT or GLCD_CURSOR commands in there. I feel that I'm being a bit thick but where else could those calls/commands be?

[Edit] Found two more files for 1306, I think I'm on the home straight. Thanks Les.

[RGV250]

Hi,
I might be wrong but I think you need an extra underscore at the start of "__print_" & "__glcd_cursor_"

Bob

[top204]

They will be label names, and possibly Calls or Gosubs.

I don't have the 1306 library code so I cannot be exact. I created my own a year or so ago, and have all the mechanisms in it. i.e. Fonts, graphics and replacements of the compiler's Print, Cls and Cursor commands etc...

As soon as I can find the time, I will be updating my new web site at RosettaMicro.com that Tim and Gabi have created for me, and I will be adding my libraries and projects and tutorials to it.

I have a good 18F project using the si4732 MW/SW/FM radio chip with a small colour graphic LCD and a rotary encoder. As well as a project of a 16x16 matrix of WS2812b RGB LED devices with fonts and graphics etc... Among other projects using the Positron compilers. :-)

[charliecoutas]

It's now sorted Les. Many thanks. I'll write up the changes tomorrow morning and post them.

Thant new project of yours sounds interesting....

[charliecoutas]

Thanks Bob, yes you are right. This is what I did (for the 1306 display code):

Edit the file: SSD1306_Def_v0.4.inc

Find the line: Dim FSR0 As FSR0L.Word       ;Addressing of variable
And change it to: Dim wFSR0 As FSR0L.Word       ;Addressing of variable
Save and close

Edit the file: SSD1306_Sub_v0.4.inc

Find the lines (two of them): FSR0 = AddressOf (bVideoMem) + wElement#No
And change them to: wFSR0 = AddressOf (bVideoMem) + wElement#No
Save and close

Edit the file: Graphic_Sub_v0.4.inc

Comment out GLCD@CUR  and/or replace it with __GLCD_CURSOR_   Note two underlines at start
Do the same with PRINT. You are simply replacing two labels with their new names.

Below is the area you need along with the changes

;----------------------------------------------------------------------------
Asm
__GLCD_CURSOR_   ;new label  TWO underscores
;GLCD@CUR        ;old redundant label
    Movwf Graphic_wCursorY,0                ;Value in W (Y.byte0) is also in GEN2
    Movff GEN2H,Graphic_wCursorYH           ;y could be greater than 255
    Movff GEN,Graphic_wCursorX             
    GoTo Graphic_GotoXYSub
;Print           ;old label
__PRINT_         ;new label  TWO underscores
    GoTo Graphic_PrintCharSub
EndAsm
;----------------------------------------------------------------------------
Save and close

The compiler is warning that HBUS will not be supported soon. That's a bit outside my ability. Hopefully somebody will look at this.

[Dompie]

@charliecoutas, sorry I see this thread today, in the downloadsection of this site are the lates version of this ssd1306 library with ....v1.11. You can find the download here

Johan

[top204]

Thanks Charlie.

Within the code, change things like:

Code Select Expand

    Movwf Graphic_wCursorY,0                ;Value in W (Y.byte0) is also in GEN2
    Movff GEN2H,Graphic_wCursorYH           ;y could be greater than 255
    Movff GEN,Graphic_wCursorX

to
   

Code Select Expand

    Graphic_wCursorY = WREG
    Graphic_wCursorYH = GEN2H
    Graphic_wCursorX = GEN

Otherwise, it will not work if RAM banks are changed and will not work with the newer 18F devices because their RAM layout is very different and sometimes the Movffl mnemonic needs to be used instead of the Movff mnemonic. The compiler sorts all of this out for the user and the BASIC commands given above will create the same as the assembler mnemonics window above, but will alter them to suit when required.

Raw assembler mnemonics are not suitable in libraries, unless a knowledge of the Harvard architecture is known and the RAM banks are managed alongside the mnemonics, otherwise, they will fail from device to device, and the failures will be very subtle because a different variable will be altered or read from because it is sitting in another RAM bank.

[charliecoutas]

Dompie and Les

Thanks. I'll sleep on it. It sounds as though things are not quite as straightforward as they first appear?

Charlie

Everything has an end, except the sausage, which has two.

[Dompie]

@Les, Thank you for this error and solution. This part of the library is already 10-15 years old and dates back to the Nokia driver era (the time of the users Gabi and VaGyver). Back then there were no PIC devices with more than 64k. I will put this problem on my todo list to make a new version of the SSD1306. There are still a few more points to fix.

Johan

[Stephen Moss]

Because Microchip have, foolishly, added "FSR0" as well as "FSR0L". But "FSR0" is not an official SFR and is not in any datasheets!!!

I don't use the MPLAB/MPLABX IDE but have been creating BNF file from the Microchips file and have noticed in the source files I have been using that a register called FRS0 could be what they call a "Joined" Register which would comprise of FSR0L, FRS0H and FSR0U (where applicable).
Presumably, that allows the user to treat the component registers as a single entity, Reading/Writing the register using either 16/32 bit or 24/48 (8bit/16bit devices) values as the address of the Joined register appears to always be the same as that of the Low register.

Is that the same as "LH" registers the compiler uses, i.e. TMR1LH? As I see those in the register listing but not in the datasheet, although in the PPI files the address is the same as that that of the High register, not the low register.

[Dompie]

@charliecoutas the new version is in the download section Graphic&SSD1306_20220701. All Les his advices are implemented in this version.

Johan