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

New BASIC compiler for Prop1 and Prop2

1568101120

Comments

  • David Betz wrote: »
    FYI, I tried this today and ran the "blink1.bas" sample program. It worked fine on the ActivityBoard WX after I changed the PIN number to 26. I only tried a serial download.

    I have a WX now, and while I haven't tried it on a Mac on Windows proploader found and used my Wifi module automatically (so spin2gui worked with it out of the box). Nice job on proploader, David -- it was very seamless and easy to use!
  • I tried my WX Activity Board setup again, it works, using spin2gui, BUT. This is a real big BUT, you can only have one WiFi board on that is transmitting. If you have two units on then chances are that spin2gui will not pick the right board port to use.

    The only way around this issue for spin2gui, is to have a port choice column to pick the unit(port) that you are using. Since I will probably have more than one WiFi unit running at all times, at this time this scenario is not very practical.

    You may want to consider setting up fastspin(BASIC) to run within SimpleIDE, then that COM choice problem could be resolved. SimpleIDE has the port selection choice, so you just pick the port, and program away.

    Now, if you go to a command line process, or use something like Geany, this also becomes not practical. You will then have to figure out what the IP address is, of your WiFi module, and than include that with your method of working with the Propeller chip.

    When I think about this now, I have had some problems with the way SimpleIDE works, for handling the port issue. You have to very aware of which port that you are going to use when you hit the program button. I have been caught on this many times having programmed the wrong unit because I did not check the port choice.

    Ray
  • yetiyeti Posts: 818
    edited 2018-10-21 20:59
    Rsadeika wrote: »
    When I think about this now, I have had some problems with the way SimpleIDE works, for handling the port issue. You have to very aware of which port that you are going to use when you hit the program button. I have been caught on this many times having programmed the wrong unit because I did not check the port choice.
    With Linux I can distinguish boards if the USB UART somehow is individual e.g. by having a unique serial number in its USB descriptor.
    $ ls -l /dev/GG-* 
    lrwxrwxrwx 1 root root 7 Okt 21 20:05 /dev/GG-PP-SD-USB-HK-C -> ttyUSB0
    
    This works OOTB with FT232 UARTs which are delivered with a random serial number. CP2102 UARTs come not individualised but their EEPROM contents can be changed.

    The magic is done by UDEV rules which can make symlinks to the real device entry.
    $ fgrep -B2 GG /etc/udev/rules.d/99-local-usb-serial.rules
    SUBSYSTEM=="tty", \
            ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A800BSBW", \
            OWNER="yeti", GROUP="yeti", MODE:="0660", SYMLINK+="GG-PP-SD-USB-HK-C"
    
    Just one piece is missing: Propeller loaders scanning for Propellers on the ports ignore the links. But they work as expected:
    $ cat moo.bas 
    print "Moo!"
    $ /opt/spin2cpp/bin/fastspin -q -O2 moo.bas
    $ /opt/spin2cpp/bin/proploader -r -t -p /dev/GG-PP-SD-USB-HK-C moo.binary 
    Opening file 'moo.binary'
    Downloading file to port /dev/GG-PP-SD-USB-HK-C
    1420 bytes sent                  
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
    Moo!
    
    Are you using something Linux-ish?
    Or maybe someone knows how to do something similar on other OSes?
  • Rsadeika wrote: »
    I tried my WX Activity Board setup again, it works, using spin2gui, BUT. This is a real big BUT, you can only have one WiFi board on that is transmitting. If you have two units on then chances are that spin2gui will not pick the right board port to use.
    Ah, OK, I only have the one WX board, so it wasn't a problem for me.

    You can always use the "Configure Commands..." menu item to change the proploader command line (for example to include '-i IPADDRESS' to select the board). I realize that's not very user friendly, but it will at least guarantee that you get the right board.
    You may want to consider setting up fastspin(BASIC) to run within SimpleIDE, then that COM choice problem could be resolved. SimpleIDE has the port selection choice, so you just pick the port, and program away.
    I submitted a pull request for SimpleIDE a while back to support fastspin (just the plain Spin version) but I don't think it's ever been merged. I'm not sure if SimpleIDE is still supported very actively.

    I'm not really focused right now on developing the GUI, I'm trying to get the basic compiler finished first. But thanks for pointing out this issue. If I can think of a simple way to provide a board choice for spin2gui I'll add it.

    Regards,
    Eric
  • There are new releases of fastspin and spin2gui up on github now. This version should fix the DHTnn_Object problem Ray found, as well as a few other bugs I ran into while testing.

    If you haven't updated for a while, this version (3.9.7) also includes the try/catch handling and anonymous functions that were in 3.9.6, and reduces COG memory usage a lot.

    I definitely suggest users update to the latest release if they're interested in BASIC support.

    Eric
  • Just downloaded the latest spin2gui, and the problem persists.

    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#)
    
    do
    	cm2302.DHTnn_Read()
    	print "Temp ";(9.0/5.0)*temp# + 32.0;"  Humid  ";humid#
    	pausems 3000
    
    loop
    
    G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.6 Compiled on: Oct 19 2018
    test_temp.bas
    |-DHTnn_Object.spin
    |-|-FloatMath.spin
    test_temp.pasm
    Done.
    G:/fastspin/programs/test_temp/test_temp.pasm(719) error: Unknown symbol Dhtnn_object_dhtnn_read_tmp003_
    G:/fastspin/programs/test_temp/test_temp.pasm(771) error: Unknown symbol Dhtnn_object_dhtnn_read_tmp003_
    child process exited abnormally
  • Aargh! Sorry Ray, somehow the wrong fastspin compiler got in the release (it should have been 3.9.7, not 3.9.6). It should be fixed now, could you try it again?

    Thanks,
    Eric
  • I downloaded the latest spin2gui, new problem has emerged. The program compiles without errors, but there is nothing being output to the terminal screen.

    Also, the Compiler Output screen area is doing some kind of jiggling or slow weird updating of that area of the screen. But the main problem is that there is nothing being displayed to the terminal screen.

    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#)
    
    do
    	cm2302.DHTnn_Read()
    	print "Temp ";(9.0/5.0)*temp# + 32.0;"  Humid  ";humid#
    	pausems 3000
    
    loop
    
    Compiler Output
    G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.7 Compiled on: Oct 21 2018
    test_temp.bas
    |-DHTnn_Object.spin
    |-|-FloatMath.spin
    test_temp.pasm
    Done.
    Program size is 8832 bytes
    cmd.exe /c start G:/fastspin/spin2gui/bin/proploader G:/fastspin/programs/test_temp/test_temp.binary -r -t -k
    Terminal screen
    Opening file 'G:/fastspin/programs/test_temp/test_temp.binary'
    Downloading file to port 192.168.1.147
    8832 bytes sent
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
  • Ray:

    I think the problem is that fastspin is *too* fast now :). The StartDHTnn method relies on the remote COG reading its pointers from the stack, which is fine in "regular" Spin (where the Spin interpreter is a lot slower than the remote COG) but can be a problem in fastspin. I stuck a small delay after the init, like:
      cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
      waitcnt(getcnt() + 10_000_000)
    
    and started getting output. Note that it should be the waitcnt/getcnt combo, not pausems -- pausems is a function call so it may mess up the stack that the COG is still reading.

    I always get a temperature of 32 and humidity of 0 from my Activity board. But the same thing happens when I try the regular Spin DHT11_Test.spin (compiled with openspin or fastspin, both give the same results). I don't know what needs to be done to change that.

    Thanks for your help testing this!

    Eric
  • It sort looks like it has something to do with the Spin object, but I do not know what to do with it. I tried something a little different just see what would happen when I put the 'cm2302.DHTnn_Read()' into a sub, I get some kind of different error. I thought it would just hang, and not print anything to 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#)
    
    sub cm2302
    	cm2302.DHTnn_Read()
    end sub
    
    do
    	'cm2302.DHTnn_Read()
    	cm2302
    	print "Temp ";(9.0/5.0)*temp# + 32.0;"  Humid  ";humid#
    	'waitcnt(getcnt() + 10_000_000)
    	pausems 3000
    
    loop
    
    G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
    Version 3.9.7 Compiled on: Oct 21 2018
    test_temp.bas
    |-DHTnn_Object.spin
    |-|-FloatMath.spin
    G:/fastspin/programs/test_temp/test_temp.bas(5) error: Internal error: unknown type 51 passed to IsArrayType
    child process exited abnormally
  • The "internal error" should be a more helpful error message :). The problem is that you used the same symbol name "cm2302" both for the object and for the sub, and so the compiler got confused. If you change the sub name to something like "cm2302_read" it will compile (but not work, for that you need the delay that I mentioned earlier).
  • Eric

    I have tried to render some html code from the sdcard. However the input string length appears to be limited to only 127 characters. The other issues is that we do not know the file length at the time of read back, so we can't define s$ length

    openfile(3, "test2.txt", "r")
    s$ = input$(127, 3)
    

    Your readback code that I have been looking at.
    #ifdef TRY_READ
      pausems 500
      ' try reading it back
      print "testing read"
      openfile(3, "test2.txt", "r")
      s$ = input$(127, 3)
      if s$ then
        print "read back:"
        print s$
      else
        print "got end of file"
      endif
      close #3
    #endif
      print "all done"
    
    catch err
    
      print "caught error: "; err
    
    end try
    
    
    
  • input$(N, handle) reads up to N bytes from the file. I don't think there should be any limit on N, except for memory (and in particular the size of the garbage collected heap, set by HEAPSIZE; if you want to read large files you'll have to add a "const HEAPSIZE = XXXX" declaration, where XXXX is some big number (but not so big that it overflows memory -- sorry, this isn't automatic right now, so you have to do some experimentation).

    You can use multiple input$(N, handle) calls and add them together. So for example the read loop could look like:
    dim file$
    file$ = ""
    do
      s$ = input$(20, 2) ' read up to 20 characters at a time
      file$ = file$ + s$
    loop until s$ = ""  ' loop until end of file
    
    print file$
    
    At least, that's the theory. I think there are probably bugs in practice :(
  • ### INPUT$

    A predefined string function. `input$(n, h)` reads `n` characters from handle `h`, as created by an `open device as #h` statement.
    Is there an `input$()` variant for the default IO channel I'm just overlooking?
  • ersmithersmith Posts: 5,900
    edited 2018-10-23 15:59
    yeti wrote: »
    ### INPUT$

    A predefined string function. `input$(n, h)` reads `n` characters from handle `h`, as created by an `open device as #h` statement.
    Is there an `input$()` variant for the default IO channel I'm just overlooking?

    I forgot to document it, but if you leave out the h and use just plain `input$(n)` then it reads `n` characters from the default channel.
  • Eric

    The first issue was HEAPSIZE however the html file was less than 254 bytes. Therefore
    s$=input$(254,3) was not full filled before it reached end of file!

    Looks like I have to count the chars in a getc loop before I build s$
    or is there another way to get the file size ?

    I like the idea oft getting s$ by concatenating the s$ blocks in a loop


    Ron
  • rsut wrote: »
    The first issue was HEAPSIZE however the html file was less than 254 bytes. Therefore
    s$=input$(254,3) was not full filled before it reached end of file!
    That's OK -- input$() will read as much as it can up to the limit you give it. That is, the 254 is a maximum size, but the string returned by input$ could be smaller. If the file only has 200 characters than input$(254, 3) should return a 200 character string. (The current implementation does actually allocate space for 254 bytes in this case, so there is some memory wasted.)
    Looks like I have to count the chars in a getc loop before I build s$
    or is there another way to get the file size ?
    If you just read small chunks at a time and concatenate the chunks to build a bigger string then there's no need to know the file size. This string concatenation will only work if the file doesn't contain NUL bytes (0). For binary files we'll need another solution, but for text files it should be fine.

    I think fsrw does have a getfilesize method too.

    Regards,
    Eric
  • Yep, there is a getfilesize in fsrw I missed it.

    Thinking about it, building a string for simply printing a file makes no sense. Printing a ubyte in a getc loop until eof is much better, so will post something to the other thread later for other comments.

    Thanks again

    Ron
  • Something strange is going on with latest spin2gui program. I used the -p COMxx in Configure Commands, to select a com port. It seems to compile and run, but I am seeing some garbage characters on the terminal screen. Not sure where that is coming from.

    It looks like the print string is getting clobbered. I am using a board that does not have any WiFi components.

    Ray
    rem test1.bas
    
    ' Declarations
    const pin = 26
    
    let mscycles = clkfreq / 1000
    direction(pin) = output
    
    
    '******************************
    'Main
    print "will I see something"
    
    do
    	output(pin) = not output(pin)
    	pausems 1000
    loop
    
    '******************************
    'Subs and Functions
    sub pausems(ms)
    	waitcnt(getcnt() + ms * mscycles)
    end sub
    
    Opening file 'G:/fastspin/programs/test1/test1.binary'
    Downloading file to port COM3
    1676 bytes sent
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
    ÇÇÇÇ ÇÇ ÇÇ ÇÇ Ç Ç Ç ÇÇÇ »{Ésomething
  • Ray: are you using a QuickStart board or something similar? I have sometimes seen boards where there is some noise at the beginning. I get this in any language (not just fastspin). I think it's because pin 30 is floating when the program starts up and so there's a problem syncing the serial port.

    On my WX Activity board your program runs without issue.
  • This started showing up on my WX Activity Board. The latest board, an Activity Board (no WiFi), shows that problem also. I just tried a Propeller Project Board, that also shows the same problem. So, of the three boards, they all show the clobbered print string.

    I think that I might have to figure out a different way of working with fastspin(BASIC), this getting to be too unpredictable.

    Ray
  • I opened up a command prompt window in Windows 10, and I manually did a proploader command. It sort looks like fastspin(BASIC) is not cooperating with the new proploader.exe program, I could be wrong about this.

    For the people that are not using proploader.exe, what is your setup for working with fastspin(BASIC)?

    Ray
    G:\fastspin>proploader -p COM3 -t g:/fastspin/programs/test1/test1.binary
    Opening file 'g:/fastspin/programs/test1/test1.binary'
    Downloading file to port COM3
    1676 bytes sent
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
    ÇÇÇÇ ÇÇ ÇÇ ÇÇ Ç Ç Ç ÇÇ┘e something
  • Ray try this
    let mscycles = clkfreq / 1000
    direction(pin) = output
    pausems 10              REM add this line here in your code
    
    

    Ron
  • Thanks Ron, but that did not help, still getting a clobbered print string. I would like to see this work because when I debug a program, I use a terminal output to see the debug results.

    While looking at the proploader.exe program I noticed it has a command for writing to the SD card, I wonder how that works. Also, I noticed a capability for writing a program to the eeprom, I will probably have to try that also.

    Ray
  • Not to step on anybody's toes or to make people upset, I tried the following small program below with the proploader.exe in the Command line window. It seems that the print string in the C program seems to be showing as expected, in the terminal window.

    It seems like something changed in the proploader.exe vs the propeller-loader.exe that fastspin(BASIC) was using, originally.
    Not sure what to check or verify next.

    Ray
    /*
      Blank Simple Project.c
      http://learn.parallax.com/propeller-c-tutorials 
    */
    #include "simpletools.h"                      // Include simple tools
    
    int main()                                    // Main function
    {
      // Add startup code here.
    
     print("This is a test\n");
      while(1)
      {
        // Add main loop code here.
        
      }  
    }
    
    
    G:\fastspin>proploader -p COM3 -t -r g:/programs/propeller/load_test/load_test.elf
    Opening file 'g:/programs/propeller/load_test/load_test.elf'
    Downloading file to port COM3
    8284 bytes sent
    Verifying RAM
    Download successful!
    [ Entering terminal mode. Type ESC or Control-C to exit. ]
    This is a test
  • @Rsadeika, which FastSpin version do you use?
    Did you try the freshest version?
    Can you build FastSpin from git sources?
  • Ray:

    If you put the print in a loop, does the corruption happen every time, or is it only for the first time it is printed?

    Does the blinking part of the program work correctly?
  • rsutrsut Posts: 45
    edited 2018-10-25 08:19
    Eric


    I do have to add a small delay to make Ray's code work.
    The 1 ms delay is an arbitrary value at this stage. I am using Windows 10, like Ray.

    I use fastspin --fcache=0 -e -O1 %f in a batch file to compile and
    propeller-load -e -p3 -r -t %1.eeprom in a batch file to load.

    Without a short delay the first character is missing from the output in the command line window.
    It is the just the same if I use my terminal software Tera Term Pro after a prop reset.

    I have checked this on both my Prop demo board and on my Arty7 FPGA board running P1.
    I was suspicious of some ringing (when tthe DIR reg is changed) on my low quality USB cable to the Prop Demo Board but I have high quality USB cable to the FPGA board and the results are identical.
    And good quality PSUs for both boards

    Ray is using different pin out, whereas I am using the default pin which is probably pre set to out,
    I should nave checked that.


    Hope it helps

    Ron


  • Have you tried it without the --fcache=0? That shouldn't be necessary any more, and definitely will affect performance. I also tend to run directly rather than loading into EEPROM, which probably changes the startup timing.
  • Tried that.

    Same result, still need the 1ms pause.

    Misses first two chars.


    Ron
Sign In or Register to comment.