Re: [Ftdi-usb-sio-devel] Data corruption on serial link using FTDI USB to serial driver and RS232

[Mats J. <mat...@te...>]

Thanks Bill,

When I get back to work I will get into this again.
My PC is running Windows, but I actually have two serial ports on my emebedded system, so I will try to send between these two instead, and then I can play around with the settings of the port they way you suggest.

/Mats

17 mars 2018 kl. 00:56, "Bill Ryder" <bil...@gm... (mailto:%22Bill%20Ryder%22%20<bil...@gm...>)> skrev:
Good call Michael.
The pattern in the bytes is indicative of mismatched serial parameters.
Re the different byte counts you are getting - that completely depends on when the data is available on the interface - there's no guarantee that the blocks of data you are sending will be delivered in the same chunks you have put them on the interface unless you make extra system calls. 
I see you are missing the last little chunk of data which suggests there was still that data in the buffers to be read. 
Your expected output should include a newline because echo puts a newline on the output stream if you don't use the -n option 
In ubuntu 1604 (and probably most linuxes) you can use this to check the serial settings 
sudo stty -a --file=/dev/ttyUSB0 
 speed 9600 baud; rows 0; columns 0; line = 0; 
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; 
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; 
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; 
 -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts 
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany -imaxbel -iutf8 
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc  
man stty will tell you what the settings are. 
You can change them with stty as well - but - at least in the old days - you have to hold that device open, or the settings will reset when the file is closed. 
I suggest you use the tool screen to talk to the serial interface, you can set parity etc and everything you type should go to the port and you'll have proper control over the serial parameters. 
screen isn't necessarily installed by default so you may have to install it. 
On 17 March 2018 at 12:14, Michael Plante <mic...@gm... (mailto:mic...@gm...)> wrote:

  Mats, I don't know the answer, but I see patterns in the data. I suggest carefully checking parity, 1vs2 stop bits, and 7vs8 bits/char and reporting what you see. I can't remember the chipset, but I've seen some converters don't respect all those settings, so you might try 8n1 if you can. Buffering with usb to serial is hit or miss in my experience. I assume the converter is COTS, not custom, and it's a plain serial cable. An oscope would make this easier. Maybe also try sending other patterns involving 5,A,3,C.   Michael    
On Mar 16, 2018 10:33, "Mats Jansson" <mat...@te... (mailto:mat...@te...)> wrote:Hi,

I have a problem with the FTDI USB Serial port driver in an embedded
system.
The embedded system is a running Linux kernel 4.4, and we have an
atmel processor.

The FTDI USB Serial port driver is built into the kernel.

I attach an the USB end of an FTDI USB to RS232 adapter to the linux unit and connect
the RS232 connector to a PC.

In a terminal window on my linux unit I do the following
$ echo 01234567899876543210 > /dev/ttyUSB0
$ echo 01234567899876543210 > /dev/ttyUSB0
$ echo 01234567899876543210 > /dev/ttyUSB0
$ echo 01234567899876543210 > /dev/ttyUSB0
$ echo 01234567899876543210 > /dev/ttyUSB0

In the other end I have connected a PC and built a very simple program
that opens the COM port, reads data and prints it out.
I was expecting to get the data as (printed in hex values):
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]

But the resulting data on the PC from the three lines of echo above is:
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]
Read 28 bytes [76 96 B6 D6 F6 B6 00 D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 76 96 B6 D6 F6 B6 00 ]
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]
Read 15 bytes [76 96 B6 D6 F6 B6 00 D6 B6 96 76 56 36 16 F6 ]
Read 29 bytes [D6 D6 F6 16 36 56 76 96 B6 D6 F6 B6 00 D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 76 96 ]

Not only the data is not all what I suspected, there seems to be some
buffering issue.

I have tested with different speeds on the line, 2400, 9600, 57600 and
115200 and the result is the same in all cases. I have also tested to
send data the other way, and the result is similar.

Does anyone have any idea what could be wrong here?
Why is the data corrupted?

Best Regards,
Mats mailto:mat...@te... (mailto:mat...@te...)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot (http://sdm.link/slashdot)
_______________________________________________
Ftdi-usb-sio-devel mailing list
Ftd...@li... (mailto:Ftd...@li...)
https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel (https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel)    
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot (http://sdm.link/slashdot)
_______________________________________________
Ftdi-usb-sio-devel mailing list
Ftd...@li... (mailto:Ftd...@li...)
https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel (https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel)