@macca tried fixing a tearing issue with debug bitmap display by creating a new window in the loop, at the start, and then "close" -ing it at the end.
But this seems to have been a horrible idea... Several windows appeared at same time, none of them showing any data and then appears to have actually broken the system.
Looks like I need to reboot...
@Rayman said:
Also tried "clear" and "update" mode, clear caused second window to open with both blank. Update mode doesn't seem to work.
Not sure if works in Prop Tool or not...
Maybe will try that later because not exactly sure of syntax...
CLEAR simply clear the window (all black), should not open any other window.
UPDATE performs a window update, it should be used when the auto-update is disabled with the UPDATE keyword on the setup line (the first line that opens a window).
Maybe there is a clash when windows with the same name are closed and reopened too fast, hard to tell.
I don't know what you want to accomplish but I suggest to try with the standard ways, keep the window open and use the RATE, UPDATE or DLY commands.
Are you trying to debug a problem with the bitmap window or with your program ?
I've just tried SpinTools for the first time because I thought it could probably reduce the binary size of old P1 code due to dead code removal. However, I got some errors and it didn't compile.
It says "not a constant" although enc_freq is a constant.
maskErr RES
It also doesn't like RES without a number. For the P1 this was perfectly legal and defaulted to RES 1.
dec long 0 ' decelleration
Is "dec" a reserved keyword, now? Propeller Tool 2.9.3 didn't complain.
And my apologies for bothering you... If it can't be fixed for some reason or you simply don't want to I will surely find workarounds. I just wanted to report that it seems not to be fully compatible.
@ManAtWork said:
I've just tried SpinTools for the first time because I thought it could probably reduce the binary size of old P1 code due to dead code removal. However, I got some errors and it didn't compile.
It says "not a constant" although enc_freq is a constant.
maskErr RES
It also doesn't like RES without a number. For the P1 this was perfectly legal and defaulted to RES 1.
I tried your attached source and it compiles without errors, what version are you using ? I think res without arguments was fixed at some point, make sure to always use the latest release.
However, I see there is a problem with the encod operator, seems that the result is one less than the expected value (in your expression it should return 5 but returns 4).
I need to check with the P2 if the operator returns the same result, from the description seems that this changed from P1 to P2:
P1 - The Bitwise Encode operator encodes a 32-bit long value into the value (0 - 32)
P2 - Encode MSB, 0..31
With P1 returns 0 if no bit is set, with P2 apparently it returns the bit position, meaning that, if I'm not wrong, values 0 and 1 returns both 0. Need to check.
dec long 0 ' decelleration
Is "dec" a reserved keyword, now? Propeller Tool 2.9.3 didn't complain.
No, that was my mistake, for some reasons dec was included as a pasm instruction that doesn't exists... (sometimes hallucinations happens to humans too, not just AIs...).
And my apologies for bothering you... If it can't be fixed for some reason or you simply don't want to I will surely find workarounds. I just wanted to report that it seems not to be fully compatible.
No need to apology, thank you for reporting, I try to test the code but bugs are always there waiting to show, feel free to post issues or ask questions, I'll do my best to fix everything.
For that specific issues, I'll fix them for sure, but I'm in the middle of some deep refactorings and I'm not sure when a new release is ready (hopefully in a couple of weeks).
The most problematic workaround is for the encod issue, if you don't need to change enc_freq you may hard-code the result.
@macca said:
I tried your attached source and it compiles without errors, what version are you using ? I think res without arguments was fixed at some point, make sure to always use the latest release.
Sorry, my fault. I thought I've just downloaded the latest version but I remember I got some errors during the installation I ignorantly just clicked away. But now, I found out I actually did install an old version in 2022 and there are some outdated files left from the old installation. I'll fix that.
The most problematic workaround is for the encod issue, if you don't need to change enc_freq you may hard-code the result.
LOL, I have to find out what that expression actually does. I've just copied that from Harrison Pham's original code.
@macca said:
I tried your attached source and it compiles without errors, what version are you using ? I think res without arguments was fixed at some point, make sure to always use the latest release.
Sorry, my fault. I thought I've just downloaded the latest version but I remember I got some errors during the installation I ignorantly just clicked away. But now, I found out I actually did install an old version in 2022 and there are some outdated files left from the old installation. I'll fix that.
Good.
The most problematic workaround is for the encod issue, if you don't need to change enc_freq you may hard-code the result.
LOL, I have to find out what that expression actually does. I've just copied that from Harrison Pham's original code.
Actually, a more suitable workaround is to just remove the constant() wrap and disable the automatic constant folding in the Spin1 preferences:
That will use the bytecode encod operator that works correctly.
Ok, I re-installed the latest version and now it compiles without error.
I've done a quick check and the constant() actually computes different results. Propeller Tool shows
PLLDIV=0A800000
FRQ=14000000
SpinTools IDE produces:
PLLDIV=0A000000
FRQ=28000000
I'll hardcode the correct values above. Changing the frequency makes no sense at all. The ENC28J60 chip always wants 25MHz.
BTW, The binary file SpinTools produces is ~70longs shorter than the filr from Propeller Tool. That's only 1% but just enough so I can add debug output.
Comments
@macca tried fixing a tearing issue with debug bitmap display by creating a new window in the loop, at the start, and then "close" -ing it at the end.
But this seems to have been a horrible idea... Several windows appeared at same time, none of them showing any data and then appears to have actually broken the system.
Looks like I need to reboot...
Also tried "clear" and "update" mode, clear caused second window to open with both blank. Update mode doesn't seem to work.
Not sure if works in Prop Tool or not...
Maybe will try that later because not exactly sure of syntax...
CLEAR simply clear the window (all black), should not open any other window.
UPDATE performs a window update, it should be used when the auto-update is disabled with the UPDATE keyword on the setup line (the first line that opens a window).
Maybe there is a clash when windows with the same name are closed and reopened too fast, hard to tell.
I don't know what you want to accomplish but I suggest to try with the standard ways, keep the window open and use the RATE, UPDATE or DLY commands.
Are you trying to debug a problem with the bitmap window or with your program ?
I've just tried SpinTools for the first time because I thought it could probably reduce the binary size of old P1 code due to dead code removal. However, I got some errors and it didn't compile.
It says "not a constant" although enc_freq is a constant.
It also doesn't like RES without a number. For the P1 this was perfectly legal and defaulted to RES 1.
Is "dec" a reserved keyword, now? Propeller Tool 2.9.3 didn't complain.
And my apologies for bothering you... If it can't be fixed for some reason or you simply don't want to I will surely find workarounds. I just wanted to report that it seems not to be fully compatible.
I tried your attached source and it compiles without errors, what version are you using ? I think res without arguments was fixed at some point, make sure to always use the latest release.
However, I see there is a problem with the encod operator, seems that the result is one less than the expected value (in your expression it should return 5 but returns 4).
I need to check with the P2 if the operator returns the same result, from the description seems that this changed from P1 to P2:
P1 - The Bitwise Encode operator encodes a 32-bit long value into the value (0 - 32)
P2 - Encode MSB, 0..31
With P1 returns 0 if no bit is set, with P2 apparently it returns the bit position, meaning that, if I'm not wrong, values 0 and 1 returns both 0. Need to check.
No, that was my mistake, for some reasons dec was included as a pasm instruction that doesn't exists... (sometimes hallucinations happens to humans too, not just AIs...).
No need to apology, thank you for reporting, I try to test the code but bugs are always there waiting to show, feel free to post issues or ask questions, I'll do my best to fix everything.
For that specific issues, I'll fix them for sure, but I'm in the middle of some deep refactorings and I'm not sure when a new release is ready (hopefully in a couple of weeks).
The most problematic workaround is for the encod issue, if you don't need to change enc_freq you may hard-code the result.
@macca After rebooting PC again, tearing problem seems to have gone away, at least mostly....
Sorry, my fault. I thought I've just downloaded the latest version but I remember I got some errors during the installation I ignorantly just clicked away. But now, I found out I actually did install an old version in 2022 and there are some outdated files left from the old installation. I'll fix that.
LOL, I have to find out what that expression actually does. I've just copied that from Harrison Pham's original code.
Good.
Actually, a more suitable workaround is to just remove the constant() wrap and disable the automatic constant folding in the Spin1 preferences:
That will use the bytecode encod operator that works correctly.
Ok, I re-installed the latest version and now it compiles without error.
I've done a quick check and the constant() actually computes different results. Propeller Tool shows
SpinTools IDE produces:
I'll hardcode the correct values above. Changing the frequency makes no sense at all. The ENC28J60 chip always wants 25MHz.
BTW, The binary file SpinTools produces is ~70longs shorter than the filr from Propeller Tool. That's only 1% but just enough so I can add debug output.