Problem with crystal, baudrate. PST

FredBlais

Hi,

I've been playing around with pyserial python library and the propeller. What I did is sending 64 bytes to the propeller and echo it back to the computer (python script) with some strings added to give some information.
Sending data from python to propeller worked well at 115200 (Hydra board: xtal _clkmode = xtal2 + pll8x _xinfreq = 10_000_000). The problem lies in sending it back to the computer, it did not work with these settings. I received an almost complete string with $FE and $F0 ending, characters that I never sent.

After a while, I decided to use pll2x and 57600 baud rate (both prop and computer...) and it worked really well, no more errors. Lowering the pll annoy me a little bit, can anyone share is thoughts on this?

The spin code is really simple... I can share it if it can help solve the problem.

Thanks a lot,
Fred

MagIO2

You did not tell us which computer you have? I once did some serial IO with a RaspberryPi/Linux in C and it worked pretty well far above 115200baud.

So, which machine, which OS do we talk about?

Why did you go down with the clock AND the baudrate? Wouldn't it work to keep the clock and go down with the baudrate only?

Maybe you could give another serial driver a try: http://forums.parallax.com/showthread.php/143514-Fast-Full-Duplex-Serial-1-Cog-a.k.a.-FFDS1
This is advertised as being more accurate in bit-timings.

SRLM

I've used pyserial at 230400 baud, and was reliable.

You may try putting a delay of 1ms between each byte, and seeing if there is any change in the results. I did an experiment of sending a stream of bytes without any delay (ie, at maximum bandwidth) and the Propeller couldn't receive them fast enough using the serial driver that I had.

This was on Windows and Ubuntu.

If you share both sets of code we may be able to help more.

FredBlais

Hi,

my machine is a 2.4GHz i7-3630QM with 16GB of RAM and 64-bit Windows 8. I got the clock down and baudrate because it did not work otherwise. Sending to the Propeller is okay, receiving to the computer is the problem.

TX - Propeller

PUB PrintSequence | data
  ''Print all the commands
  byte_cnt := 0

  pst.Str(string("Commands:"))
  pst.LineFeed
  repeat MAX_COMMAND_BYTES
    data := commands[byte_cnt++]
    pst.Dec(data)
    pst.LineFeed
  Wait(100)   
  pst.Str(string("Number of bytes: "))
  pst.Dec(byte_cnt)
  pst.LineFeed
  pst.Char(0) 'The end (null character)

RX - Python

#Special read : read the bytes as string and when there is a newline, it marks the end of string
#Return all the strings in a array (tuple) stop reading when null character received chr(0)
def read():
    data = []
    buffer = []
    while(True):
        value = ser.read()
        if value == "\n": #LineFeed
            data.append("".join(buffer))
            buffer = [] #Flush the buffer
        elif value == chr(0):
            break
        else:
            buffer.append(value)
    print tuple(data)
    return tuple(data)

#Print the data echoed (debug)
for data in read():
    print(data)

I will try putting delay between my sent bytes and tell you if it's better

Thanks for your feedback,
Fred

SRLM

Does the program work at 57600 with the 80MHz clock speed?

I would try this Propeller code:

repeat
   pst.Char(pst.CharIn)

Then, try sending it 12 bytes or so (no more than 16). That's distilling it down to it's very basic roots. If that doesn't work, then it's probably not your code.

If you have access to one, you might also try using an oscilloscope or logic analyzer to take a look at the bytes sent. The proper tools really speed up the debugging process.