Why do I get an extra CR when I send LF characters to serial port?

[RMACOM]

I am using CVI to receive data over the serial port from a development board. I call the ComRdByte function to receive the bytes. Everything works fine until the development board sends 0X0A (linefeed) to the serial port. CVI automatically adds a CR (0x0D) to the input queue! I have used OpenCommConfig to setup the serial port. Why is CVI adding the extra character to the queue? Is there a way to set it up so this doesn't happen?

[menchar]

I've used the rs-232 library a lot, with many devices, and have never seen this.  There are semantics to remove CR & LF in various ways when using ComRdTerm().

Maybe it's the serial driver doing it, rather than the NI serial library (which uses the serial driver).

How certain are you that the development board isn't issuing a CR?

terminal.exe is a freeware tool that I've used many times, it might help you get an "independent" view of what's happening on the serial port.

http://bray.velenje.cx/avr/terminal/

The link can be flakey - google "terminal bray" for another download link.

Menchar

[RMACOM]

I am certain that the development board is not doing it. I tested the scenario by sending mutilple 0x0A's from the development board and the CVI input queue always got an extra 0x0D for each 0x0a. I am running a debugger on the development board and can look at every character sent out of the UART.

[menchar]

Are you looking at the data being emitted by the UART or the data being sent to a serial driver on the development board?

Adding a CR to a LF is a common mechanism to make serial output more readable, but usually on the receiving end. 

Which serial driver are you using on the CVI end?  Are you using Windows?

[RMACOM]

On the development board I have a breakpoint where the UART register gets written to. I am only looking at the put_byte function and there is nothing below it to add another character. On the receiving side I am running Windows XP.

[menchar]

What's in between the development board and the PC?  Are you routed through a modem of any kind?

[RMACOM]

There is nothing between the two. It is a direct connection. Believe me, I checked all the obvious stuff.

[menchar]

This is quite the mystery.

I've looked at the Windows com config struct and I don't see where you can make the Windows XP serial driver add a carriage return to a line feed.

I'm curious what it will turn out to be. 

Did you have something else installed on the PC com port at some time that may have done some sort of config on the port, or inserted a serial driver?

Do you have a second com port on the PC side to try?  Or another PC?

Are you using a built-in com port on the PC, or an add-in port?

[jr_2005]

Many of my programs use the CVI RS232 library to transfer binary data, and I've never seen this effect. The only place that a 0x0D character is explicitly added to a string containing a 0x0A one, as far as I am aware, is when the string is being written to a file that has beed opened in text mode. I presume this is not your situation? How are you inspecting the data in the input queue?

JR

[RobertoBozzolo]

I've never observed such a phenomenon too, and I've been heavily using rs232 in my job.

According to the first post, RMACOM is using standard RS232 library (OpenComConfig and ComRdByte): one possibility could be to read back an entire strung from the connected device and see if the LF is added there too, or install a com callback on the CR character being received.

Just some suggestions...