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.
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.
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.
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.
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]
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...
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.
@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
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.
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.
@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
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.
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.
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)
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.
Comments
At some point, initializing x to 15 may cause some issues.
Fast spin does not show a gui it just flashes and disappears.
Can you cut & paste the program in a Code block so we can try it?
Thanks
Tom
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?
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 a loadp2.exe of the latest version that you could post or link to?
Thanks,
Tom
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.
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.
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 also find it easier to use p2asm and loadp2 along with the m4 preprocessor.
Here is the code it is from parallax and the error in spin2 gui
dgately
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 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 to
When it ran those 4 lights lit but did not appear to blink.
Looking at all of "blink" I saw that the maximum time delay between blinks was 15 << 16 which equals approx 49ms at RCFAST (20 MHz).
I changed to 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
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 will try that.
Thanks
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
dgately
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.
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
Its is indeed libreadline-dev.
Thanks for finding my error. I HATE it when i post incorrect or incomplete info.
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)
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.