Yes, I modified the dat file ... I think really that my dinosaurs don't yet have a hardware multiplier. (Worse, I have even about 10 units of 90S8515 in my stock which I don't use presently ; their dat file is OK).
All the way, the program works now correctly, even with the one line instruction. Thanks again !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found some old datasheets ; it seems really that the Mega8515 (but not the 90S) had already a hardware multiplier, but it seems also that my build 1137 does not "like" it. So the best thing to do was to disable it in the dat file ; and I won't use the 90S anymore, since I should use an external brown out detector. At the beginning I used the 90S on my layout and this caused transients during power down, resulting in "wild" back and forth switching of the turnouts, which is in fact not very good for a "long life" !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pleasure - this was a real learning experience for me.
I had to walk the program using an emulator. Thank to Vladimir Soso at OshonSoft who recently provided me his wonderful software - I am able to see the ASM source and see the registers change when the hardware multiplier was used. Get the software here - https://www.oshonsoft.com/avr.php
Oshonsoft - walking the code to see that MUL was active on the Mega8515.
I have also made the following changes to the compiler to ensure this does not happen again.
The compiler assesses the maths calc and it will automatically switch HARDWAREMULT off to manage the registers in a very robust manner using the AVR method SYSMULTSUB. The ASM will show ;AVR MUL using SYSMULTSUB software maths to indicate this action.
The compiler supports turning HARDWAREMULT off from the user program so all multiplications are done in software. So, users will be able to selectively disable HARDWAREMULT. This capability was part of the update anyway.
The proper resolution was to examine the generation of the variable being used in the 'sum'. The compiler now automatically uses a variable that is not overwritten by the MUL directive.
This means the HardwareMult can be set back to HardwareMult=y as the compiler should do AVR maths correctly.
Sorry, I tested with the patch from Aug 25 : IT DOES NOT WORK ! (I erased all old gcbasic*.exe in the original installation, in the patch the gcbasic.exe and gcbasic32.exe and renamed gcbasic64.exe as gcbasic.exe before patching). And the error occurs even with the newest version (from today) ; it concerns line 239.
The issue was the slight change in line 239. The new braces caused the compiler to treat the math analysis differently. Not a user issue the compiler should cope.
So, I have move the 'sum' analysis to CompCalc() (which is further up the stack of maths analysis) to resolve. If the compiler can use simple multiplication it will MUL, else it will force software MULtiplication .
So, please try build 1163 - it should resolve the issue.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, now it "seems" to work, at least for my formula ; hope only that there are no "side effects", You know one rule in the collection about "Murphy's law" : Correcting one error causes other new errors to appear, much more difficult to correct ...
:)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PS : Despite of the fact that I kept here the code to manage the EasyVR3, finally I won't use it on my layout, it needs a feedback to show when it is ready to listen (here the Led at PB.7), and either blinking a Led or beeping can be very quickly boring.
Last edit: Bertrand BAROTH 2022-08-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I modified the dat file ... I think really that my dinosaurs don't yet have a hardware multiplier. (Worse, I have even about 10 units of 90S8515 in my stock which I don't use presently ; their dat file is OK).
All the way, the program works now correctly, even with the one line instruction. Thanks again !
I found some old datasheets ; it seems really that the Mega8515 (but not the 90S) had already a hardware multiplier, but it seems also that my build 1137 does not "like" it. So the best thing to do was to disable it in the dat file ; and I won't use the 90S anymore, since I should use an external brown out detector. At the beginning I used the 90S on my layout and this caused transients during power down, resulting in "wild" back and forth switching of the turnouts, which is in fact not very good for a "long life" !
PS : and I did the same for Mega162 !
Pleasure - this was a real learning experience for me.
I had to walk the program using an emulator. Thank to Vladimir Soso at OshonSoft who recently provided me his wonderful software - I am able to see the ASM source and see the registers change when the hardware multiplier was used. Get the software here - https://www.oshonsoft.com/avr.php
Oshonsoft - walking the code to see that MUL was active on the Mega8515.
I have also made the following changes to the compiler to ensure this does not happen again.
;AVR MUL using SYSMULTSUB software mathsto indicate this action.All sorted - good
Last edit: Anobium 2022-08-14
I have resolved - properly - the maths error.
The proper resolution was to examine the generation of the variable being used in the 'sum'. The compiler now automatically uses a variable that is not overwritten by the MUL directive.
This means the HardwareMult can be set back to
HardwareMult=yas the compiler should do AVR maths correctly.You need build 1152 or greater.
Great Cow BASIC (1.00.00 Release Candidate 2022-08-18 (Windows 64 bit) : Build 1152)
Evan
Sorry, I tested with the patch from Aug 25 : IT DOES NOT WORK ! (I erased all old gcbasic*.exe in the original installation, in the patch the gcbasic.exe and gcbasic32.exe and renamed gcbasic64.exe as gcbasic.exe before patching). And the error occurs even with the newest version (from today) ; it concerns line 239.
Last edit: Bertrand BAROTH 2022-08-27
Thank you for the source. I am looking at the moment.
THANK YOU for retesting. I am truly grateful.
Resolved in build 1163
The issue was the slight change in line 239. The new braces caused the compiler to treat the math analysis differently. Not a user issue the compiler should cope.
So, I have move the 'sum' analysis to CompCalc() (which is further up the stack of maths analysis) to resolve. If the compiler can use simple multiplication it will MUL, else it will force software MULtiplication .
So, please try build 1163 - it should resolve the issue.
Evan
Thanks, now it "seems" to work, at least for my formula ; hope only that there are no "side effects", You know one rule in the collection about "Murphy's law" : Correcting one error causes other new errors to appear, much more difficult to correct ...
:)
The code generate is good. Excellent.
The method does not change the ASM generation, it change the imput into that process. So, very low risk, but, better than before... hopefullly.
PS : Despite of the fact that I kept here the code to manage the EasyVR3, finally I won't use it on my layout, it needs a feedback to show when it is ready to listen (here the Led at PB.7), and either blinking a Led or beeping can be very quickly boring.
Last edit: Bertrand BAROTH 2022-08-27