to synchronize rs232 signal

Johnnyfumi

Hy, i'm sorry if my questions is always so lowly, but i'm just a beginner. So i'm trying· to realize a rs232 interface between propeller and pc. i'm using "FullDuplexSerial" (library) but i think there are some synchronization problem. This is a sample of my code:
······
····· Con
··········· p = $2

·······Obj
··········· fullduplex : "FullDuplexSerial"

·······Pub main
··········· fullduplex.start(0,1,1,9600)
··········· fullduplex.tx(p)

in this way i read on my pc (i open a com port whit java program) two items ( "0" and "2" or if p = $7 i read "0" and "7" ) but·i don't undestand why. Maybe there are some synchronization problem but i don't know how can i solve it. Maybe i have to set in different way any parameters in my code or in "FullDuplexSerial" but i don' know witch can i change.

thank you all

Johnny

Mike Green

The comments in FullDuplexSerial.spin describe the parameters:

PUB start(rxpin, txpin, mode, baudrate) : okay

'' Start serial driver - starts a cog
'' returns false if no cog available
''
'' mode bit 0 = invert rx
'' mode bit 1 = invert tx
'' mode bit 2 = open-drain/source tx
'' mode bit 3 = ignore tx echo on rx

Do you want the mode to invert the transmit line, but not the receive line? Do you understand what these parameter values mean?

How do you have the Propeller and PC connected?

Johnnyfumi

I connected the PC and propeller through a serial-to-usb converter cable and connect the serial port to propeller with a max232 3.3v on pin P0 and P1. For the moment i'm interesting only in unidirectional communication from propeller to PC (later i'll explore the rest), but i confes that i don't exactely know what this parameters means (i'm trying to learn more about studing the serial rs232 8n1 protocol).··I believed that mode = 0·is used to communicate in the direction propelles to PC and that mode = 1 is used for to invert the communication.·I could to address a Cog0 for communication with mode = 0 and Cog1 for the other.

J

Cluso99

I think your Java program may be interpreting the result and converting to hex. A $02 is a control character in ASCII and therefore may be converted by your Java applet. You could also check to ensure you haven't called the output hex routine in the serial driver.

Have you tried sending characters $41 to $59 for A to Z ? This may help identify your problem.

Mike Green

Usually both transmit and receive are the same mode value. Usually with a MAX3232 or MAX232, the mode bits are zero.

Johnnyfumi

Hello,
first thank you guy for you support, but i think my problem is not about java applet's interpretation. If i send a single value,·hex or binary it's not important, i read two values and it's biggest problem then interpretation problem [noparse];)[/noparse]
If a send value "%110" i read "0" and "5" on my java terminal. So i think that maybe there is a synchronizzation fault that split my value in two part; is it possible?

J

Mike Green

I don't think your program is even receiving the data to begin with. Make sure the mode bits and the Baud are set properly first. A good starting point is 9600 Baud and mode %0000. You can try mode %0011, but that's not normally used with a MAX232 or MAX3232. Synchronization problems usually happen when a block of data is sent, one character sent immediately after the other with no separation, and the Baud on one end is wrong.

Johnnyfumi

Ok guys, maybe i find a bug...this is the situation: i use fullDuplex library whit the following parameters

1 ) rxpin = 0

2) txpin = 1

3) mode = 0

4) baudrate = 9600

Whit method tx(variable) in fullduplex library i send a single word p = "%110" such fullduplex.tx(p) . So i use two different program "hyperterminal" (microsoft) and "Terminal" and i read always two words "00" and "07" so i'm sure that the problem is the fullduplex library. That's my only belivable conclusion [noparse];)[/noparse]

thanks for you patience

Johnny

Mike Green

I don't think there's a bug in the FullDuplexSerial library. I've gone over the code very carefully as I've modified it for my own purposes as I'm sure Chip (the author) has done and others have done. More important, this object is used extensively, including with the start parameters you're using and with the same character values. More likely, there's something about your program. Without a complete listing, it's hard to tell what's going on. Keep in mind that the value %110 is the character 6 (ASCII ACK). Many terminal programs discard or interpret these control characters in undefined ways. I don't remember what Hyperterminal does, but I would not trust it. Some terminal programs can be configured to display control characters in a human readable way, but many cannot.

If your program stops itself after trying to send the %110 value, the actual transmission of the value may not have completed. FullDuplexSerial is buffered. At 9600 Baud, it will take about a millisecond to actually send the character. If your program ends first, the I/O pin will be reset to input mode and the MAX232 or MAX3232 may be just transmitting noise pulses.

Post Edited (Mike Green) : 5/11/2008 4:07:56 PM GMT

Johnnyfumi

Hi Mike,
i send you my simplest program

CON
p = %111

OBJ

fullduplex : "fullduplex"

Pub Main

fullduplex.start(0,1,0,9600)
repeat 4
fullduplex.tx(p)

and i send you also the result of "Terminal" <00 07 07 07>

if i start 3 times consecutively this program ao "Terminal" i read <00 07 07 07 00 00 07 07 07 07 00 07 07 07 07>

I'm really desperate but i don't understand..

Johnnyfumi

Hi mike i forget this...If you want and if you can, you could send me an your simple program and i will try to understand using that...
thank you very very much and sorry for my insistence...

my mail address is:

alessandro.amadorsen@hotmail.it

Mike Green

Your program is working the way it's written. The first zero byte is probably due to noise on the transmit line as your program is initializing. To fix that, use a pullup resistor on the MAX232 transmit input (10K will work). The 3 or 4 bytes with a %111 value are exactly what your program is sending. The reason for less than 4 bytes is that your program ends before the last byte is sent or sent completely. To fix that, put a "waitcnt(clkfreq/4 + cnt)" as the last statement in your Main method. This will add a 250ms delay before the program exits to allow any characters in the transmit buffer to be sent.

Cluso99

Try sending $41 which is a printable character "A" (%01000001) and see what you get.

You are sending unprintable characters ($07) and so it depends on software what it will do. This is masking your real problem.