Serial Terminal not working.

Kirk Fraser

While trying to debug another program I ran from the PE Kit, Objects Lab, TextMessages.spin - after setting the serTerm to 57600 as per the program, it displayed garbage continuously. Why not the comprehensible text it is being sent?

I tried downloading Serial Terminal again from Parallax but that didn't do it either. What could be happening? How can I fix it?

Thanks.

turbosupra

It's one of two things

The prop serial you are using is not configured properly with 8N1 and 57_600 or the following is missing from the parent object (or whatever your crystal settings should be)

_CLKMODE      = XTAL1 + PLL16X                        
  _CLKFREQ      = 80_000_000

Duane Degn

Brad brings up a good point about clock settings.

What board are you using?

Some boards have removable crystals that can come lose. Make sure any crystal on the board is secure.

Kirk Fraser

turbosupra wrote: »

It's one of two things

The prop serial you are using is not configured properly with 8N1 and 57_600 or the following is missing from the parent object (or whatever your crystal settings should be)

_CLKMODE      = XTAL1 + PLL16X                        
  _CLKFREQ      = 80_000_000

That was it! Thank you very much.

turbosupra

You're welcome

Kirk Fraser

turbosupra's comment made me remember to change
_CLKFREQ = 6_250_000
which works well with my setup and the example code cited.

Duane Degn wrote: »

Brad brings up a good point about clock settings.

What board are you using?

Some boards have removable crystals that can come lose. Make sure any crystal on the board is secure.

My board is a standard 3M Solderless Breadboard wired as in the diagram on page 17 of http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/WebPM-v1.1.pdf

Your software Duane has some additional bug which changing the CLKFRQ as above does not solve. Perhaps it is related to the reason both of you used a value of 80_000_000 for the CLKFRQ instead of the crystal frequency which for you apparently is 5_000_000? I presume that somehow affects the code in the serial terminal.

Interesting, when I changed CLKFRQ to 100_000_000 the test text I added to your code worked. So why does the SerTerm accept the crystal frequency in the cited example TextMessages program but in yours it requires the clock frequency which is the crystal frequency times 16?

Oh, I finally see it, the example program uses _xinfreq instead of _clkfrq which your code uses and my success on the example was just random because I didn't notice the difference in variable names before. Ok then. To prevent this problem from arising again for everyone, I wonder if it's possible to sense the actual crystal frequency instead of "assuming" it is a 5MHz crystal?

In my opinion, adding crystal sensing code to the serTerm object setup module would be a useful update.

Mike G

I doubt the constant _CLKFREQ = 6_250_000 produces expected results.

Do you have a 6.25MHz crystal?

_clkmode = xtal1 + pll16x 
_xinfreq = 6_250_000

Interesting, when I changed CLKFRQ to 100_000_000 the test text I added to your code worked. So why does the SerTerm accept the crystal frequency in the cited example TextMessages program but in yours it requires the clock frequency which is the crystal frequency times 16?

The top level object configures the system clock frequency. Clock configuration is openly published in the Propeller manual.

Ok then. To prevent this problem from arising again for everyone, I wonder if it's possible to sense the actual crystal frequency instead of "assuming" it is a 5MHz crystal?

In my opinion, adding crystal sensing code to the serTerm object setup module would be a useful update.

According to Nyquist, minimum sampling rate must be at least 2 times the highest frequency of the sampled signal. The Propeller's Internal fast oscillator is about 12 MHz and may be 8 MHz to 20 MHz. It might be possible to guess the external frequency but probably not reliable. Besides the technical aspect of using software for sensing an external clock, the circuit is homemade. IMHO the circuit builder should know the the technical details of the crystal in use.

Secondly and most notably, how is it possible for the software to select the developers intended system clock frequency? I'd get a little upset if software changed my clock settings. Especially if it caused unexpected results.