serial first nibble problem

muniorbust

I've got my 32-pin propeller dip on a breadboard up an running. This is my first time trying to get a propeller running outside of a starter kit board.
I decided to get a simple serial connection working to my pc.
I'm using a MAX3232 TTL - RS232 board (pre-soldered with caps and pins) between my prop TX output and PC serial cable.

I've connected the P15 to the TX pin of the max3232 board.
I'm using FullDuplexSerial.spin and my test program to output "Hello World" repeatedly.

I'm expecting this:             48 65 6c 6c 6f 20 57 6f 72 6c 64                 Hello World
But see this on my PC terminal: a8 b5 bc bc bf 90 a7 bf b2 bc b4                 ¨µ¼¼¿ §¿²¼´

It's close, but the first nibble of each byte is off.
4 becomes A (0100 becomes 1010)
6 becomes B (0110 becomes 1011)
2 becomes 9 (0010 becomes 1001)
5 becomes A (0101 becomes 1010)

It looks like the nibble is shifted right and a 1 is shifted in.

Any guesses to what's going on?
Buzz

Mike Green

It looks like you've got the Baud wrong either on the PC or the Propeller. The least significant bit is sent first, then the most significant bit is sent last followed by a stop bit (always 1). Either the Propeller is sending too fast or the PC is receiving too slowly. Things go ok for 4 bits, then the relative timing becomes so off that the last several bits get interpreted incorrectly. Perhaps the Propeller's clock is faster than you've indicated using CLKFREQ / XINFREQ / CLKMODE.

Duane C. Johnson

Hi Buzz;

I suspect the baud settings are correct, otherwise the bits received would be gibberish.
The data bits are just about correct, just off a little bit. And the "1" looks like the stop bit.

I think the clock is off just a little bit.
Are you running on the internal RC clock? This clock has a lot of frequency error and drift as opposed to a crystal or resonator.
Or
Maybe the crystal is outside the allowable frequency range so the Phase Locked Loop clock is unstable.
Or
There is not enough power buss filter caps on the plug board especially the VDD pin next to the crystal.
One of mine does this. Ok not enough to disrupt the serial interface but is quite measurable with a frequency counter.

Duane J

muniorbust

Thanks for the responses!!

I am in fact running with the internal RC clock.
At the top of my test program:

CON   
    _clkmode = RCFAST

Short term, what's my best bet? Can I determine and explicitly assign the internal clock frequency?

Sounds like in the long term I should just get an external crystal? Is there a recommended frequency/crystal?
Looks like 5Mhz is common.

Buzz

Mark_T

The RCFAST oscillator is nominally 12MHz but only guaranteed to be between 8 and 20MHz - asynchronous serial I/O requires a clock accurate to 3% or so, this means crystal or resonator or some external source of the required accuracy.

Duane C. Johnson

Hi Buzz;

muniorbust wrote: »

I am in fact running with the internal RC clock. At the top of my test program:

CON   
    _clkmode = RCFAST

Short term, what's my best bet? Can I determine and explicitly assign the internal clock frequency?

Yes, sort of.
I assume you are using one of the serial objects.
They do a calculation to setup the serial timing usually based on the Prop's clock frequency.
You probably set this up based on the assumed nominal RC Fast clock frequency of about 12MHz.
However, the spec says it can be between 8MHz and 20MHz.
If you use a frequency counter you can measure this and use this in the serial object.
This should work. At least temporarily.

You can also just play around with the frequency in the object. Quick and dirty but can be done.

Keep in mind that this RC frequency is not very stable and will vary depending on the temperature.
Sure you can get it to work today, but tomorrow? Just adjust it again.

muniorbust wrote: »

Sounds like in the long term I should just get an external crystal?
Is there a recommended frequency/crystal?
Looks like 5Mhz is common.

Clearly, if serial is used a crystal is required in the long run.

Duane J

muniorbust

Thanks for the advice.
For the short term I was able to use 13_000_000 instead of clkfreq in FullDuplexSerial.spin.

Hello World!!! :P

JonnyMac

Short term, what's my best bet? Can I determine and explicitly assign the internal clock frequency?

If you have a scope you can output a known pulse width and measure it, the apply the measured value against the expected value to determine the actual RC frequency. There's a section in this article that may help:

-- http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf

Note that the article discusses PropBASIC, but the strategy still applies.