Shop OBEX P1 Docs P2 Docs Learn Events
New BASIC compiler for Prop1 and Prop2 - Page 9 — Parallax Forums

New BASIC compiler for Prop1 and Prop2

1679111220

Comments

  • 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
  • Rsadeika wrote: »
    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.

    Ray
  • Rsadeika wrote: »
    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?
  • PublisonPublison Posts: 12,366
    edited 2018-10-25 12:46
    This is a copy from ProplyBlock, so it should be recent.

    (BTW I found propeller-load in my SimpleIDE folder)
  • The attached zip file contains both, test1.bas and test1.binary.

    Ray
  • Rsadeika wrote: »
    The attached zip file contains both, test1.bas and test1.binary.

    Ray
    Thanks! I'll try to look at this tonight. I'm at work at the moment.

  • 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
  • Rsadeika wrote: »
    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.

  • Did you try setting fast-loader-baud-rate to 115200? Does that fix the problem?
  • 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
  • rsutrsut Posts: 45
    edited 2018-10-25 16:51
    Eric

    I think noise maybe part of the problem.
    Try this
    
    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


    Regards

    Ron
  • David Betz wrote: »
    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.

  • ersmith wrote: »
    David Betz wrote: »
    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.

  • rsut wrote: »
    Eric

    I think noise maybe part of the problem.
    Try this
    
    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)?

    Thanks,
    Eric
  • ersmithersmith Posts: 6,068
    edited 2018-10-25 18:37
    David Betz wrote: »
    ersmith wrote: »
    David Betz wrote: »
    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.
  • ersmith wrote: »
    David Betz wrote: »
    ersmith wrote: »
    David Betz wrote: »
    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.
  • jmgjmg Posts: 15,175
    ersmith wrote: »
    David Betz wrote: »
    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 ?
  • jmgjmg Posts: 15,175
    David Betz wrote: »
    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.
  • Eric

    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 :smile:

    Thanks

    Ron
  • 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
  • RaymanRayman Posts: 14,755
    I think I'm close to having a decent colorizer for FastBasic in SpinEdit (see attached).

    Been so long since I've used BASIC, I think I need to relearn...
    937 x 910 - 45K
  • RaymanRayman Posts: 14,755
    edited 2018-10-27 17:52
    I think I see some keywords not in documentation's list:
    waitcnt getcnt clkfreq waitpeq waitpne const heapsize new delete chr$

    Also, what is with "mscycles"?
    Do you need to define it to use "pausems"?
  • RaymanRayman Posts: 14,755
    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
    

    That compiles for P1, but for P2 I get this:
    D:\Propeller\Code\SpinEdit\temp>fastspin -2 BasEditTest1.bas
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.7 Compiled on: Oct 21 2018
    BasEditTest1.bas
    |-FullDuplexSerial.spin
    FullDuplexSerial.spin(191) error: syntax error, unexpected identifier `Jmpret'
    FullDuplexSerial.spin(202) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(209) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(213) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(233) error: syntax error, unexpected identifier `Jmpret'
    FullDuplexSerial.spin(256) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(264) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(269) error: syntax error, unexpected ':'
    FullDuplexSerial.spin(271) error: syntax error, unexpected ':'
    
  • RaymanRayman Posts: 14,755
    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...
  • Rayman wrote: »
    Wish there was a simple input method to go with "print"... Something like GetChar or something...
    Look for `input$()` in FastSpin-BASIC's doc.
  • RaymanRayman Posts: 14,755
    edited 2018-10-27 18:31
    I see this:
    ### 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
    
  • yetiyeti Posts: 818
    edited 2018-10-27 18:36
    If no `h` is specified (just `input$(n)` is used) then the default serial device will be used.
    print input$(80)
    
  • RaymanRayman Posts: 14,755
    Thanks! that does work for P1.
    For P2, I think there's a bug because I get this:
    error: Unknown symbol _rx
    
Sign In or Register to comment.