@Rsadeika said:
Well, since ersmith and dgately have their systems working with the WiFi, and I cannot get mine to work, I think that I may have a hardware problem. Now, how do I figure out which piece of hardware is causing the problem.
You said last time that it was running the program from flash instead of the one downloaded via serial. So that indicates pretty clearly that you need to disable booting from flash, at least while you're trying to experiment with downloading programs. Set your DIP switches to UP-UP-UP-DOWN to set the boot mode to "SERIAL ONLY" (as described in the chart on the back of the P2 Edge). Dennis and I are using UP-UP-DOWN-DOWN, which allows flash boot, but we don't have anything programmed in our flash (at least I don't, I'm guessing the same for Dennis).
Does WiFi upload work from a computer running (WIN, Linux, Mac), rather than RPi?
Does "Compile & Run on P2" work (USB-based, non-WiFi) from WIN/Linux/Mac or RPi?
Does the WiFi Module configuration look something like this:
Does flexprop's "Configure Commands" look like this:
Does the flexprop Ports menu show something like this:
And...
When you try to WiFi upload, have you removed the PropPlug? I find that I must remove it and power the P2 Edge Mini Breakout Board with a USB A to DC 2.1mm Jack Cable (Parallax part 805-00019).
The new propeller loader doesn't work on x64 Ubuntu Linux. It tells "loading", then "successful", but the P2 starts from what it previously had in flash.
Opening file '/home/pik33/Dokumenty/GitHub/P2-retromachine/Propeller/Tracker player/player2.binary'
Downloading file to port /dev/ttyUSB0
Download successful!
[ Entering terminal mode. Type Control-] or Control-Z to exit. ]
No, download was not successful. When I manually changed the command to use the old loader, it worked as expected, the program was loaded and run. The loading process was several times faster.
However I did something wrong in the command configuration and the flexprop hanged up after (successful) loading.
Downloading is not getting done in time to overcome to flash boot timeout. For now, you'll have to disable boot from flash with the appropriate dip switch settings.
I've created a new 5.9.7 beta package and uploaded it to my Patreon. Many of the annoying bugs reported above have been fixed. Thanks to you all for trying this out!
Unable to successfully download a program via WiFi to P2Edge. Using MacBook Pro with MacOS 12.2, FlexProp 5.9.7 beta, WiFi firmware 1.4. I get "Download Successful!" message and terminal starts up, but nothing further happens on P2. With serial connection, the same program outputs several lines of text, then waits for input.
@"Mike Green" said:
Unable to successfully download a program via WiFi to P2Edge. Using MacBook Pro with MacOS 12.2, FlexProp 5.9.7 beta, WiFi firmware 1.4. I get "Download Successful!" message and terminal starts up, but nothing further happens on P2. With serial connection, the same program outputs several lines of text, then waits for input.
If you've got something programmed into the flash you will have to disable flash boot to download a new program over WiFi. There's just too much latency to get to the P2 before the serial times out and boots from flash.
Could the WiFi Module program be changed to deal with this?
Perhaps changing the order from separate reset and transmit commands, to a "store first packet, then reset P2, wait slightly, then begin transmitting that stored packet to P2"?
Am I correct in thinking that the issue is more about the gap between reset and the first byte sent, as opposed to gaps between subsequent bytes once the first byte is sent?
It won't be as smart as Eric's update I'm sure, but maybe it can help pinpoint the issue. I'm happy to assist getting the firmware updated if something simple is identified that can help.
It may be that the ability to do a serial download with a program already in flash may depend on what exactly is programmed in the flash. As @dgately mentioned in the thread @VonSzarvas linked to:
"If you have a program already loaded onto the FLASH of the P2 board and that program uses pins that conflict with the WiFi Module pins, you'll have problems loading a program... Two programs that unfortunately were blinking pin 56 or attempting to quickly write to serial in a loop were previously loaded into the FLASH of my 2 P2Eval boards (ARG!). Removing those programs with a program that did not access any pins in the vicinity of 56-63 on the FLASH, fixed the loading via Wifi issue."
The proploader that comes with FlexProp is based on the one @VonSzarvas ported to support WiFi, so it should have the same capabilities as that one... I added serial support for P2, and changed some things about how the terminal interaction works, but the download code is basically the same. It works very reliably for me, but I don't have anything in the flash on my WiFi enabled board.
I have my own P2 load program to load over WiFi and it works even if there is a program already loaded to flash. Not sure what I am doing different than the default loader.
Just checked my program and I am using the rom base64 encoder loader with no stub program.
I tried to build the fresh version of flexprop using Ubuntu. The resulting program doesn't work, instead it displayed this:
Error in startup script: couldn't read file "debug_term.tcl": no such file or directory
while executing
"source debug_term.tcl"
(file "/home/pik33/flexprop/src/debugwin.tcl" line 32)
invoked from within
"source $ROOTDIR/src/debugwin.tcl"
(file "/home/pik33/flexprop/src/flexprop.tcl" line 27)
For my P2 Edge rev b WiFi setup, I am doing a sort of work around, which works for the time being.
What I do is, having the WiFi system unplugged and the propplug plugged in, I run compile and flash, on the program I want to use. Then I can unplug the the propplug and plug the WiFi system back in, and turn on the P2 Edge.
This is a little cumbersome but it works for using the WiFi. I tested this out by using the flexprop terminal window to access the P2 Edge. Tried this by using a telnet connection, but it seems like there is a baud rate discrepancy, not sure how to fix that. At least I can say that the WiFi system hardware works.
@pik33 said:
I tried to build the fresh version of flexprop using Ubuntu. The resulting program doesn't work, instead it displayed this:
Error in startup script: couldn't read file "debug_term.tcl": no such file or directory
while executing
"source debug_term.tcl"
(file "/home/pik33/flexprop/src/debugwin.tcl" line 32)
invoked from within
"source $ROOTDIR/src/debugwin.tcl"
(file "/home/pik33/flexprop/src/flexprop.tcl" line 27)
@pik33 said:
A question: how to - in Linux/5.9.7 and the new loader - make the propeller output window to automatically disappear after programming?
Do you want there to be no terminal window at all? Or do you want the terminal window to automatically close when the program in it exits?
It looks like there's a bug in the current terminal window that doesn't close it automatically. The fix is fairly simple, just apply the following patch to flexprop/src/tkterm.tcl:
With that change, you can remove the terminal window after download by leaving the "-t" off of the proploader command line. Or, you can have the terminal window close automatically when the Propeller program sends the exit sequence $FF, $00, $xx by adding a "-q" to the proploader command line.
Both options will be useful: I will try to apply the patch. What I need is the terminal window closing itself immediately after upload. Now the "workflow" is often like this: compile the program, upload the program, forget about the terminal window, change the program, try to upload - can't connect (as the old terminal is still active) - make a mistake and close the shell which started flexprop instead - flexprop is now closed
Is it possible to start the flexprop in Linux window manager without the shell window active?
@pik33 said:
Both options will be useful: I will try to apply the patch. What I need is the terminal window closing itself immediately after upload. Now the "workflow" is often like this: compile the program, upload the program, forget about the terminal window, change the program, try to upload - can't connect (as the old terminal is still active) - make a mistake and close the shell which started flexprop instead - flexprop is now closed
With the internal terminal this shouldn't be a problem -- the previous session is automatically closed before the new session is started. That's one of the advantages of the internal terminal, flexprop knows that the loader is still running and can stop it. So you can leave the terminal window open somewhere and just ignore it. But an option to have no terminal window at all might be nice as well.
Is it possible to start the flexprop in Linux window manager without the shell window active?
That probably depends on the window manager. With Mate on Debian I had to follow the instructions at https://forums.linuxmint.com/viewtopic.php?t=276003 to enable the desktop manager to run shared library applications.
The (default command settings) terminal doesn't close itself on reload. I have to close it manually or got "cannot connect"
The flexprop is Version 5.9.7-beta-HEAD-v5.9.6-74-ga3baf2f5
The bash -c method worked, but not 100% as expected: Flexprop started without underlying shell and allowed me to compile and upload. Then the main Flexprop window didn't respond at all until I closed the terminal window.After closing this window it started to respond again.
So I returned to the previous activator ("start in terminal"). Time to go home from the university and continue playing
Howdy, I was using flexgui and saw that you did the upgrade to flexprop.
First of all I wish I could code like you. Great stuff.
I launched flex prop and tried to use some code from flexgui. The error messages were as follows:
The fullduplesxserial2 is in the folder with the object I tried to run. I have had issues trying to get all my older code
running with all the changes. I have been out of the loop for over a year.
Thanks
Martin
The (default command settings) terminal doesn't close itself on reload. I have to close it manually or got "cannot connect"
Yes, the default is still to use the external terminal, which does need to be closed manually. To use an internal terminal you have to explicitly choose "Use Internal PST terminal" or "Use internal ANSI terminal".
The bash -c method worked, but not 100% as expected: Flexprop started without underlying shell and allowed me to compile and upload. Then the main Flexprop window didn't respond at all until I closed the terminal window.After closing this window it started to respond again.
Strange, I'm not seeing that in my environment. But definitely "start in terminal" is the better tested method and probably safer to use.
@pilot0315 said:
The fullduplesxserial2 is in the folder with the object I tried to run. I have had issues trying to get all my older code
running with all the changes. I have been out of the loop for over a year.
Without seeing the actual code I couldn't say for sure what the problem is. Since some of the errors are related to indentation it's possible that it's a problem with the tab settings. You could try changing the tab stop (under Options > Editor Options...). A tab stop of 8 is probably the best for compatibility, but some programs expect a tab stop of 4. Changing all tabs in the program to spaces is the safest option though!
Howdy, I was using flexgui and saw that you did the upgrade to flexprop.
First of all I wish I could code like you. Great stuff.
I launched flex prop and tried to use some code from flexgui. The error messages were as follows:
The fullduplesxserial2 is in the folder with the object I tried to run. I have had issues trying to get all my older code
running with all the changes. I have been out of the loop for over a year.
Thanks
Martin
Martin,
I too am back into the P2 after a couple of years out of the loop. Alot has changed. Now all pub declarations require () after them. Also, if you return anything from the object, you must add a variable for a return code.
flexgui spin2 code:
pub someobj
return 2
becomes this in flexprop/Proptool code:
pub someobj() : rtv
return 2
Where rtv is the return value. There are alot of bugaboos like that. I think it was done to allow overload methods with the objects as well as to accommodate inline PASM.
It takes some adjustment. I am having fun though!
Also @ersmith , thank you for all of your hard work!
The (default command settings) terminal doesn't close itself on reload. I have to close it manually or got "cannot connect"
Yes, the default is still to use the external terminal, which does need to be closed manually. To use an internal terminal you have to explicitly choose "Use Internal PST terminal" or "Use internal ANSI terminal".
The bash -c method worked, but not 100% as expected: Flexprop started without underlying shell and allowed me to compile and upload. Then the main Flexprop window didn't respond at all until I closed the terminal window.After closing this window it started to respond again.
Strange, I'm not seeing that in my environment. But definitely "start in terminal" is the better tested method and probably safer to use.
I managed to configure this:
I used bash -c in the activator. It still makes flexprop to not respond while the external terminal is open (on another computer and xubuntu installation, this time at home), but then, after changing the 'compile and run' command to
the terminal now disappears after loading the program and flexprop is then usable again.
This however broke "terminal only" menu command. Now it opens a terminal, resets a Propeller (why?) and immediately closes the terminal.
The internal terminal, if selected, opens, programs the P2, then doesn't close itself. Instead it minimizes its window so only a part of its decoration remains. This null window has to be manually closed before programming again.
Maybe I will configure 2 flexprop instances: "program" (this one) and "debug", without bash -c and with all options enabled in the loading command line, including Plan9 (this also prevents the terminal window from closing itself) and possibility of using BRK based debug which is not possible without a running terminal window. However my HDMI driver now uses the upper memory for its frame buffer (16 kB more place for an Amiga module) which disables this debug, and then the audio driver cannot be BRK debugged at all with its 3.5 MHz interrupts.
@pik33 said:
Maybe I will configure 2 flexprop instances: "program" (this one) and "debug", without bash -c and with all options enabled in the loading command line, including Plan9 (this also prevents the terminal window from closing itself) and possibility of using BRK based debug which is not possible without a running terminal window. However my HDMI driver now uses the upper memory for its frame buffer (16 kB more place for an Amiga module) which disables this debug, and then the audio driver cannot be BRK debugged at all with its 3.5 MHz interrupts.
You totally can debug code that has a timing constraint. You just need to slow it down.
Yes I know. I did it - I just needed to really slooooooooooooooooooooooow it dooooooooooooooooooown - a lot!!! I put 9000 instead of 90 as a DAC sample rate.
After the driver produced first heavily distorted sound, a simpler way to find bugs was wrlong the variable to hub, then, from another cog, display it at the screen.
@ke4pjw
@ersmith
Thanks for the info. Yea the () after say pub main() confused me at first. Making adjustments. I will try to play with the tab stop and see what happens.
The tab setting change appears to have fixed the problem in FlexProp.
I do have a question with the Proptool 2.6.2
I am trying to receive data asynchronous from a gps. I did it fine in Prop C on the P1. Trying in P2 Spin but I cannot get the rx to work with the jmfullduplexserial. Attempting to use simple serial in a second cog for receiving and pass the data as my next move. But for simplicity launching FDS twice with two different nick names should work. The rx in the jm version does not seem to work.
Any suggestions.
Thanks
Martin
Comments
You said last time that it was running the program from flash instead of the one downloaded via serial. So that indicates pretty clearly that you need to disable booting from flash, at least while you're trying to experiment with downloading programs. Set your DIP switches to UP-UP-UP-DOWN to set the boot mode to "SERIAL ONLY" (as described in the chart on the back of the P2 Edge). Dennis and I are using UP-UP-DOWN-DOWN, which allows flash boot, but we don't have anything programmed in our flash (at least I don't, I'm guessing the same for Dennis).
I agree... You need to be able to single-out the "problem" component or configuration.
Things that might help:
What are the versions of flexprop, WiFi Module firmware, Raspberry Pi (3, 4?), etc...
What I'm using:
Some questions to ask (determine what does work):
Does flexprop's "Configure Commands" look like this:
Does the flexprop Ports menu show something like this:
And...
When you try to WiFi upload, have you removed the PropPlug? I find that I must remove it and power the P2 Edge Mini Breakout Board with a USB A to DC 2.1mm Jack Cable (Parallax part 805-00019).
The new propeller loader doesn't work on x64 Ubuntu Linux. It tells "loading", then "successful", but the P2 starts from what it previously had in flash.
No, download was not successful. When I manually changed the command to use the old loader, it worked as expected, the program was loaded and run. The loading process was several times faster.
However I did something wrong in the command configuration and the flexprop hanged up after (successful) loading.
Downloading is not getting done in time to overcome to flash boot timeout. For now, you'll have to disable boot from flash with the appropriate dip switch settings.
It seems the best solution for now is to try and combine 5.9.6 IDE/loader with 5.9.7 compiler
I've created a new 5.9.7 beta package and uploaded it to my Patreon. Many of the annoying bugs reported above have been fixed. Thanks to you all for trying this out!
Today's build can upload to P2 using VM based Ubuntu (I have no real instalation of it at home) - not 100% sure, but only one try of several failed.
Unable to successfully download a program via WiFi to P2Edge. Using MacBook Pro with MacOS 12.2, FlexProp 5.9.7 beta, WiFi firmware 1.4. I get "Download Successful!" message and terminal starts up, but nothing further happens on P2. With serial connection, the same program outputs several lines of text, then waits for input.
If you've got something programmed into the flash you will have to disable flash boot to download a new program over WiFi. There's just too much latency to get to the P2 before the serial times out and boots from flash.
Could the WiFi Module program be changed to deal with this?
Perhaps changing the order from separate reset and transmit commands, to a "store first packet, then reset P2, wait slightly, then begin transmitting that stored packet to P2"?
Am I correct in thinking that the issue is more about the gap between reset and the first byte sent, as opposed to gaps between subsequent bytes once the first byte is sent?
Is the issue with programming to Flash, or just running programs over WiFi ?
This version of proploader does allow download to ram and run over WiFi with the flash dip switched on (post #20): https://forums.parallax.com/discussion/comment/1518643/#Comment_1518643
Dgately provided a MacOS compiled version in one of the posts too!
It won't be as smart as Eric's update I'm sure, but maybe it can help pinpoint the issue. I'm happy to assist getting the firmware updated if something simple is identified that can help.
It may be that the ability to do a serial download with a program already in flash may depend on what exactly is programmed in the flash. As @dgately mentioned in the thread @VonSzarvas linked to:
"If you have a program already loaded onto the FLASH of the P2 board and that program uses pins that conflict with the WiFi Module pins, you'll have problems loading a program... Two programs that unfortunately were blinking pin 56 or attempting to quickly write to serial in a loop were previously loaded into the FLASH of my 2 P2Eval boards (ARG!). Removing those programs with a program that did not access any pins in the vicinity of 56-63 on the FLASH, fixed the loading via Wifi issue."
The proploader that comes with FlexProp is based on the one @VonSzarvas ported to support WiFi, so it should have the same capabilities as that one... I added serial support for P2, and changed some things about how the terminal interaction works, but the download code is basically the same. It works very reliably for me, but I don't have anything in the flash on my WiFi enabled board.
I have my own P2 load program to load over WiFi and it works even if there is a program already loaded to flash. Not sure what I am doing different than the default loader.
Just checked my program and I am using the rom base64 encoder loader with no stub program.
Mike
I tried to build the fresh version of flexprop using Ubuntu. The resulting program doesn't work, instead it displayed this:
For my P2 Edge rev b WiFi setup, I am doing a sort of work around, which works for the time being.
What I do is, having the WiFi system unplugged and the propplug plugged in, I run compile and flash, on the program I want to use. Then I can unplug the the propplug and plug the WiFi system back in, and turn on the P2 Edge.
This is a little cumbersome but it works for using the WiFi. I tested this out by using the flexprop terminal window to access the P2 Edge. Tried this by using a telnet connection, but it seems like there is a baud rate discrepancy, not sure how to fix that. At least I can say that the WiFi system hardware works.
Ray
A new commit repaired this, now it works
A question: how to - in Linux/5.9.7 and the new loader - make the propeller output window to automatically disappear after programming?
Do you want there to be no terminal window at all? Or do you want the terminal window to automatically close when the program in it exits?
It looks like there's a bug in the current terminal window that doesn't close it automatically. The fix is fairly simple, just apply the following patch to flexprop/src/tkterm.tcl:
--- a/src/tkterm.tcl +++ b/src/tkterm.tcl @@ -781,7 +781,8 @@ proc Terminal_Data { } { set c [read $term_pipe 1024] if { "$c" eq "" } { if { [eof $term_pipe] } { - fileevent $term_pipe readable { } + #puts "EOF on terminal data" + close_term } } else { term_recv $cWith that change, you can remove the terminal window after download by leaving the "-t" off of the proploader command line. Or, you can have the terminal window close automatically when the Propeller program sends the exit sequence $FF, $00, $xx by adding a "-q" to the proploader command line.
Both options will be useful: I will try to apply the patch. What I need is the terminal window closing itself immediately after upload. Now the "workflow" is often like this: compile the program, upload the program, forget about the terminal window, change the program, try to upload - can't connect (as the old terminal is still active) - make a mistake and close the shell which started flexprop instead - flexprop is now closed
Is it possible to start the flexprop in Linux window manager without the shell window active?
With the internal terminal this shouldn't be a problem -- the previous session is automatically closed before the new session is started. That's one of the advantages of the internal terminal, flexprop knows that the loader is still running and can stop it. So you can leave the terminal window open somewhere and just ignore it. But an option to have no terminal window at all might be nice as well.
That probably depends on the window manager. With Mate on Debian I had to follow the instructions at https://forums.linuxmint.com/viewtopic.php?t=276003 to enable the desktop manager to run shared library applications.
This is XFCE.
The (default command settings) terminal doesn't close itself on reload. I have to close it manually or got "cannot connect"
The flexprop is Version 5.9.7-beta-HEAD-v5.9.6-74-ga3baf2f5
The bash -c method worked, but not 100% as expected: Flexprop started without underlying shell and allowed me to compile and upload. Then the main Flexprop window didn't respond at all until I closed the terminal window.After closing this window it started to respond again.
So I returned to the previous activator ("start in terminal"). Time to go home from the university and continue playing
@ersmith
Howdy, I was using flexgui and saw that you did the upgrade to flexprop.
First of all I wish I could code like you. Great stuff.
I launched flex prop and tried to use some code from flexgui. The error messages were as follows:
The fullduplesxserial2 is in the folder with the object I tried to run. I have had issues trying to get all my older code
running with all the changes. I have been out of the loop for over a year.
Thanks
Martin
Yes, the default is still to use the external terminal, which does need to be closed manually. To use an internal terminal you have to explicitly choose "Use Internal PST terminal" or "Use internal ANSI terminal".
Strange, I'm not seeing that in my environment. But definitely "start in terminal" is the better tested method and probably safer to use.
Without seeing the actual code I couldn't say for sure what the problem is. Since some of the errors are related to indentation it's possible that it's a problem with the tab settings. You could try changing the tab stop (under Options > Editor Options...). A tab stop of 8 is probably the best for compatibility, but some programs expect a tab stop of 4. Changing all tabs in the program to spaces is the safest option though!
Martin,
I too am back into the P2 after a couple of years out of the loop. Alot has changed. Now all pub declarations require () after them. Also, if you return anything from the object, you must add a variable for a return code.
flexgui spin2 code:
pub someobj return 2becomes this in flexprop/Proptool code:
pub someobj() : rtv return 2Where rtv is the return value. There are alot of bugaboos like that. I think it was done to allow overload methods with the objects as well as to accommodate inline PASM.
It takes some adjustment. I am having fun though!
Also @ersmith , thank you for all of your hard work!
--Terry
I managed to configure this:
%#"%D/bin/proploader" -2 %P -D baud-rate=%r -D loader-baud-rate=%r "%B" -rthe terminal now disappears after loading the program and flexprop is then usable again.
This however broke "terminal only" menu command. Now it opens a terminal, resets a Propeller (why?) and immediately closes the terminal.
The internal terminal, if selected, opens, programs the P2, then doesn't close itself. Instead it minimizes its window so only a part of its decoration remains. This null window has to be manually closed before programming again.
Maybe I will configure 2 flexprop instances: "program" (this one) and "debug", without bash -c and with all options enabled in the loading command line, including Plan9 (this also prevents the terminal window from closing itself) and possibility of using BRK based debug which is not possible without a running terminal window. However my HDMI driver now uses the upper memory for its frame buffer (16 kB more place for an Amiga module) which disables this debug, and then the audio driver cannot be BRK debugged at all with its 3.5 MHz interrupts.
You totally can debug code that has a timing constraint. You just need to slow it down.
Yes I know. I did it - I just needed to really slooooooooooooooooooooooow it dooooooooooooooooooown - a lot!!! I put 9000 instead of 90 as a DAC sample rate.
sound, a simpler way to find bugs was wrlong the variable to hub, then, from another cog, display it at the screen.
After the driver produced first heavily distorted
@ke4pjw
@ersmith
Thanks for the info. Yea the () after say pub main() confused me at first. Making adjustments. I will try to play with the tab stop and see what happens.
@ersmith
The tab setting change appears to have fixed the problem in FlexProp.
I do have a question with the Proptool 2.6.2
I am trying to receive data asynchronous from a gps. I did it fine in Prop C on the P1. Trying in P2 Spin but I cannot get the rx to work with the jmfullduplexserial. Attempting to use simple serial in a second cog for receiving and pass the data as my next move. But for simplicity launching FDS twice with two different nick names should work. The rx in the jm version does not seem to work.
Any suggestions.
Thanks
Martin