Parallax Serial Terminal jitter and garbage on start up, then can clear it. Cau

Harprit · 2010-07-21 08:15

What causes the PST to jitter under some circumstances?
What causes extra lines to appear on start up, and can then be cleared, and will not reappear.

I have been starting the PST and then displaying once and then clearing the screen at the end
of the first full cycle, once, to fix this, but this should not be necessary.
A short wait command is needed at the end of the refresh, what should this time length be?
The jitter is quite sensitive to this delay. (This delay/wait too should not be necessary.)

As suggested the PST is running in its own cog at full speed. The situation is not sensitive to the
amount of data displayed. The scheme clears the screen on startup and then uses home for subsequent
refreshes. Once the window is cleared manually it never screw up again.

I do not believe listing the program is relevant but will course of post it if requested.

Harprit.

JonnyMac · 2010-07-21 12:20

Start-up of what? The cog or the terminal program? I tend to hang a pull-up on TX lines so that an uninitialized IO pin is kept in the idle state and, if initialized properly, will not cause garbage on the terminal when the firmware starts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Harprit · 2010-07-21 14:09

I start the program I wrote, it runs fine, it call PST in its own Cog. 115200 is set in the constants.
In my program the TX and RX lines are pulled dn and up as specified before I do anything else.
I click on the PST icon on the desktop, PST come on, garbage present with my data
I click on the clear button in PST
Everything clears up and stays OK from there on as I move back and forth between program and PST

Harprit.

Bean · 2010-07-21 14:13

You need to keep the pin in a HIGH state when not sending data (or before you send data).

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
NEW PropBasic Blog: http://propbasic.blogspot.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Harprit · 2010-07-21 16:06

I will go over the code
Do appropriate checking
Report back to the Forum
Many thanks to Jon and Bean

Harprit

Harprit · 2010-07-21 19:42

Following the competent advice above, here is what I did
Up front, before anything else I specified

dira[noparse][[/noparse]30]~ 'receive
dira[noparse][[/noparse]31]~~ 'xmit
outa[noparse][[/noparse]31]~~ 'set high and left high
pst.StartRxTx(31,30,0,Baud)

This seems to fix it, if the problems comes back I will report back.

CLOSED

Harprit.

kuroneko · 2010-07-22 00:30

Harprit said...

dira[noparse][[/noparse]30]~        'receive
dira[noparse][[/noparse]31]~~       'xmit
outa[noparse][[/noparse]31]~~      'set high and left high                                        
  pst.StartRxTx(31,30,0,Baud)

Why do you bother setting I/O in the main cog anyway? The StartRxTx method does all the required setup for you (in a different cog). Also, I'm a bit concerned that you drive the receiver pin (31) with high effectively against the external chip (the PST object receives on 31 and transmits on 30). So unless the main cog releases it's output assignment later on I can't see this working.

Harprit · 2010-07-22 02:06

It works all right but....
Let me check it out
and report back.

Harprit

Harprit · 2010-07-22 14:49

First. There are still problems with the proposed fix as was implemented.

Second. Taking out the 3 lines suggested by Kuroneko does not fix things, there are still problems.

The problem can be made visible by enabling and disabling the PST repeatedly at a random rate
It does not manifest itself on every state change caused by the key presses. It is random.

Harprit

Post Edited (Harprit) : 7/22/2010 2:55:04 PM GMT

jazzed · 2010-07-22 17:39

I'm trying to be helpful here, but am not suggesting a solution since I've never seen the problem.

If you're interested in keeping the TX pin (Propeller to PC) in a high state when the Propeller's serial COG driver is not active, you should be asserting P30 and not 31. Asserting P31 causes a fight with the device sending data to the Propeller.

Cheers.
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Harprit · 2010-07-22 18:41

@Steve:

I may not completely understand asserting terminology but... (If I don't, tell me what to do in plainer language!)
If I make Pin 30 output and then make it high... (in the main cog at start up.)
Nothing works. It disables to PST completely, you cannot see anything on it.

If I make 31 an output and make it high, things work but I get occasional garbage
I leave the other pin untouched in either case.

Harprit.

Harprit · 2010-07-22 18:50

Here is the program listing
You can run it without the external hardware
Toggle enable and disable on the PST screen

Harprit

jazzed · 2010-07-22 19:10

Harprit said...
@Steve:

I may not completely understand asserting terminology but... (If I don't, tell me what to do in plainer language!)
If I make Pin 30 output and then make it high... (in the main cog at start up.)
Nothing works. It disables to PST completely, you cannot see anything on it.

If I make 31 an output and make it high, things work but I get occasional garbage
I leave the other pin untouched in either case.

Harprit.

Sorry, I forgot to mention (and assumed it was understood) that P30 should be set to input after cognew.

Cheers.
--Steve

Edit: To further clarify. The same cog that you are using to set P30 to output before cognew should set P30 in input after cognew.
The new cog will control P30 as the output. I looked at your code and only one cog is og using the serial cwhich is good.
If the P30 pin has a weak pull up, none of this is necessary, If something else is driving P30, that would be a problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Post Edited (jazzed) : 7/22/2010 11:00:34 PM GMT

p00ndawg · 2010-07-22 19:15

Make sure you arent calling the terminal in any other parts of your code other than the main file. that usually makes it act up for me.

soshimo · 2010-07-22 23:50

You don't have to launch your sub cog_PST into a new cog. The call to StartRxTx does that for you. Also, if you don't plan on changing pins you can use the helper function Start on the PST object. It takes a baud rate and calls the correct functions for you. So, just call PST.Start on the main cog and you should be good to go. I run PST in every project I make (at least during debugging and testing) and I have never ran into this problem. I get garbage characters sometimes when I turn off the prop while the terminal is still connected but that could be because I don't have pull ups. I assumed the FTDI board would provide that functionality for me (and why shouldn't it, right?). The point is that if you are getting garbage characters on start it's usually because you have the wrong baud setting (in which case everything will be garbage) or you have contention on the pins. I'm putting my money on the latter.

Harprit · 2010-07-23 13:57

Here is my final take on the problem as I see it.

The suggestions made are all relevant and improve performance. Thanks guys.

The problem is that when you switch back and forth between PST and the program
you are asking the system to start typing to the PST in the middle of an output stream
and that causes problems. There is no way to guarantee that the transfer begins with
a clear screen or home instruction so the message gets garbled. If you use clear screen
at the start of each refresh all is good but the screen flashes off and on every cycle.
Starting at 1,1 gives you a steady screen but it does not reset itself if you come in
in the middle of a transmission. Clear does the job.

Now I have a much better understanding of what is going on.

The PST works fine. It needs to be in its own cog to get a really fast refresh on the display.

Harprit

Harprit · 2010-07-23 14:22

The delay at the end of the routine reduces the "clear screen" flashing
It needs to be at least 1/60 seconds long. Then everything works fine.

Thanks to all helpers.

Harprit.

jazzed · 2010-07-23 14:30

Harprit said...
The delay at the end of the routine reduces the "clear screen" flashing
It needs to be at least 1/60 seconds long. Then everything works fine.

Thanks to all helpers.

Harprit.

So you had 2 cogs driving the serial port simultaneously?
I presume you can remove the tx pin hacks now.

Considering the queuing mechanism in the serial port driver, some delay would be required.
Glad you have something working.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

soshimo · 2010-07-23 16:33

Harprit said...
Here is my final take on the problem as I see it.

The PST works fine. It needs to be in its own cog to get a really fast refresh on the display.

Harprit

Yes, but does it belong in two cogs? That is effectively what you are doing. You are launching a cog to launch PST in another cog. Not every efficient, but if it works, what the heck right?

Code straight out of the PST object:

PUB Start(baudrate) : okay
{{Start communication with the Parallax Serial Terminal using the Propeller's programming connection.
Waits 1 second for connection, then clears screen.
  Parameters:
    baudrate - bits per second.  Make sure it matches the Parallax Serial Terminal's
               Baud Rate field.
  Returns    : True (non-zero) if cog started, or False (0) if no cog is available.}}

  okay := StartRxTx(31, 30, 0, baudrate)
  waitcnt(clkfreq + cnt)                                'Wait 1 second for PST
  Clear                                                 'Clear display

And here is StartRxTx, you can see it launches the serial code in a cog:

PUB StartRxTx(rxpin, txpin, mode, baudrate) : okay
{{Start serial communication with designated pins, mode, and baud.
  Parameters:
    rxpin    - input pin; receives signals from external device's TX pin.
    txpin    - output pin; sends signals to  external device's RX pin.
    mode     - signaling mode (4-bit pattern).
               bit 0 - inverts rx.
               bit 1 - inverts tx.
               bit 2 - open drain/source tx.
               bit 3 - ignore tx echo on rx.
    baudrate - bits per second.
  Returns    : True (non-zero) if cog started, or False (0) if no cog is available.}}

  stop
  longfill(@rx_head, 0, 4)
  longmove(@rx_pin, @rxpin, 3)
  bit_ticks := clkfreq / baudrate
  buffer_ptr := @rx_buffer
  okay := cog := cognew(@entry, @rx_head) + 1

The key line is this okay := cog := cognew(@entry, @rx_head) + 1. Look familiar?

Pretty much what you do already, only you launch an entire cog to do just that. Just call PST.Start(BAUD_RATE) and you are fine. You don't need the loading code in another cog. Oh, and the object doesn't "live" in a cog, code does. You can have an object that launches code in 8 cogs or just run in one cog - it doesn't matter. Objects are cog agnostic and are really just containers for code and data.

Post Edited (soshimo) : 7/23/2010 4:43:07 PM GMT

Parallax Serial Terminal jitter and garbage on start up, then can clear it. Cau

Comments