Prop tool question? Solved Timing issue waiting for PST to launch
pilot0315
Posts: 913
I get this:
send the code again and get this:
This is JM code that I am stripping out to relearn the changes.
try the code again and get the gibberish then run the code again and get the text. It goes back and forth with each. One is correct the other is gibberish. Baud rate is not changed.
I have been away for over a year. Y'all changed a lot of stuff. I am confused.
What is happening?
Thanks
Comments
The screen with gibberish is likely caused by sending an address to the wrong section of memory rather than the text string you wanted to display.
If you post an archive of your project, we can take a look at it. The code you posted only contained constants. There wasn't any code.
Here we go again....
You break break my code, complain and imply that it's my fault, and then won't post your broken code. What you posted is not a complete program -- it's a list of constants.
The program works. I've attached screen-shots from Propeller Tool (2.7.0) and from FlexProp (5.9.9 -- set to use internal PST terminal), along with the code from my machine to prove it.
When I do presentations for Parallax I always end with this slide.
I only used a small portion of the code that you wrote.
Trying to get used to the new format.
All I wanted to do was print a string. I do not know what happens when I get the gibberish and then rerun the code and get the correct print then run again and get gibberish.
That is my question.
JM I am not blaming anybody. Do not take it personally.
con { timing } CLK_FREQ = 200_000_000 ' system freq as a constant MS_001 = CLK_FREQ / 1_000 ' ticks in 1ms US_001 = CLK_FREQ / 1_000_000 ' ticks in 1us BR_TERM = 115_200 ' terminal baud rate _clkfreq = CLK_FREQ con { fixed io pins } RX1 = 63 { I } ' programming / debug TX1 = 62 { O } obj ' main ' * master Spin cog term : "jm_fullduplexserial" ' * serial IO for terminal pub main() setup() ' term.start(RX1, TX1, %0000, 115_200) repeat ' term.fstr1(string("%033c\r\r"), "-") ' term.str(string("test")) term.fstr0(string("Please enter your name: ")) pub setup() term.start(RX1, TX1, %0000, BR_TERM)This is what I posted if it did not show up not my fault.
ModEdit: Code tags added
It may be more to do with printing text so quickly after term.start... Try this which waits a half-second before printing to the Terminal. Or you can add code to wait for input from the Terminal before printing anything. Note, I changed the baud rate to 230_400 since flexprop (the IDE I use) sets a default to that baud.
con { timing } CLK_FREQ = 200_000_000 ' system freq as a constant MS_001 = CLK_FREQ / 1_000 ' ticks in 1ms US_001 = CLK_FREQ / 1_000_000 ' ticks in 1us BR_TERM = 230_400 ' terminal baud rate _clkfreq = CLK_FREQ con { fixed io pins } RX1 = 63 { I } ' programming / debug TX1 = 62 { O } obj ' main ' * master Spin cog term : "jm_fullduplexserial" ' * serial IO for terminal pub main() setup() waitms(500) ' wait .5 second, allowing terminal to start up repeat ' term.fstr1(string("%033c\r\r"), "-") ' term.str(string("test")) term.fstr0(string("Please enter your name: ")) ' This will print forever! pub setup() term.start(RX1, TX1, %0000, BR_TERM)Stop mentioning me by name when you have problems. I have demonstrated more than once with you that my code works, yet you continue to imply that my code is an issue. To paraphrase Will Smith: Please keep my name out of your posts.
You're doing that. Over and over and over again -- because you put the print statement in a repeat loop.
Because you didn't read the file and set PST to the correct baud rate. As Dennis pointed out, FlexProp defaults to 230400, so that's what I use for my P2 projects to make things easier for everyone during my presentations (and the P2 smart pins have no trouble with high baud rates -- the P1 has a speed limit for full duplex).
Nothing seems to be....
Duane and I both downloaded your "problem" file and it was nothing but constants.
I know that I am using a repeat loop. It is the gibberish that I am concerned about.
I copied the code and pasted it.
Are you still getting gibberish?
If you attach an archive of your project, we can make sure we are using the same child object as you.
After you've compiled the program (use F9 to compile), you can save an archive by selecting File\Archive "Project Name"\Project... . This will produce a .zip file which you can then attach to your forum post.
If your code presently just repeatedly prints "Please enter your name: " then there's little point in posting an archive this time and and you can keep the archive option ready when you have another question.
The gibberish could just be a fluke. I occasionally need to restart Parallax Serial Terminal.exe (PST) when I'm working on a project. It's possible the gibberish had nothing to do with the Propeller and was just a PC glitch.
I won't worry too much about the gibberish if you're presently getting the expected output.
Jumpin' Jiminy on a cracker -- this has been covered at least 3 times: the baud rate of PST must match the baud rate that the serial object has been set for. I copied and pasted your test code into my editor and ran it. When I opened PST I got "gibberish" because the my PST baud rate was set to 230400. When I changed it to match the code (115200), the strings appeared normally. I didn't even have to restart the program.
On my reminders list is "Start with a Template" -- this is far better than ripping apart another program to play with. I've attached my P2 template. Save this in your Propeller Tool folder and then set this to be you template for new P2 programs (in the Preferences [F5], Files & Folders tab). This will make starting new projects much easier than what you're doing now. Since I like to test by running from RAM, there's a bit of code that holds the program until PST is open and ready. Again... study the code before running the code.
Baud rate 230400 does the same thing.
You may have a bad Prop-Plug or cable.
Ran it on two different p2eval boards, and two different edge boards different prop plugs resulting in the same issue. Ran other test routine with flexprop no issues on any of those boards repeat loop is good and printing. p2 eval board same issue. So changing boards x 2, changing cables x 2 changing prop plugs x2 no change in the results.
Also uninstalled 2.6.3 cleaned all registries installed 2.6.7 the beta and no changes. Wow then using the beta I had com port issues not seen before. Then the pst would not shut down had to use task manager to kill it. I am going back to 2.4.1 to see what happens.
Continues to flip flop with good repeat loop and gibberish that either freezes or flickers. Baud rates 115200 or the 230400 is the same stuff.
If this was a Propeller Tool error, all of us would be having problems, not just you. FlexProp and Propeller Tool use different loaders, so you could try manipulating your download baud rate of Propeller Tool -- maybe there's something funky about you USB port. You could experiment by adding this to the timing section of your program.
Original worked as advertised on @Cluso99 Retroblade2 using prop plug and 2.7.0 tool. Has the OP run the original code to verify proper functioning of the current harware prior to attempted software modifications?
Btw using the example code in the demos works fine.
Looks like your PC is not fast enough to receive so many characters without any pause, and the input buffer gets overloaded. Strange things, like freezed applications, can happen then.
So as suggested before insert a little delay after every line you send:
repeat term.fstr0(string("Please enter your name: ")) waitms(250)Andy
Never had this problem until recently. Ran P2 with out issue. Only had this with the latest Prop tool.
The suggestion to change "DOWNLOAD_BAUD = 115_200" is this a prop tool setting if so how do I change it?
No issues with flexprop.
If something worked with the existing hardware/software and then did not after it was touched/modified/etc, then go back to the original settings/code/whatever. Touch only one thing at a time and test to see if it has been broken. Iterate until it works as intended or breaks. Use diff or Tkdiff or similar between the original example and the iteration where it broke to see what broke and then understand why it broke. On occasion doing a Preventive Maintenance on a complex device may cause another issue where the resolution is to look for what was touched and restore from there. Same may help the OP here. I run an older box with a gen 6 i7 comms through putty and have run up to the 921600 rate with the Retroblade2 under TAQOZ reloaded.
New issue.
PST will not close. Only way to close is Task Manager. Anyone have this issue?
BTW I started getting weird stuff after this:
I sent it to IT and he could not find it.
Any Ideas?
pilot0315,
It may be a false positive.
https://www.eset.com/us/home/online-scanner/
https://www.malwarebytes.com/solutions/rootkit-scanner
https://www.malwarebytes.com/solutions/trojan-scanner
https://www.malwarebytes.com/solutions/virus-scanner
https://www.malwarebytes.com/solutions/spyware-scanner
https://support.norton.com/sp/static/external/tools/overview.html?inid=hho_supp_quick_help
https://www.emsisoft.com/en/tools/emergencykit/
https://helpcenter.trendmicro.com/en-us/article/TMKA-18728
https://www.bitdefender.com/toolbox/freeapps/desktop/
Vipre Rescue
https://www.vipreantivirus.com/support.aspx/.aspx
If it's real, it's good enough to evade norton. Not detected with norton on win 10 proptool 2.7.0 beta.
Hey to all.
First thanks for all of the help and suggestions.
I like to write my code simply in the beginning and then separate out into different methods. So since I am getting used to the new spin syntax since I have not coded for over a year, decided to start simple. Thanks to JM for the template. I used one of his demos to start with.
The "malware" issue, I checked with some of the suggestions from Genetix. Found nothing. Thanks.
Second the issue with the PST I found to be a timing issue.
I gestimated the timing for JM code in the example I used:
pub wait_for_terminal(clear)
term.rxflush()
term.rx() ' wait for keypress
if (clear)
term.tx(term.CLS)
Experimented with waitms
I had started like this:
pub main ()
' waitms(100)
term.start(RX1, TX1, %0000, BR_TERM)
_first did not have wait ms the used the wait for terminal routine. figured out that the timing was off. The waitms(1000) did the same wait time for the PST to launch and that was the issue
So that fixed the problem.
waitms(1000) ' wait_for_terminal(true) repeat term.fstr0(string("Please enter your name: "))So that fixed the issue. Thanks for all of the suggestions.
Martin
The purpose of wait_for_terminal() in many of my test/demo programs is to let me open PST and get it ready before I let the main part of the program run (after setup) -- no need to race a waitms() call. The reason I put a small delay after is to let me see that PST is cleared if I didn't do that manually. With code this I can test in RAM and have a quick code update / retest cycle. Once the code is done and I don't need output to PST anymore, I comment out wait_for_terminal() and its trailing delay (if there)
Now... there are times when I don't want to press a key to get into the program, but I still want nice output to PST for debugging. In that case I run a background cog for debugging as this lets me display any global value on the fly. To fix the start-up issue, I allow that cog to look for any key input. If the user presses a key, PST will be cleared and the report string (that are in a DAT section) will be reprinted.
This is from a commercial project. It's simple, but effective.
pri bkg() | k debug_window() repeat repeat until (debugsync) debugsync := false k := term.rxcheck() if (k <> -1) debug_window() term.rxflush() show_command_values() pri debug_window() term.tx(term.CLS) term.str(@Report) goto_xy(0, 2) term.str(string("Version: ")) term.str(@Version)For those wondering, the main loop of this program runs at 30Hz. When everything is updated, the main loop sets debugsync to true which then allows the background debug display to show the latest values. It's easy, and it ensures that all the values on screen belong together.
There was never anything wrong with the programs the OP tested -- it was simply a matter of jumping the gun and modifying programs without fully understanding how they worked. This gets us all -- which is why I have that "Study the code before running the code" suggestion on my list. For my next presentation I'm going to add, "Understand the code before modifying the code."
Maybe also how much time it takes for the PST to launch fully. I did not have this problem with the P1. It would leave it not to be discovered. Some of us are still learning especially, with the new changes.
Not all of us are in the know. For the very new who are really starting, not catching up like me. There are so many changes that are coming, it may be hard for the first timers.
Also a suggestion for you. In your presentations, keep in mind all teaching should be explained in simple fashions so as to catch those who are familiar and those who are not. I am a retired aircraft mechanic instructor. Complex subjects need to be laid out so a varied audience can get it. Some are faster some are slower. One can forget this and loose a lot of people in the fever of trying to teach. Very Very important. I as it is seen figured it out eventually but it would have helped if I was aware of the time delay if I had had more information.
Another way to consider that is by thinking about the speed you are running your P1 code vs your P2 code.
Maybe 80Mhz vs 180Mhz (or more?)
P2 going so much faster could get a lot more done before PST on your computer is ready. The little delay or wait-for-keypress would allow your computer time to "catch up".
That cannot be defined with precision because it will depend on the computer in use. Again, the PST start-up delay is completely countered through the use of wait_for_terminal() -- it's in the name. Development is different than running a finished application; I set this up for development. I remove it when development is done.
I disagree. You stumbled into a solution for your situation that may not have worked for another computer. Sorry to sound like a broken record, but that is why the wait_for_termina() method exists. It lets the operator decide when to launch the code during the development cycle (PST is easy to launch via F12, but sometimes I want to use PuTTy which takes longer to get started). When development is done, the wait_for_terminal() line can be commented out and the program will run directly into a terminal (that is already running). I recently created a tool to capture and print the messages between a piece of PC software and a connected XBee module. Now that the program is finished I run it from flash (program with F11 into the P2) and there is no need for me to press a key to let the program run.
Online presentations are not ideal for brand new people, though I do try to ask at every step if there are questions because I don't want anyone left behind.
The syntax differences between the Spin1 and Spin2 are minor, and Parallax has a bunch of written information about Spin1 (that you already have experience with). I have converted hundreds of Spin1 files to Spin2. These are the things I keep in mind when doing that (note it's a short list):
Honestly, I start with Step 1 and then press F9. The compiler will tell me where a problem is and I can fix it. After compiler-detected errors are sorted I go line by line to look for hidden gotchas (like changing => and =< to >= and <=). If you're only concern is running a program to learn from, do the original author the courtesy of running the program without modification. Once you understand what's happen, then it might be time to experiment (without blaming the original author by invoking their name for code they didn't modify).
As Andy pointed out, doing this is NOT a good idea:
repeat term.str(string("This is a test string", 13))...because PST (and other terminals) have a finite buffer size, and with no delay between strings, the terminal may not be able to empty its incoming buffer in time for the next new string from the P2. This can cause the program to enter an unknown state. In hacking this buffer overflow is a trick used to break into a program. That said, in P2 code development this is not desirable. If you're just printing strings in a loop, always add a delay. When I want something to print as quickly as possible, I estimate the time it would take to transmit the string and use that (minimum of 5ms). This seems to give PST enough breathing room to operate without problems.
Note on the attached list: I created this for myself; it may not be complete as of the current state of the Spin2 compiler and it has not been validated by Parallax or anyone else. Use at your own risk.
@VonSzarvas
Thank you for that. The catching up has been frustrating. I/O speeds between the P2, P1 and the computer (including monitors, keyboards etc. are different.
The P2 is dramatically faster than the P1. In the early days I did a simple test with Spin code that would run on both platforms. I ran both a 80MHz and measured speed using an IO pin and a 'scope. The P2 -- in that simple test -- was 16 times faster running the same code at the same speed. This comes down to the P2 memory architecture being able to move data faster, having 2 clock cycles per instruction (versus 4 in the P1), and the improved PASM2 instruction set. PASM instructions went from about 70 in the P1 to over 350 in the P2. Many P2 instructions will do the work of multiple P1 instructions. I have found that most (not all) of my P1-P2 PASM migrations result is fewer instructions, and many aspects of P2 PASM programming are simplified. This speaks to a programmer creating the chip and taking suggestions from other programmers.
I just sent a note to Ken Gracey asking if we should have a P1 to P2 migration presentation.