So, looking at the patch file, if I understand it correctly it isn't a problem with the Q40/Q41 and the MOVFF instruction, it's that your .dat file didn't identify the Q40/Q41 as been part of the newer 18xv core devices and having the updated instruction set.
I don't really see how this is a MOVFF/MOVFFL issue, since none of the parts in that family have > 4K of ram. Even though they support the MOVFFL instruction it should never be required.
Was the issue really the encoding of the LFSR instruction? In that thread you linked to you mentioned "different movffl and lfsr instruction", and LFSR is different between the 18F's
Am I missing something? Sorry if I'm being a pest... I just want to understand what the issue is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The DAT is not the root cause. The DAT file simply switches on a piece of the code in the compiler. I has to change the compiler for these chips to always use the MOVFFL. I think this is what I missed in the datasheet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I has to change the compiler for these chips to always use the MOVFFL. I think this is what I missed in the datasheet.
Trying not to be too much of a PITA, but let me see if I understand.
You 're saying that for the 18Fx4Q40/Q41 and the 18Fx5Q40/Q41 (all of which have ram located below the 4K address boundary of the MOVFF instruction) you can't use MOVFF and have to use MOVFFL?
In what datasheet is this called out? MOVFF is a documented instruction for the Q40/Q41. It has the same encoding (and operation) as in previous PIC18's.
What "memory corruption" does MOVFF cause?
I could see this being an issue if you were talking about the x6Q40 since that has ram past the 4K address space of MOVFF, but not for the smaller parts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That might make more sense... setting FamilyVariant=1 seems to enable the xv18 core instruction set.
I think what that might have really fixed was the LFSR instruction. That one has different binary encoding for standard pic18 vs xv18 core (12-bit vs 14-bit addresses)
Could be wrong, though...
Thanks for putting up w/me. I just wanted to know if there was some unpublished errata or something since you seem to have good access to the support/developer teams.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I report all the issues I find direct to my assigned Microchip Support person. :-)
Last year reported a lot of errors, which they corrected in the code and/or documentation. I reported a bug in PIC-AS in Jan 22, fixed by Feb 22.. not to shabby.
The difference for the FamilyVariant =1 is the bank calculation.
Just to satisfy my own curiosity, I compiled mkstevo's bin_hex_dec_calculator_v3.20.gcb for the 18F15Q40 with and without the 'FamilyVariant =1'.
The only differences of note in the .lst file were the encoding of the LFSR instruction. No 'MOVFFL' instructions were used, so at least all of that makes sense now.
So, the ChipFamilyVariant =1 means (B AND 8064) / 128
That's an interesting way to calculate the bank considering banks are 256 bytes in the 18F.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Am I optimising by using
if var1 =1 and var2=1 then
replace by
if var1=1 then if var2=1 then
and tests both vars but if then if will skip testing condition 2 if condition 1 fails.
Does the compiler make any difference between the 2 methods?
Using or is different.
Last edit: stan cartwright 2022-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed in your 1st video you used 328p but not,16 and in the last video you used 328p,16.
I thought the ide assumed 328p at 16MHz in 1st vid. Nice you use 328p as examples.
just feedback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem, but in that case I guess I have the same basic question... I haven't noticed a problem with MOVFF and the Q40/41 either.
Was this to get around some PIC-AS issue or something?
The Q40/Q41 last week. I had to revise the DAT file to support the enhanced MOVFF. The issue was memory corruption. See https://sourceforge.net/p/gcbasic/discussion/579125/thread/2882e7b7c7/?limit=250#b4e8
I see.
So, looking at the patch file, if I understand it correctly it isn't a problem with the Q40/Q41 and the MOVFF instruction, it's that your .dat file didn't identify the Q40/Q41 as been part of the newer 18xv core devices and having the updated instruction set.
I don't really see how this is a MOVFF/MOVFFL issue, since none of the parts in that family have > 4K of ram. Even though they support the MOVFFL instruction it should never be required.
Was the issue really the encoding of the LFSR instruction? In that thread you linked to you mentioned "different movffl and lfsr instruction", and LFSR is different between the 18F's
Am I missing something? Sorry if I'm being a pest... I just want to understand what the issue is.
The DAT is not the root cause. The DAT file simply switches on a piece of the code in the compiler. I has to change the compiler for these chips to always use the MOVFFL. I think this is what I missed in the datasheet.
Trying not to be too much of a PITA, but let me see if I understand.
You 're saying that for the 18Fx4Q40/Q41 and the 18Fx5Q40/Q41 (all of which have ram located below the 4K address boundary of the MOVFF instruction) you can't use MOVFF and have to use MOVFFL?
In what datasheet is this called out? MOVFF is a documented instruction for the Q40/Q41. It has the same encoding (and operation) as in previous PIC18's.
What "memory corruption" does MOVFF cause?
I could see this being an issue if you were talking about the x6Q40 since that has ram past the 4K address space of MOVFF, but not for the smaller parts.
I probably got my diag wrong.
FamilyVariant fixed the issue. It the does not change the use of MOVFF then I will have to dig a lot deeper.
That might make more sense... setting FamilyVariant=1 seems to enable the xv18 core instruction set.
I think what that might have really fixed was the LFSR instruction. That one has different binary encoding for standard pic18 vs xv18 core (12-bit vs 14-bit addresses)
Could be wrong, though...
Thanks for putting up w/me. I just wanted to know if there was some unpublished errata or something since you seem to have good access to the support/developer teams.
I report all the issues I find direct to my assigned Microchip Support person. :-)
Last year reported a lot of errors, which they corrected in the code and/or documentation. I reported a bug in PIC-AS in Jan 22, fixed by Feb 22.. not to shabby.
The difference for the FamilyVariant =1 is the bank calculation.
So, the ChipFamilyVariant =1 means (B AND 8064) / 128
:=)
Just to satisfy my own curiosity, I compiled mkstevo's bin_hex_dec_calculator_v3.20.gcb for the 18F15Q40 with and without the 'FamilyVariant =1'.
The only differences of note in the .lst file were the encoding of the LFSR instruction. No 'MOVFFL' instructions were used, so at least all of that makes sense now.
That's an interesting way to calculate the bank considering banks are 256 bytes in the 18F.
must be the encoding of the LFSR that fixed the error.
Am I optimising by using
if var1 =1 and var2=1 then
replace by
if var1=1 then if var2=1 then
and tests both vars but if then if will skip testing condition 2 if condition 1 fails.
Does the compiler make any difference between the 2 methods?
Using or is different.
Last edit: stan cartwright 2022-02-21
The second approach is fastest. The code will branch out if the first test fails, and, there is no comaparison of the two tests.
I noticed in your 1st video you used 328p but not,16 and in the last video you used 328p,16.
I thought the ide assumed 328p at 16MHz in 1st vid. Nice you use 328p as examples.
just feedback.