Basic help with Full-Duplex Serial Driver v1.2

BrainBlank

I am trying to use the built in USB port on the Propeller Proto Board USB.

Here is my .spin program:
OBJ
Com : "FullDuplexSerial"
PUB Main
Com.start(31, 30, %0000, 9_600)
repeat 'Echo forever
Com.tx($00)
Com.stop

Doing this sends 0x80 over and over to the receiving terminal on the PC.

What am I missing?

Some more info.
To test that the port was actually working and normal data could be recieved I loaded the FemtoBasic_PropTerminal. This works great. Even using something other than the PropTerminal that is able to not assert DTR.

Mike Green

Your problem looks like you're using the default built-in RCFAST clock which is not accurate. When you send $00, this produces a start bit (0), then 8 data bits (0), followed by a stop bit (1) plus a little idle time (1). The Propeller's clock is running a little faster than FullDuplexSerial thinks, so the PC sees a start bit, 7 data bits (0) and an 8th data bit (1) which is actually the stop bit giving you the $80 that you're seeing.

Use the crystal on the Protoboard by including this in your program:

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

Invent-O-Doc

Did you set the clock frequency at the beginning of the program?
CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

Did you properly indent the com statemnts after the repeat?

I hope this helps!

BrainBlank

Mike that fixed it perfectly. Thank you for your help.

Since I am kinda new to the Prop I was not aware of these things.

Here is my updated code for anyone else who wants to see a working sample:

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 

VAR
byte x

OBJ
 Com : "FullDuplexSerial"
PUB Main
 Com.start(31, 30, %0000, 9_600)
 repeat  'Echo forever
  repeat x from 0 to 255
    Com.tx(x)

Com.stop

CannibalRobotics

I've had a problem with sending and receiving null's but I don't remember FDS has any code to toss out $00. The string handler uses it as a marker but that shouldn't matter.

A delay or count is needed. This little repeat can execute quite a few times before the first byte is sent at 9600. You might be blowing the buffer.

Just for fun, try a sequence of different bytes, maybe $00 to $0F and see what that sends. It might help you find out if something else is writting into the transmit buffer. If one or two of the sent bytes are wrong but the rest are right then it's a good indicator of memory problems.