views:

127

answers:

3

My brain is fried, so I thought I would pass this one to the community.

When sending 1 character to my embedded system, it consistently thinks it receives 2 characters. The first received character seems to map to the transmitted character (in some unkown way) and the second received character is always 0xff

Here is what I observed:

Tx char (in hex)    Rx character (in hex), I left out the second byte (always ff)
31                    9D
32                    9B
33                    99
61                    3D
62                    3B
63                    39
64                    37
65                    35
41                    7D
42                    7B
43                    79

I have check my clocks and them seem to be ok. The only diff between this non working version and the previous version is that i am now using a RS485 chip. I have traced the signal all the way up to the MCU and it looks fine (confirmed the bit value on the rx pin)

+1  A: 

RS485 is quite different from RS232 at the electrical level (differential versus single ended and +/-6V versus +15/-3V) - are both sides of your communication link using the same protocol?

mtrw
Absolutely! I have an sn75.... rs485 chip on the USB/serial cable side, and 1 on my micro board.
michael
Good. I got confused when you said "now using a RS485 chip" - it made me think you'd changed only one end of the link. Anyway, looks like Mark might have solved it by inspection!
mtrw
+1  A: 

If it's RS485 have you got the "default state" of the bus set correctly? How about the correct number of stop bits?

peter_mcc
Yep, it should be good, the code is the same from when I used straight UART (rs232) and that stuff worked! I also made sure to have proper selector pins set the direction of the rs485 chip when sending or receiving
michael
+9  A: 

The first received character seems to map to the transmitted character (in some unkown way)

In each case the TX byte is shifted left 1 bit then inverted.

For instance:

31 = 00110001 9D = 10011101

0x31 << 1 = 01100010

the complement of 01100010 is 0x9D

I checked a couple of the others, looks to be the same for them all. I don't know where the second byte is coming from but it could be a result of the likely signal inversion thats going on.

RS485 uses differential signaling. It smells like you used the inverted output of the chip and plugged into a RS232 input.

I have traced the signal all the way up to the MCU and it looks fine (confirmed the bit value on the rx pin)

What signal did you use as the ground reference?

Mark
Will an rs485 convertor actually work if the + and - lines are swapped? ie will the uart side still generate a byte? if so then what is being generated here makes sense as the UART would get confused when the stop and start bits are inverted.
michael
And the extra crap byte at the end would make sense too. If a start bit was mistakenly seen at the end, the next byte would just be all logical ones. I think. I am no where near my scope, and my dev kit.
michael
Nice answer - who needs a scope when you've got Mark on Stackoverflow?
Michael Burr
@michael yes the rs485 link would "operate" with the +/- connections inverted assuming both ends of the wire are rs485 transceivers. The signal would appear inverted if you wired it that way so that could well be the problem. There are conflicting methods of naming the +/- terminals (A/B) in the 485 world so check into it.
Mark
If the UART has a signal invert option built-in, that may be simpler than changing the wiring.
Clifford
@michael I think your on to something with the start bit(or lack of it) This would account for the 1 bit shift and the trialling 0xff.
simon