P2 Newbie Discussion

24

Comments

  • I think your problem is that you're giving fastspin the -1 option which I believe tells it to compile code for P1. You need to specify -2 to compiler for P2.
  • Not a source of errors, yet, but didn't we only get 8 COGs in the silicon?

    At some point, initializing x to 15 may cause some issues.
    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • David,
    Fast spin does not show a gui it just flashes and disappears.
  • Fastspin is a command line program called by spin2gui. Spin2gui can generate code for either Prop 1 or 2 - you have to tell it which. Go to Commands->Configure Commands->P2 Defaults and it will now generate code for P2. Unfortunately I think the default clock settings, etc., are still valid for the FPGA only so it's very likely not going to work. The LED (basepin) is referencing the wroig pins for the ES board as well. The only way I get anything to reliably run at the moment is with PASM code generated and loaded with PNut. I think the less techy folks (me!) need to wait for the low level tool makers to evolve the tools.
  • pilot0315 wrote: »
    Tried that and got this error.

    Can you cut & paste the program in a Code block so we can try it?
    Thanks
    Tom
  • Eric may be away for the holidays or waiting for his P2-Eval board to be delivered. I suspect he'll update spin2gui when he gets back.
  • cgraceycgracey Posts: 10,922
    edited 2018-12-28 - 21:00:03
    Peter, I have a question about your Forth.

    I understand it can be augmented by new "words", but can these words be used to invoke PASM code? Or, can the words only invoke your Forth primitives?
  • pmrobert wrote: »
    Fastspin is a command line program called by spin2gui. Spin2gui can generate code for either Prop 1 or 2 - you have to tell it which. Go to Commands->Configure Commands->P2 Defaults and it will now generate code for P2. Unfortunately I think the default clock settings, etc., are still valid for the FPGA only so it's very likely not going to work. The LED (basepin) is referencing the wroig pins for the ES board as well. The only way I get anything to reliably run at the moment is with PASM code generated and loaded with PNut. I think the less techy folks (me!) need to wait for the low level tool makers to evolve the tools.

    I've listed the steps that have worked with Windows to use spin2gui in this post. It does take a few steps, but is not that difficult. However, the first step is to make sure that the program compiles without an error, setting the Command to P2 defaults.

    https://forums.parallax.com/discussion/comment/1459371/#Comment_1459371
  • Do you have Spin2GUI set for the P2?
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • @Dave Hein,
    Do you have a loadp2.exe of the latest version that you could post or link to?

    Thanks,
    Tom
  • pmrobert wrote: »
    Excellent idea Zappman!

    I'll go first - I'm unable to get any of the code in spin2gui/samples to actually run - not even helloworld. The binaries appear to load but nothing appears out the serial pins and even trying to just bring a pin high and low does nothing. I'm using the latest spin2cpp files as well. TAQOZ does run fine and I'm positive I have a good USB cable feeding the P2-ES board. Perhaps the sample code is configured somehow for the FPGAs and things are inoperative due to that? I've looked at the generated .asm and .lst files and nothing jumps out at me. The pin designation for tx is correct, etc. Ideas are appreciated!

    Thanks, Mike R...

    I also have this problem. No luck with loadp2 or the Python loader. The problem is not fastspin, for it produced a blinkey binary identical to PNut. PNut works perfectly after setting up the serial port with wine. Editing is fine too. Note: I'm on an arm machine, using Exagear to run x86 apps. So PNut+WIne+Exagear works.
    James https://github.com/SaucySoliton/

    Invention is the Science of Laziness
  • Don't suppose these issues have anything to do with the need to invert the DTR signal? I'm not that familiar with the 2 stage loaders, but its easy to try with FT_Prog. Just do a power down/up after making the change

  • Now have my P2-EVAL board running great. Thanks everyone at Parallax !!!

    I use Ubuntu 18.04 (fully updated) LTS

    Problems encountered so far (hoping i save others same wasted time)

    1. Use a decent quality USB cable.
    2. Use a USB3.0 port for connection to the P2 if available. (Provides more power ?)
    3. Linux really wants to save power and can AUTOSUSPEND USB ports. This causes unexpected
    board resets and can make your terminal program fail silently.

    My solution was to "sudo apt install powertop". Run "sudo powertop". Hit the TAB key 4 times
    until you reach the Tunables section. Use down arrow, and enter key to set BOTH the P2 usb
    port and the USB Host device it is connected on to Bad.
    This disables all attempts by the kernel to power the port down silently. To exit Hit ESC Key, and
    wait (maybe about 10 secs). You have to do this after EVERY bootup.

    Thus is what it should look like after your changes

    Bad Autosuspend for USB device Propeller P2-EVAL-ES [Parallax Inc.]
    Bad Autosuspend for USB device xHCI Host Controller [usb1]

    4. Many linux terminal programs suck. I am using dterm and it works well.
    You may need to "sudo apt install readline-dev" before u "make".
    It can be downloaded from http://www.knossos.net.nz/resources/free-software/dterm/

    In my case i use "dterm /dev/ttyUSB0 115200". Use Control-] to get the command prompt
    dterm>. "?" will give you a list of commands. "show" is also useful. You can reset the P2-EVAL
    board by doing

    dterm>d (drops dtr. wait 1 sec.)
    dterm>d (raises dtr and resets the board. You can see this from the P2-EVAL board leds)
    dterm> (use enter key to return to your terminal session and type ">" then space and then)
    (either ESC key for TAQOZ or CTRL-D for P2-MONITOR)

    5. FTDI drivers are included in Ubuntu 18.04 and work out of the box. If strange things happen or
    stuff doesnt work, open a spare terminal (Ctrl-Alt-T) and "dmesg -w" to watch kernel messages
    in real time. Leave this terminal open. If you see stuff like:

    [83661.955425] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83662.563543] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83666.353259] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83670.147583] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83716.739343] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83717.347503] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83717.683343] ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
    [83723.107604] ftdi_sio ttyUSB0: failed to get modem status: -71
    [83723.108071] ftdi_sio ttyUSB0: failed to get modem status: -71
    [83723.108191] ftdi_sio ttyUSB0: error from flowcontrol urb
    [83748.278571] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
    [83748.278666] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
    [83748.278792] ftdi_sio ttyUSB0: urb failed to clear flow control
    [83748.279044] ftdi_sio ttyUSB0: failed to get modem status: -71
    [83748.279170] ftdi_sio ttyUSB0: urb failed to clear flow control
    [83748.279299] ftdi_sio ttyUSB0: failed to get modem status: -71
    [83748.279428] ftdi_sio ttyUSB0: failed to get modem status: -71
    [83748.289699] ftdi_sio ttyUSB0: failed to get modem status: -71

    then exit your terminal program, and unplug the usb cable to the P2, wait 10 secs and plug it
    back in, and restart your terminal program.

    6. /dev/ttyUSB0 is only created AFTER you P2 board is plugged in. (Its created dynamically and removed
    according to udev rules). This means you can only start your terminal program AFTER you connect
    the P2 with the usb cable. dterm exits if u unplug the usb cable. (which is the correct behaviour)
    and wont start until the P2 is connected via usb. It also prints an error message if u attempt this.

    7. if you cant access /dev/ttyUSBx because you dont have the correct permissions
    (use id in shell to check your groups, and ls -lsa /dev/ttyUSBn to see permissions), you may need

    "sudo usermod -a -G dialout your-username-here", followed by a restart.

    Sorry for the wall of text, hoping i save others the time and hassle.




  • Sounds like we need a programming jumper on the reset line for Linux users...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Sounds like we need a programming jumper on the reset line for Linux users...

    Actually, i am quite happy with the way it functions. Now i fixed all the other problems it works great.

    Only one thing remains, after i run dterm, i then want to be able to run loadp2 from inside dterm, because
    exiting dterm and then starting loadp2 will cause dtr to be cycled and do a board reset. I shall think in more
    detail and have a look at loadp2 tomorrow. (the reset occurs not on dropping dtr but on raising it again).

    Are there jumpers on the board to change the behaviour of DTR ? Its late here, so tomorrow i will find
    the board schematic and have a look.

    Does this differ from the behaviour under Windows ? (I have not tried windows)

    Is there something in the current behaviour that is not desirable ? (I am a Propellor Newbie, so i have
    no idea what long time users expect)
  • I'm running minicom on Linux Mint 19.1 but curiously have never had any issues or anything special that I needed to do. This is both on the desktop and laptops that I use.

    I also find it easier to use p2asm and loadp2 along with the m4 preprocessor.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2CHIP-1.jpg
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • To twm47099:
    Here is the code it is from parallax and the error in spin2 gui
  • The tools do not like the space in the directory: "p2 ide"...


    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • twm47099twm47099 Posts: 801
    edited 2018-12-29 - 19:14:42
    @pilot0315
    I initially got an error complaining about loop. I deleted the "." in "#.loop".
    Then it compiled ok.
    When I loaded it, nothing appeared to happen. But looking at
    blink		cogid	x		'which cog am I, 0..15?
    		add	x,#32		'add 32 to get pin 32..47
    
    the program is trying to blink LEDs on pins 32 to 47. I don't have any LEDs on those pins, but I do on pins 1 to 4. So I changed
    add x, #32
    
    to
    add x, #0
    

    When it ran those 4 lights lit but did not appear to blink.

    Looking at all of "blink"
    blink		cogid	x		'which cog am I, 0..15?
    		add	x,#0		'add 32 to get pin 32..47      **** I changed to #0  
    		drvnot	x		'output and flip that pin
    		shl	x,#16		'shift up to make it big
    		waitx	x		'wait that many clocks
    		jmp	#blink		'do it again
    
    I saw that the maximum time delay between blinks was 15 << 16 which equals approx 49ms at RCFAST (20 MHz).
    I changed
    shl	x,#16		'shift up to make it big
    
    to
    shl   x, #20
    
    which is approx .8 sec
    Now the code is blinking my 4 LEDs at different rates (P1 very fast, P4 fast).

    If you only have the LEDs on the P2-ES board adjust the "add x" instruction to control those pins.
    Hope this helps.
    Tom
  • ElectrodudeElectrodude Posts: 1,269
    edited 2018-12-29 - 19:21:16
    loadp2 wouldn't work for me on linux, so I wrote a simple and ugly shell script that does it. It doesn't reset the P2 for you (yet); you have to reset it yourself. It hangs forever if you forget the P2 before running it; you have to manually interrupt it and try again when that happens. It doesn't use a checksum, and I haven't made any big programs yet; try lowering the baud if you have problems.
    #!/bin/bash
    
    # Usage: loadp2.sh <port> <binary>
    
    port="$1"
    binary="$2"
    baud=1000000
    
    # bind and configure serial port
    exec 3<> "$port"
    stty -hup igncr "$baud" <&3
    
    
    # send identification request
    (echo -ne '> Prop_Chk 0 0 0 0 ') >&3
    
    # get blank line
    read r1 <&3 && [[ -z "$r1" ]] || (echo "Bad response: $r1"; exit 1)
    # get identification string
    read r2 <&3 && [[ "$r2" == Prop_Ver\ * ]] && echo $r2 || (echo "Bad response: $r2"; exit 1)
    
    
    # send binary in Base64 and run
    (echo -n '> Prop_Txt 0 0 0 0 ' && base64 "$binary" && echo -n '~') >&3
    
  • jmgjmg Posts: 13,226
    Rayman wrote: »
    Sounds like we need a programming jumper on the reset line for Linux users...

    Given reset is at the mercy of all the OS variants and settings, that would be a good idea for any revision.
    There is already a reset button on board, so a reset-jumper allows isolate of all COM side, for up-time testing.
    There are also dual Brownout_reset parts that connect to P2_RESN via DIPSW.
  • I agree, a jumper to disconnect reset would be very useful, given all of the differences in how the DTR line is treated.
  • @twm47099
    I will try that.
    Thanks
    twm47099 wrote: »
    @pilot0315
    I initially got an error complaining about loop. I deleted the "." in "#.loop".
    Then it compiled ok.
    When I loaded it, nothing appeared to happen. But looking at
    blink		cogid	x		'which cog am I, 0..15?
    		add	x,#32		'add 32 to get pin 32..47
    
    the program is trying to blink LEDs on pins 32 to 47. I don't have any LEDs on those pins, but I do on pins 1 to 4. So I changed
    add x, #32
    
    to
    add x, #0
    

    When it ran those 4 lights lit but did not appear to blink.

    Looking at all of "blink"
    blink		cogid	x		'which cog am I, 0..15?
    		add	x,#0		'add 32 to get pin 32..47      **** I changed to #0  
    		drvnot	x		'output and flip that pin
    		shl	x,#16		'shift up to make it big
    		waitx	x		'wait that many clocks
    		jmp	#blink		'do it again
    
    I saw that the maximum time delay between blinks was 15 << 16 which equals approx 49ms at RCFAST (20 MHz).
    I changed
    shl	x,#16		'shift up to make it big
    
    to
    shl   x, #20
    
    which is approx .8 sec
    Now the code is blinking my 4 LEDs at different rates (P1 very fast, P4 fast).

    If you only have the LEDs on the P2-ES board adjust the "add x" instruction to control those pins.
    Hope this helps.
    Tom
    Still got the error listed below in the window. I changed one value but the gui spin2gui won't work


    1023 x 677 - 78K
  • msrobotsmsrobots Posts: 2,439
    edited 2018-12-29 - 20:37:05
    jmg wrote: »
    Rayman wrote: »
    Sounds like we need a programming jumper on the reset line for Linux users...

    Given reset is at the mercy of all the OS variants and settings, that would be a good idea for any revision of any board.
    There is already a reset button on board, so a reset-jumper allows isolate of all COM side, for up-time testing.
    There are also dual Brownout_reset parts that connect to P2_RESN via DIPSW.

    I added the bold stuff.

    Finally someone agrees, I am almost preaching about this. It is just two pins, a jumper, two holes. That can not be much on the BOM and I guess a Pick and Place can also place complete jumpers.

    PLEASE guys do that on all Propeller boards.

    And it's not just for Linux User, Windows does also cruel things to the com ports, like enumerating them under different COMXX as before the last reboot.

    I usually have multiple Propeller connected to my PC for different functions. But I just need to program one of them, the other ones doing their jobs.

    You can not imagine how often I accidently overwrite the wrong EEPROM, interrupt its function, run in danger that the wrong code hits pins with completely different components on it, have to reload the correct code, go back to my project and start again to load it into the hopefully right EEPROM.

    A jumper (or even switch) on the reset line from the FTDI could prevent all of this hassle and danger. If you can't reset it, you can't program it.

    PLEASE, on all Boards you make, please

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • markmpx wrote: »
    4. Many linux terminal programs suck. I am using dterm and it works well.
    You may need to "sudo apt install readline-dev" before u "make".
    It can be downloaded from http://www.knossos.net.nz/resources/free-software/dterm/
    Fairly sure that you need to use: "sudo apt install libreadline-dev", to get readline into Debian Linux (and most likely, Ubuntu).

    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • jmgjmg Posts: 13,226
    msrobots wrote: »
    Finally someone agrees, I am almost preaching about this. It is just two pins, a jumper, two holes. That can not be much on the BOM and I guess a Pick and Place can also place complete jumpers.

    A fitted jumper does impact the BOM, but a footprint is very close to true zero cost, so adding the footprint is something that should be on all boards.

    I've seen Eval Boards that use a nifty default solder bridge too.
    It is artwork like -(>>)- and there are 2 versions. One with paste, one without. The paste one (hopefully) defaults bridged.
    These bridges are easy to spot, and easy to change.
  • ok, a foot print would already be golden but at least holes, just cut in between and one can solder the header in.

    Currently I have to check every board where and if I can disable /RST and put some wires to archive my independence from external reset.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • dgately wrote: »
    markmpx wrote: »
    4. Many linux terminal programs suck. I am using dterm and it works well.
    You may need to "sudo apt install readline-dev" before u "make".
    It can be downloaded from http://www.knossos.net.nz/resources/free-software/dterm/
    Fairly sure that you need to use: "sudo apt install libreadline-dev", to get readline into Debian Linux (and most likely, Ubuntu).

    dgately

    Its is indeed libreadline-dev.


    Thanks for finding my error. I HATE it when i post incorrect or incomplete info.
  • markmpxmarkmpx Posts: 28
    edited 2018-12-30 - 06:38:58
    loadp2 wouldn't work for me on linux, so I wrote a simple and ugly shell script that does it. It doesn't reset the P2 for you (yet); you have to reset it yourself. It hangs forever if you forget the P2 before running it; you have to manually interrupt it and try again when that happens. It doesn't use a checksum, and I haven't made any big programs yet; try lowering the baud if you have problems.

    Thanks Electrodude for your shell script. Works for me just great.

    (I should have thought of this myself, this is what i would have done 30 years ago,
    but sadly i am rusty after so many years of not using this stuff)
  • jmg wrote: »
    msrobots wrote: »
    Finally someone agrees, I am almost preaching about this. It is just two pins, a jumper, two holes. That can not be much on the BOM and I guess a Pick and Place can also place complete jumpers.

    A fitted jumper does impact the BOM, but a footprint is very close to true zero cost, so adding the footprint is something that should be on all boards.

    I've seen Eval Boards that use a nifty default solder bridge too.
    It is artwork like -(>>)- and there are 2 versions. One with paste, one without. The paste one (hopefully) defaults bridged.
    These bridges are easy to spot, and easy to change.

    After more work today, and solving the loading problems, i am forced to agree with you both.

    A pad or jumper to control DTR reset of the board would be extremely useful.

Sign In or Register to comment.