Does anyone have a copy of propeller-load.exe, that I could download? I cannot seem to find one here on the forums. It seems I have deleted my previous versions of fastspin, that contained propeller-load.exe.
Does anyone have a copy of propeller-load.exe, that I could download? I cannot seem to find one here on the forums. It seems I have deleted my previous versions of fastspin, that contained propeller-load.exe.
Ray
propeller-load.exe is part of SimpleIDE. If you have that installed you should have it. So you're thinking this is a problem with proploader.exe? If so, please file a bug report in GitHub. proploader.exe is the program that Parallax is using now so we should make sure it works correctly.
I just checked my version of SimpleIDE, and it has proploader.exe, not propeller-load.exe. The version in my SimpleIDE is v1.0-24, and when I ran the test1.binary, with that version, it displays the same clobbered chars.
I just checked my version of SimpleIDE, and it has proploader.exe, not propeller-load.exe. The version in my SimpleIDE is v1.0-24, and when I ran the test1.binary, with that version, it displays the same clobbered chars.
Ray
Sorry if you've already done this but could you provide your code so I can try to duplicate this problem?
I just tested the test1.binary with the propeller-load.exe program, and it looks like the print string is not clobbered. It is showing what is expected. I will run some of my other test... programs with propeller-load.exe to see if anything else runs the way I expect it to.
Ray
G:\fastspin\temp>propeller-load -p COM3 -t -r g:/fastspin/programs/test1/test1.binary
Propeller Version 1 on COM3
Loading g:/fastspin/programs/test1/test1.binary to hub memory
1676 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
will I see something
I just tested the test1.binary with the propeller-load.exe program, and it looks like the print string is not clobbered. It is showing what is expected. I will run some of my other test... programs with propeller-load.exe to see if anything else runs the way I expect it to.
Ray
G:\fastspin\temp>propeller-load -p COM3 -t -r g:/fastspin/programs/test1/test1.binary
Propeller Version 1 on COM3
Loading g:/fastspin/programs/test1/test1.binary to hub memory
1676 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
will I see something
In thinking about this it might be that proploader.exe uses a much higher baud rate to download your code and then switches to the target baud rate when the program starts. There may be an issue with that transition. You could try using proploader.exe with "-D fast-loader-baud-rate=115200" to get it to use 115200 for the download as well as terminal mode and see if that solves the problem.
Ah, I'm able to reproduce the issue now Ray (thanks for posting your binary). It does seem to be a timing issue related to startup -- propeller-load doesn't show it, but proploader does (presumably proploader is slightly slower at starting to look at the serial port?). Putting a delay in at the beginning, as Ron suggested, seems to fix it for me. A 1 millisecond delay is not enough, but 10 milliseconds does the trick.
David, thanks for looking at this. I'm not sure if there's any way for proploader to get into its serial port receive routines faster. I suspect we haven't seen this before because regular Spin and even PropGCC CMM are slow enough that there's probably a baked in delay before anything can be printed. But PropGCC LMM can show the problem too. For example:
#include <stdio.h>
int main() {
int i;
for(i = 0; i < 4; i++) {
printf("hello, world!\n", i);
}
return 0;
}
shows some garbage for the first one or two lines when compiled with LMM mode and -Os and run with proploader. The last 2 or 3 lines come out OK.
I just did a test run of my test.temp.binary using the propeller-load.exe. I added the delay that Eric suggested, and the program runs, but the temp and humid values are way out of the normal. At least I got something to shyow on the terminal.
Ray
rem test_temp.bas
' October 13, 2018
' Test of the CM2302 module on the WX Activity Board
dim cm2302 as class using "DHTnn_Object.spin"
let mscycles = clkfreq / 1000
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
dim temp#,humid#,misc#
cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
waitcnt(getcnt() + 10_000_000)
print "Did I get this far."
do
cm2302.DHTnn_Read()
print "Temp ";(9.0/5.0)*temp# + 32.0;" Humid ";humid#
pausems 3000
loop
G:\fastspin\temp>propeller-load -p COM4 -t -r g:/fastspin/programs/test_temp/test_temp.binary
Propeller Version 1 on COM4
Loading g:/fastspin/programs/test_temp/test_temp.binary to hub memory
8908 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Did I get this far.
Temp 103.46 Humid 1.1093E+09
Temp 103.46 Humid 1.1093E+09
Temp 105.26 Humid 1.1096E+09
Temp 106.88 Humid 1.1098E+09
Temp 105.80 Humid 1.1097E+09
Temp 105.08 Humid 1.1096E+09
Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Are you sure it's not just a timing issue? The Propeller program may start sending data before the PC side has changed its baud rate. There may be nothing that can be done about this other than inserting a delay.
rem test_noise.bas
' Declarations
const pin = 30
let mscycles = clkfreq / 1000
direction(pin) = output
pausems 5
'******************************
'Main
print "Now watch the cursor carefully"
do
output(pin) = not output(pin)
pausems 1000
loop
'******************************
This would indicate that the print channel is still open.
Given that there is also a problem with the back to back read/write with fsrw, It begs the question as to
whether the two problems are related.
Ron
Pin 30 is the serial pin, so if you explicitly toggle it then strange things are going to happen on the terminal. I don't think there's any way around that!
The back to back read/write problem with fsrw was a bug in the BASIC close function. That'll be fixed in the next release. Is there some other read/write problem you've noticed (when BASIC close is not called)?
Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Are you sure it's not just a timing issue? The Propeller program may start sending data before the PC side has changed its baud rate. There may be nothing that can be done about this other than inserting a delay.
Good point, it may be that the only solution is to insert a delay (or to use -D fast-loader-baud-rate=115200). Having a delay at the start of the program is pretty common, so that may not be too bad.
Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Are you sure it's not just a timing issue? The Propeller program may start sending data before the PC side has changed its baud rate. There may be nothing that can be done about this other than inserting a delay.
Good point, it may be that the only solution is to insert a delay (or to use -D fast-loader-baud-rate=115200). Having a delay at the start of the program is pretty common, so that may not be too bad.
I'll check with Jeff Martin but it might be friendlier to provide a simple option to disable the "fast loader" other than the cumbersome way of setting the fast loader speed the same as the terminal emulator speed. propeller-load doesn't have this problem because it doesn't have a fast loader.
Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Any change in Baud speed, does take time in modern OS.
If the Prop is alive at that stage, it could easily send-before ready.
Options would be to delay as discussed (somewhat klunky, but works), or wait on some ready signal from the PC side.
It may be possible to define an optional char the fast loader can send, when it is speed-changed, to give a simple handshake that acts as a ready signal ?
I'll check with Jeff Martin but it might be friendlier to provide a simple option to disable the "fast loader" other than the cumbersome way of setting the fast loader speed the same as the terminal emulator speed. propeller-load doesn't have this problem because it doesn't have a fast loader.
That's one workaround, but for those wanting to keep fast loader, and friendly, you could also ask Jeff about a user optional ready Char it can send when terminal is 'up' at changed baud speed.
Ok, that's good to know I just assumed the output port would close after a print and the input port
would open (they would toggle). I now understand why that would never work.
No other issues. Looking forward to the next release
My setup, for now is, using spin2gui to compile, and from the command line, use the propeller-load.exe to run the program.
Below is my test_temp program and the values that are being printed are way off. Did something happen to the '#' floating point variable, in the last update of fastspin?
I also tried using '%' integer variable in place of '#', to see what would happen, still was getting some way off results. I also noticed that by using '%' integer variable, it increased the size of the program by ~4000. I thought it would be the other way around.
Ray
rem test_temp.bas
' October 13, 2018
' Test of the CM2302 module on the WX Activity Board
dim cm2302 as class using "DHTnn_Object.spin"
let mscycles = clkfreq / 1000
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
dim temp#,humid#,misc#
cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
waitcnt(getcnt() + 10_000_000)
do
cm2302.DHTnn_Read()
print "Temp ";(9.0/5.0)*temp# + 32.0;" Humid ";humid#
pausems 3000
loop
G:\fastspin\temp>propeller-load -p COM4 -t -r G:/fastspin/programs/test_temp/test_temp.binary
Propeller Version 1 on COM4
Loading G:/fastspin/programs/test_temp/test_temp.binary to hub memory
8852 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Temp 106.52 Humid 1.1098E+09
Temp 107.06 Humid 1.1098E+09
Temp 106.52 Humid 1.1098E+09
Got my little test program to compile after fixing the way fullduplex serial is used.
Think the way described in the docs is old, one should use "class" now...
Does this look OK?
rem simple program to toggle a pin while outputting characters
'' create a Spin FullDuplexSerial object
class fullduplex using "FullDuplexSerial.spin"
dim ser as fullduplex
'Going to toggle pin #1 every 1/10 of a second
const pin = 1
let mscycles = clkfreq / 1000
direction(pin) = output
rem first, wait for user to press a key in serial terminal
var r = ser.rx()
'Then, loop forever
do
output(pin) = not output(pin)
ser.tx("Hello.")
ser.tx(13)
pausems 1000
loop
Got it to work by replacing fullduplexserial stuff with "print".
Works on P2. See the CR is automatic now.
Used p2load, works fine. Can use propellent for P1, I think.
Wish there was a simple input method to go with "print"... Something like GetChar or something...
### INPUT$
A predefined string function. `input$(n, h)` reads `n` characters from handle `h`, as created by an `open device as #h` statement.
The open device thing looks like a pain for something that is supposed to be easy...
"print" works without any setup...
Anyway, this sample code seems to work fine on P2:
rem simple program to toggle a pin while outputting characters
'Going to toggle pin #1 every second
const pin = 1
direction(pin) = output
'Will show count of how many times toggle
var c = 0
'Then, loop forever
do
output(pin) = not output(pin)
print "Toggled ";c;" times."
c = c + 1
pausems 1000
loop
Comments
Ray
Ray
(BTW I found propeller-load in my SimpleIDE folder)
Ray
Ray
David, thanks for looking at this. I'm not sure if there's any way for proploader to get into its serial port receive routines faster. I suspect we haven't seen this before because regular Spin and even PropGCC CMM are slow enough that there's probably a baked in delay before anything can be printed. But PropGCC LMM can show the problem too. For example:
#include <stdio.h> int main() { int i; for(i = 0; i < 4; i++) { printf("hello, world!\n", i); } return 0; }shows some garbage for the first one or two lines when compiled with LMM mode and -Os and run with proploader. The last 2 or 3 lines come out OK.Ray
I think noise maybe part of the problem.
Try this
This would indicate that the print channel is still open.
Given that there is also a problem with the back to back read/write with fsrw, It begs the question as to
whether the two problems are related.
Ron
Regards
Ron
Setting fast-loader-baud-rate to 115200 does fix the problem. So it seems it's something in the transition from the fast download speed to the "normal" 115200 that causes the corruption. It may even be an OS issue? Although it seems to happen on both Windows and Linux.
Pin 30 is the serial pin, so if you explicitly toggle it then strange things are going to happen on the terminal. I don't think there's any way around that!
The back to back read/write problem with fsrw was a bug in the BASIC close function. That'll be fixed in the next release. Is there some other read/write problem you've noticed (when BASIC close is not called)?
Thanks,
Eric
Good point, it may be that the only solution is to insert a delay (or to use -D fast-loader-baud-rate=115200). Having a delay at the start of the program is pretty common, so that may not be too bad.
Any change in Baud speed, does take time in modern OS.
If the Prop is alive at that stage, it could easily send-before ready.
Options would be to delay as discussed (somewhat klunky, but works), or wait on some ready signal from the PC side.
It may be possible to define an optional char the fast loader can send, when it is speed-changed, to give a simple handshake that acts as a ready signal ?
That's one workaround, but for those wanting to keep fast loader, and friendly, you could also ask Jeff about a user optional ready Char it can send when terminal is 'up' at changed baud speed.
Ok, that's good to know I just assumed the output port would close after a print and the input port
would open (they would toggle). I now understand why that would never work.
No other issues. Looking forward to the next release
Thanks
Ron
Below is my test_temp program and the values that are being printed are way off. Did something happen to the '#' floating point variable, in the last update of fastspin?
I also tried using '%' integer variable in place of '#', to see what would happen, still was getting some way off results. I also noticed that by using '%' integer variable, it increased the size of the program by ~4000. I thought it would be the other way around.
Ray
Been so long since I've used BASIC, I think I need to relearn...
waitcnt getcnt clkfreq waitpeq waitpne const heapsize new delete chr$
Also, what is with "mscycles"?
Do you need to define it to use "pausems"?
Think the way described in the docs is old, one should use "class" now...
Does this look OK?
rem simple program to toggle a pin while outputting characters '' create a Spin FullDuplexSerial object class fullduplex using "FullDuplexSerial.spin" dim ser as fullduplex 'Going to toggle pin #1 every 1/10 of a second const pin = 1 let mscycles = clkfreq / 1000 direction(pin) = output rem first, wait for user to press a key in serial terminal var r = ser.rx() 'Then, loop forever do output(pin) = not output(pin) ser.tx("Hello.") ser.tx(13) pausems 1000 loopThat compiles for P1, but for P2 I get this:
Works on P2. See the CR is automatic now.
Used p2load, works fine. Can use propellent for P1, I think.
Wish there was a simple input method to go with "print"... Something like GetChar or something...
"print" works without any setup...
Anyway, this sample code seems to work fine on P2:
For P2, I think there's a bug because I get this: