PropellerTool serial console: invalid ASCII characters, instability in general

rikki

I recently began working with the Propeller products.
With the help of some great folks here on the Forum I got PropellerIDE up and running (in Ubuntu Linux).
I created some simple test programs and successfully downloaded them to both a Spinerette and a Mini.

My serial terminal though is still a bit unstable. It will receive the print statements from my program, but there is a problem which results in the data from my Propeller being interspersed with various non-text ASCII characters.
I would guess this is a timing problem..

I've seen references alluding to this to in the book "Programming And Customizing The Multicore Propeller Microcontroller", but I am still unclear on how to diagnose and correct the problem.
I'm confident that most here have seen and dealt with this problem.

Can anyone provide guidance or a link to any tutorials that may give me the direction I need?

Thanks very much for your time and attention to my post.

Duane Degn

What sort of bit rates are you using?
Usually non-ASCII characters are caused by a error in the way a string is sent to the serial driver. Often an "@" symbol is either missing or used incorrectly.

While debugging, I often add a "SafeTx" method which catches non-ASCII characters and displays them as hexadecimal values.

PUB SafeTx(localCharacter)

  case localCharacter
    " ".."~":
      Serial.Tx(localCharacter)
    other:
      FramedHex(localCharacter)
      
PUB FramedHex(value)

  Serial.Tx("<")
  Serial.Tx("$")
  Serial.Hex(value, 2)
  Serial.Tx(">")

The above code assumes the serial driver has a "Tx" method. If you're using Parallax Serial Terminal.spin you'll want to change "Tx" calls to "Char" calls.

rikki

I'm at 115200.

code as follows:
__________________________________________________________
OBJ
pst : "Parallax Serial Terminal"


PUB mainLoop

' initialize the serial terminal for debug and test
pst.Start(115_200)

repeat
pst.str(string("test.. "))
waitcnt(clkfreq + cnt)
pst.str(string("test.. "))
waitcnt(clkfreq + cnt)

rikki

I have tried a lower rate, all the way down to 9600, (changing the rate in the serial initialization parameters and the setting in the terminal) with no improvement.

Chris Savage

Every time I see something like this it is because either the code doesn't have the Propeller running at 80 MHz (or at least off the crystal) or in rare cases, the PLL has been damaged resulting in the clock speed not being high enough to run the driver.

Electrodude

You're using the internal RC oscillator, when you should be using the crystal. Put

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

at the top of your program (supposing you have a 5MHz crystal; otherwise, change the number to match).

rikki

Electrodude wrote: »

You're using the internal RC oscillator, when you should be using the crystal. Put

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

at the top of your program (supposing you have a 5MHz crystal; otherwise, change the number to match).

I'm gonna have to start paying you Electrodude..
thanks again!

Chris Savage wrote: »

Every time I see something like this it is because either the code doesn't have the Propeller running at 80 MHz (or at least off the crystal) or in rare cases, the PLL has been damaged resulting in the clock speed not being high enough to run the driver.

Got it... thanks very much to you also for taking time to help.

DavidZemon

rikki wrote: »

Electrodude wrote: »

You're using the internal RC oscillator, when you should be using the crystal. Put

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

at the top of your program (supposing you have a 5MHz crystal; otherwise, change the number to match).

I'm gonna have to start paying you Electrodude..
thanks again!

I think we all follow the "Pay it forward" philosophy here.

I sure hope so anyway.... otherwise I'm in serious debt to a lot of forum members!

rikki

Understood..

I will hope to be able to give to the community here at some point..
Not that I'll be able to work at the level of the real programmers here, but perhaps at some point I can at least help with the beginner questions, much as those requests I've posted here so far. I keep notes, have no doubt about that..

rikki

Duane Degn wrote: »

What sort of bit rates are you using?
Usually non-ASCII characters are caused by a error in the way a string is sent to the serial driver. Often an "@" symbol is either missing or used incorrectly.

While debugging, I often add a "SafeTx" method which catches non-ASCII characters and displays them as hexadecimal values.

The above code assumes the serial driver has a "Tx" method. If you're using Parallax Serial Terminal.spin you'll want to change "Tx" calls to "Char" calls.

lest I forget.... thanks Duane for the excellent tool!



..