ftdi-usb-sio-devel — FTDI USB Device Driver development discussion list

Re: [Ftdi-usb-sio-devel] ref: ftdi_sio driver has error from flowcontrol urb

[Bill R. <bil...@gm...>]

Hi Paul,

I haven't touched this stuff in years.

In my memory that kind of error indicates an underlying problem with the
usb layer.

You want to look at errors from the usb layers around this.

You might also have bad hardware of course.

It might be some power saving settings mistakenly shutting down the usb
devices too.

But I'm not up to date on it so unfortunately you'll need to google it!

All 'error from flowcontrol urb' means there was an error from the usb
packet of some form.





On Mon, 28 Jun 2021 at 14:52, Paul Wang <pau...@tr...> wrote:

> Hi guys,
>
> I am not sure if I am asking questions at the right place.
>
>
>
> I have a problem on ftdi_sio driver of Linux  4.14 running on hardware
> based on FreeScale’s iMX6ull.
>
>
>
> The ftdi_sio driver works fine at the beginning and keeps sending |
> receiving data for a few hours, until all of a sudden, there is an error:
>
> *ftdi_sio ttyUSB0: error from flowcontrol urb*
>
> Then ttyUSB0 either stops working, or disconnected as:
>
> *ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from
> ttyUSB0*
>
> or the system has received a reboot signal.
>
> This is happening almost 100% , but the time of occurring may be variant.
>
>
>
> From the Internet, I can see there are similar bug reports from others,
> but they seem not having a solid fix.
>
> I appreciate any information or helps from you.
>
>
>
> Regards.
>
> Paul Wang.
>
>
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

[Ftdi-usb-sio-devel] ref: ftdi_sio driver has error from flowcontrol urb

[Paul W. <pau...@tr...>]

Hi guys,

I am not sure if I am asking questions at the right place.



I have a problem on ftdi_sio driver of Linux  4.14 running on hardware
based on FreeScale’s iMX6ull.



The ftdi_sio driver works fine at the beginning and keeps sending |
receiving data for a few hours, until all of a sudden, there is an error:

*ftdi_sio ttyUSB0: error from flowcontrol urb*

Then ttyUSB0 either stops working, or disconnected as:

*ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from
ttyUSB0*

or the system has received a reboot signal.

This is happening almost 100% , but the time of occurring may be variant.



>From the Internet, I can see there are similar bug reports from others, but
they seem not having a solid fix.

I appreciate any information or helps from you.



Regards.

Paul Wang.

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

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

Apparently I have been using a USB to TTL converter cabel and not an USB to RS232.
I did not know there was a difference. I will test with a USB to RS232 tomorrow. It will most likely work right away.

My boss who gave me the cable did obvioulsy not know the difference either. He has joked about me not setting the serial parameters correct the last couple of days.
Now I can nag him about giving me the wrong cable :)

/Mats

20 mars 2018 kl. 17:31, "Michael Plante" <mic...@gm... (mailto:%22Michael%20Plante%22%20<mic...@gm...>)> skrev:

Sorry, I meant to write to the list, but was on my phone. 
   -----Original Message-----
From: Michael Plante [mailto:mic...@gm...]
Sent: Tuesday, March 20, 2018 12:30 PM
To: Mats Jansson
Subject: Re: [Ftdi-usb-sio-devel] Data corruption on serial link using FTDI USB to serial driver and RS232
  Is your converter TTL levels instead of RS232? 
 On Tue, Mar 20, 2018, 12:05 Mats Jansson <mat...@te... (mailto:mat...@te...)> wrote: 
 Hi,

I think I am closing in on this issue a bit.

I have noticed using a logical analyzer (digview) that the FTDI is normally high (+3.3V) between ground and TX/RX, while on the PC the signal is normally low.

So on the FTDI output the startbit makes the line go low, while on the PC the startbit makes the line go high.

If I in tell the DigiView software to interpret the signal inverted from the PC it will read the bytes as 30 31 32 33 34 35 36 37 38 39.

I don’t see why it is this way?

Is there something that needs to be configured in our driver in our embedded system to make it invert the signals, so that the PC can recogize it correctly?

/Mats
Med vänlig hälsning,
Mats mailto:mat...@te... (mailto:mat...@te...)
den 19 mars 2018, skrev du till mig:
   Hej Bill and Michael,

As I said two ports on my embedded system. These are both USB ports.

I have now tried out connecting an FTDI USB-Serial converter to both of these and connnected them to each other.
This way I can echo to one of the ports e.g /dev/ttyUSB0 and I get the correct data sent to the other port, i.e. /dev/tty/USB1.
It also works like a charm when I send the other way, i.e. from /dev/ttyUSB1 to /dev/ttyUSB0.

It works both if use the default settings of the ports, and also if i use the stty command to set the parameters to raw.

When connecting to my Windows machine I still get the same error.

I am trying to set up so that my virtual machine with Ubuntu 16.04 running under Windows and Virtual box to use the serial port COM1 of my computer, but without any luck so far.
I get access denied when I try to access it, using echo.

Med vänlig hälsning,
Mats mailto:mat...@te... (mailto:mat...@te...)
den 17 mars 2018, skrev du till mig:
   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)

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

[Michael P. <mic...@gm...>]

Sorry, I meant to write to the list, but was on my phone.


  -----Original Message-----
  From: Michael Plante [mailto:mic...@gm...]
  Sent: Tuesday, March 20, 2018 12:30 PM
  To: Mats Jansson
  Subject: Re: [Ftdi-usb-sio-devel] Data corruption on serial link using FTDI USB to serial driver and RS232


  Is your converter TTL levels instead of RS232?


  On Tue, Mar 20, 2018, 12:05 Mats Jansson <mat...@te...> wrote:

    Hi,
     
    I think I am closing in on this issue a bit.
     
    I have noticed using a logical analyzer (digview) that the FTDI is normally high (+3.3V) between ground and TX/RX, while on the PC the signal is normally low.
     
    So on the FTDI output the startbit makes the line go low, while on the PC the startbit makes the line go high.
     
    If I in tell the DigiView software to interpret the signal inverted from the PC it will read the bytes as 30 31 32 33 34 35 36 37 38 39.
     
    I don’t see why it is this way?

    Is there something that needs to be configured in our driver in our embedded system to make it invert the signals, so that the PC can recogize it correctly?
     
    /Mats

     

    Med vänlig hälsning,
    Mats                            mailto:mat...@te...


    den 19 mars 2018, skrev du till mig:


         Hej Bill and Michael,

          As I said two ports on my embedded system. These are both USB ports.

          I have now tried out connecting an FTDI USB-Serial converter to both of these and connnected them to each other.
          This way I can echo to one of the ports e.g /dev/ttyUSB0 and I get the correct data sent to the other port, i.e. /dev/tty/USB1.
          It also works like a charm when I send the other way, i.e. from /dev/ttyUSB1 to /dev/ttyUSB0.          

          It works both if use the default settings of the ports, and also if i use the stty command to set the parameters to raw.

          When connecting to my Windows machine I still get the same error.

          I am trying to set up so that my virtual machine with Ubuntu 16.04 running under Windows and Virtual box to use the serial port COM1 of my computer, but without any luck so far.
          I get access denied when I try to access it, using echo.

          Med vänlig hälsning,
          Mats                            mailto:mat...@te...


          den 17 mars 2018, skrev du till mig:


               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...> 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...> 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...


                            ------------------------------------------------------------------------------
                            Check out the vibrant tech community on one of the world's most
                            engaging tech sites, Slashdot.org! http://sdm.link/slashdot
                            _______________________________________________
                            Ftdi-usb-sio-devel mailing list
                            Ftd...@li...
                            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
                      _______________________________________________
                      Ftdi-usb-sio-devel mailing list
                      Ftd...@li...
                      https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel 
               
         

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

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

<html><head><title>Re: [Ftdi-usb-sio-devel] Data corruption on serial link using FTDI USB to serial driver and RS232</title>
</head>
<body>
<span style=" font-family:'Arial'; font-size: 12pt;">Hi,<br>
&nbsp;<br>
I think I am closing in on this issue a bit.<br>
&nbsp;<br>
I have noticed using a logical analyzer (digview) that the FTDI is normally high (+3.3V) between ground and TX/RX, while on the PC the signal is normally low.<br>
&nbsp;<br>
So on the FTDI output the startbit makes the line go low, while on the PC the startbit makes the line go high.<br>
&nbsp;<br>
If I in tell the DigiView software to interpret the signal inverted from the PC it will read the bytes as 30 31 32 33 34 35 36 37 38 39.<br>
&nbsp;<br>
I don&#8217;t see why it is this way?<br>
<br>
Is there something that needs to be configured in our driver in our embedded system to make it invert the signals, so that the PC can recogize it correctly?<br>
&nbsp;<br>
/Mats<br>
<br>
&nbsp;<br>
<br>
Med v&#228;nlig h&#228;lsning,<br>
Mats &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mailto:mat...@te...</a><br>
<br>
<br>
<span style=" font-family:'Arial'; font-size: 12pt;">den 19 mars 2018, skrev du till mig:<br>
<br>
</span><table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Hej Bill and Michael,<br>
<br>
As I said two ports on my embedded system. These are both USB ports.<br>
<br>
I have now tried out connecting an FTDI USB-Serial converter to both of these and connnected them to each other.<br>
This way I can echo to one of the ports e.g /dev/ttyUSB0 and I get the correct data sent to the other port, i.e. /dev/tty/USB1.<br>
It also works like a charm when I send the other way, i.e. from /dev/ttyUSB1 to /dev/ttyUSB0. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
<br>
It works both if use the default settings of the ports, and also if i use the stty command to set the parameters to raw.<br>
<br>
When connecting to my Windows machine I still get the same error.<br>
<br>
I am trying to set up so that my virtual machine with Ubuntu 16.04 running under Windows and Virtual box to use the serial port COM1 of my computer, but without any luck so far.<br>
I get access denied when I try to access it, using echo.<br>
<br>
Med v&#228;nlig h&#228;lsning,<br>
Mats &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mailto:mat...@te...</a><br>
<br>
<br>
<span style=" font-family:'arial'; font-size: 12pt;">den 17 mars 2018, skrev du till mig:<br>
<br>
</span><table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Good call Michael.<br>
<br>
The pattern in the bytes is indicative of mismatched serial parameters.<br>
<br>
Re the different byte counts you are getting - &nbsp;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.<br>
<br>
I see you are missing the last little chunk of data which suggests there was still that data in the buffers to be read.<br>
<br>
<span style=" font-size: 11pt; color: #222222;">Your expected output should include a newline because echo puts a newline on the output stream if you don't use the -n option<br>
<span style=" font-size: 12pt; color: #000000;">In ubuntu 1604 (and probably most linuxes) you can use this to check the serial settings<br>
<br>
sudo stty -a --file=/dev/ttyUSB0<br>
<br>
<b>speed 9600 baud</b>; rows 0; columns 0; line = 0;<br>
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = &lt;undef&gt;;<br>
eol2 = &lt;undef&gt;; swtch = &lt;undef&gt;; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;<br>
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;<br>
<b>-parenb -parodd</b>&nbsp;-cmspar <b>cs8</b>&nbsp;hupcl <b>-cstopb </b>cread clocal -crtscts<br>
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff<br>
-iuclc -ixany -imaxbel -iutf8<br>
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0<br>
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt<br>
echoctl echoke -flusho -extproc<br>
<br>
man stty will tell you what the settings are.<br>
<br>
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.<br>
<br>
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.<br>
<br>
screen isn't necessarily installed by default so you may have to install it.<br>
<br>
On 17 March 2018 at 12:14, Michael Plante &lt;</span></span></span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mic...@gm...">mic...@gm...</a><span style=" font-family:'arial'; font-size: 12pt;">&gt; wrote:<br>
</span><table>
<tr>
<td width=2 bgcolor= #3200ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Mats,<br>
<br>
I don't know the answer, but I see patterns in the data. &nbsp;I suggest carefully checking parity, 1vs2 stop bits, and 7vs8 bits/char and reporting what you see. &nbsp;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. &nbsp;Buffering with usb to serial is hit or miss in my experience. &nbsp;I assume the converter is COTS, not custom, and it's a plain serial cable. &nbsp;An oscope would make this easier. &nbsp;Maybe also try sending other patterns involving 5,A,3,C.<br>
<br>
<span style=" color: #888888;">Michael<br>
<br>
<br>
<span style=" color: #000000;">On Mar 16, 2018 10:33, "Mats Jansson" &lt;</span></span></span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mat...@te...</a><span style=" font-family:'arial'; font-size: 12pt;">&gt; wrote:<br>
</span><table>
<tr>
<td width=2 bgcolor= #6400ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Hi,<br>
<br>
I have a problem with the FTDI USB Serial port driver in an embedded<br>
system.<br>
The embedded system is a running Linux kernel 4.4, and we have an<br>
atmel processor.<br>
<br>
The FTDI USB Serial port driver is built into the kernel.<br>
<br>
I attach an the USB end of an FTDI USB to RS232 adapter to the linux unit and connect<br>
the RS232 connector to a PC.<br>
<br>
In a terminal window on my linux unit I do the following<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
<br>
In the other end I have connected a PC and built a very simple program<br>
that opens the COM port, reads data and prints it out.<br>
I was expecting to get the data as (printed in hex values):<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
<br>
But the resulting data on the PC from the three lines of echo above is:<br>
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]<br>
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 ]<br>
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]<br>
Read 15 bytes [76 96 B6 D6 F6 B6 00 D6 B6 96 76 56 36 16 F6 ]<br>
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 ]<br>
<br>
Not only the data is not all what I suspected, there seems to be some<br>
buffering issue.<br>
<br>
I have tested with different speeds on the line, 2400, 9600, 57600 and<br>
115200 and the result is the same in all cases. I have also tested to<br>
send data the other way, and the result is similar.<br>
<br>
Does anyone have any idea what could be wrong here?<br>
Why is the data corrupted?<br>
<br>
Best Regards,<br>
Mats &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mailto:</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mat...@te...</a><br>
<br>
<br>
<span style=" font-family:'arial'; font-size: 12pt;">------------------------------------------------------------------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, Slashdot.org! </span><a style=" font-family:'arial'; font-size: 12pt;" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>
<span style=" font-family:'arial'; font-size: 12pt;">_______________________________________________<br>
Ftdi-usb-sio-devel mailing list<br>
</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:Ftd...@li...">Ftd...@li...</a><br>
<a style=" font-family:'arial'; font-size: 12pt;" href="https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel">https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel</a></td>
</tr>
</table>
<br>
<span style=" font-family:'arial'; font-size: 12pt;">------------------------------------------------------------------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, Slashdot.org! </span><a style=" font-family:'arial'; font-size: 12pt;" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>
<span style=" font-family:'arial'; font-size: 12pt;">_______________________________________________<br>
Ftdi-usb-sio-devel mailing list<br>
</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:Ftd...@li...">Ftd...@li...</a><br>
<a style=" font-family:'arial'; font-size: 12pt;" href="https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel">https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel</a></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body></html>

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

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

<html><head><title>Re: [Ftdi-usb-sio-devel] Data corruption on serial link using FTDI USB to serial driver and RS232</title>
</head>
<body>
<span style=" font-family:'Arial'; font-size: 12pt;">Hej Bill and Michael,<br>
<br>
As I said two ports on my embedded system. These are both USB ports.<br>
<br>
I have now tried out connecting an FTDI USB-Serial converter to both of these and connnected them to each other.<br>
This way I can echo to one of the ports e.g /dev/ttyUSB0 and I get the correct data sent to the other port, i.e. /dev/tty/USB1.<br>
It also works like a charm when I send the other way, i.e. from /dev/ttyUSB1 to /dev/ttyUSB0. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
<br>
It works both if use the default settings of the ports, and also if i use the stty command to set the parameters to raw.<br>
<br>
When connecting to my Windows machine I still get the same error.<br>
<br>
I am trying to set up so that my virtual machine with Ubuntu 16.04 running under Windows and Virtual box to use the serial port COM1 of my computer, but without any luck so far.<br>
I get access denied when I try to access it, using echo.<br>
<br>
Med v&#228;nlig h&#228;lsning,<br>
Mats &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mailto:mat...@te...</a><br>
<br>
<br>
<span style=" font-family:'Arial'; font-size: 12pt;">den 17 mars 2018, skrev du till mig:<br>
<br>
</span><table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Good call Michael.<br>
<br>
The pattern in the bytes is indicative of mismatched serial parameters.<br>
<br>
Re the different byte counts you are getting - &nbsp;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.<br>
<br>
I see you are missing the last little chunk of data which suggests there was still that data in the buffers to be read.<br>
<br>
<span style=" font-size: 11pt; color: #222222;">Your expected output should include a newline because echo puts a newline on the output stream if you don't use the -n option<br>
<span style=" font-size: 12pt; color: #000000;">In ubuntu 1604 (and probably most linuxes) you can use this to check the serial settings<br>
<br>
sudo stty -a --file=/dev/ttyUSB0<br>
<br>
<b>speed 9600 baud</b>; rows 0; columns 0; line = 0;<br>
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = &lt;undef&gt;;<br>
eol2 = &lt;undef&gt;; swtch = &lt;undef&gt;; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;<br>
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;<br>
<b>-parenb -parodd</b>&nbsp;-cmspar <b>cs8</b>&nbsp;hupcl <b>-cstopb </b>cread clocal -crtscts<br>
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff<br>
-iuclc -ixany -imaxbel -iutf8<br>
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0<br>
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt<br>
echoctl echoke -flusho -extproc<br>
<br>
man stty will tell you what the settings are.<br>
<br>
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.<br>
<br>
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.<br>
<br>
screen isn't necessarily installed by default so you may have to install it.<br>
<br>
On 17 March 2018 at 12:14, Michael Plante &lt;</span></span></span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mic...@gm...">mic...@gm...</a><span style=" font-family:'arial'; font-size: 12pt;">&gt; wrote:<br>
</span><table>
<tr>
<td width=2 bgcolor= #3200ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Mats,<br>
<br>
I don't know the answer, but I see patterns in the data. &nbsp;I suggest carefully checking parity, 1vs2 stop bits, and 7vs8 bits/char and reporting what you see. &nbsp;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. &nbsp;Buffering with usb to serial is hit or miss in my experience. &nbsp;I assume the converter is COTS, not custom, and it's a plain serial cable. &nbsp;An oscope would make this easier. &nbsp;Maybe also try sending other patterns involving 5,A,3,C.<br>
<br>
<span style=" color: #888888;">Michael<br>
<br>
<br>
<span style=" color: #000000;">On Mar 16, 2018 10:33, "Mats Jansson" &lt;</span></span></span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mat...@te...</a><span style=" font-family:'arial'; font-size: 12pt;">&gt; wrote:<br>
</span><table>
<tr>
<td width=2 bgcolor= #6400ff><br>
</td>
<td><span style=" font-family:'arial'; font-size: 12pt;">Hi,<br>
<br>
I have a problem with the FTDI USB Serial port driver in an embedded<br>
system.<br>
The embedded system is a running Linux kernel 4.4, and we have an<br>
atmel processor.<br>
<br>
The FTDI USB Serial port driver is built into the kernel.<br>
<br>
I attach an the USB end of an FTDI USB to RS232 adapter to the linux unit and connect<br>
the RS232 connector to a PC.<br>
<br>
In a terminal window on my linux unit I do the following<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
$ echo 01234567899876543210 &gt; /dev/ttyUSB0<br>
<br>
In the other end I have connected a PC and built a very simple program<br>
that opens the COM port, reads data and prints it out.<br>
I was expecting to get the data as (printed in hex values):<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
Read 20 bytes [30 31 32 33 34 35 36 37 38 39 39 38 37 36 35 34 33 32 31 30]<br>
<br>
But the resulting data on the PC from the three lines of echo above is:<br>
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]<br>
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 ]<br>
Read 14 bytes [D6 B6 96 76 56 36 16 F6 D6 D6 F6 16 36 56 ]<br>
Read 15 bytes [76 96 B6 D6 F6 B6 00 D6 B6 96 76 56 36 16 F6 ]<br>
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 ]<br>
<br>
Not only the data is not all what I suspected, there seems to be some<br>
buffering issue.<br>
<br>
I have tested with different speeds on the line, 2400, 9600, 57600 and<br>
115200 and the result is the same in all cases. I have also tested to<br>
send data the other way, and the result is similar.<br>
<br>
Does anyone have any idea what could be wrong here?<br>
Why is the data corrupted?<br>
<br>
Best Regards,<br>
Mats &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mailto:</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:mat...@te...">mat...@te...</a><br>
<br>
<br>
<span style=" font-family:'arial'; font-size: 12pt;">------------------------------------------------------------------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, Slashdot.org! </span><a style=" font-family:'arial'; font-size: 12pt;" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>
<span style=" font-family:'arial'; font-size: 12pt;">_______________________________________________<br>
Ftdi-usb-sio-devel mailing list<br>
</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:Ftd...@li...">Ftd...@li...</a><br>
<a style=" font-family:'arial'; font-size: 12pt;" href="https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel">https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel</a></td>
</tr>
</table>
<br>
<span style=" font-family:'arial'; font-size: 12pt;">------------------------------------------------------------------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, Slashdot.org! </span><a style=" font-family:'arial'; font-size: 12pt;" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>
<span style=" font-family:'arial'; font-size: 12pt;">_______________________________________________<br>
Ftdi-usb-sio-devel mailing list<br>
</span><a style=" font-family:'arial'; font-size: 12pt;" href="mailto:Ftd...@li...">Ftd...@li...</a><br>
<a style=" font-family:'arial'; font-size: 12pt;" href="https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel">https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel</a><br>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body></html>

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)

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

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

Hi,

I will check more on monday when I get back to work,
But I do use N81. No flowcontrol on neither the PC (windows 10) nor the Linux side is configured.
The converter is some standard COTS device yes, with three wires, ground, rx and tx.

I have sent other patterns of bytes as well. The result is similar, just that the output is other bytes gets transferred.

/Mats

17 mars 2018 kl. 00:14, "Michael Plante" <mic...@gm... (mailto:%22Michael%20Plante%22%20<mic...@gm...>)> skrev:
 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)

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

[Bill R. <bil...@gm...>]

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...> 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...> 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...
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> 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
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

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

[Michael P. <mic...@gm...>]

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...> 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...
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

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

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

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...

[Ftdi-usb-sio-devel] 2 requests: (1) add new VID/PID, (2) Add Feature

[<du...@du...>]

Request #1
    Please add:
    Vendor id:    0403
    Product id:    a6d1
    Description:  Texas Instruments XDS100v3


    What is it? A Combination JTAG probe and Serial Port developers kit.
    This is commonly embedded in multiple development boards offered by
TI.
    TI Also provides design details, and several 3rd parties make
clones.

Additional detail here (and user manual)
    http://www.ti.com/lit/ug/swru321a/swru321a.pdf
    Specifically Section 4.1.2.2 - Page 9/32

    Also see:  Figure 6, Page 13/32 
    This shows the design "built into" an example development board.
    Note: This design is replicated in multiple places not just this
board.

    Schematics etc can be found in Appendix A of the document. 

Request #2
    By default the driver for the FT2232H - loads *TWO* serial ports.
    In this case, it *should*not* load two ports, it should load only
one port.

On Windows -it works differently. The FTDI driver reads the EEPROM and
determines which ports should have serial interfaces, and which should
not.

The request here is to act like windows and read the attached EEPROM and
examine the bit that identifies what each port *should* and *should* not
be configured as a serial port.


For example - 

step 1: You'll need an FTDI device with the FTDI drivers configured.
step 2: Run the FT_PROG (windows) application (this tool is used to
program the EPROM)
Step 3: Select DEVICES -> SCAN AND PARSE
Step 4: You'll find the FT_EEPROM in the menu
Step 5: Expand the "Hardware Specific" tab
Step 6: Expand the "Port A" (or B, or C ... ) tab and the "Driver"
sub-tab.
Take note:  Radio Buttons:  "Virtual COM Port" vrs "D2XX Direct"

The request here is this:

If the port is marked as VIRTUAL COM port, the driver should load for
this comport.
If the port is marked as D2XX - do not configure the port as a comport.

Thanks.




S

Re: [Ftdi-usb-sio-devel] Problem passing custom VID/PID to ftdi-sio

[Bill R. <bil...@gm...>]

Thanks for sharing that information!

On Thu, May 21, 2015 at 7:49 PM, Roger O. Jones <ro...@pp...>
wrote:

> On 20/05/2015 16:22, Roger O. Jones MIET wrote:
> > We've used a custom `udev` rule on the Pi to pass the correct VID
> > and  PID to the driver (as per the instructions in the "FTDI
> > Technical Note  101" and the ftdi-sio webpage) and this worked
> > previously on the Raspberry Pi Model B (raspbian with kernel
> > 3.10.25+) but today I've  tried it on a Raspberry Pi A+ (raspbian with
> > kernel 3.18.11+) but get  errors in `dmesg` from the `udev` rule and the
> > device is not recognized.
> > --8<----
> > # dmesg | grep ftdi
> > ftdi_sio: unknown parameter 'product' ignored
> > ftdi_sio: unknown parameter 'vendor' ignored
> > usbcore: registered new interface driver ftdi_sio
> > ---->8--
>
> OK, found that this is down to a change in the kernel 3.12 and later
> that impacts on the way that custom VID and PID are sent to the driver.
> We now need to load the driver and then add the new numbers to the
> `/sys/bus/usb-serial/drivers/ftdi_sio/new_id` virtual file.
>
> I've amended my `udev` rule and it seesm to work.
>
> Here the link I found explaining the change, for anyone else that's
> searching the list for the same problem:
>
> http://techtuxwords.blogspot.co.uk/2014/12/using-ftdisio-with-linux-kernel-312-and.html
>
> Hwyl,
> Roger
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

Re: [Ftdi-usb-sio-devel] Problem passing custom VID/PID to ftdi-sio

[Roger O. J. <ro...@pp...>]

On 20/05/2015 16:22, Roger O. Jones MIET wrote:
> We've used a custom `udev` rule on the Pi to pass the correct VID
> and  PID to the driver (as per the instructions in the "FTDI
> Technical Note  101" and the ftdi-sio webpage) and this worked
> previously on the Raspberry Pi Model B (raspbian with kernel
> 3.10.25+) but today I've  tried it on a Raspberry Pi A+ (raspbian with
> kernel 3.18.11+) but get  errors in `dmesg` from the `udev` rule and the
> device is not recognized.
> --8<----
> # dmesg | grep ftdi
> ftdi_sio: unknown parameter 'product' ignored
> ftdi_sio: unknown parameter 'vendor' ignored
> usbcore: registered new interface driver ftdi_sio
> ---->8--

OK, found that this is down to a change in the kernel 3.12 and later
that impacts on the way that custom VID and PID are sent to the driver.
We now need to load the driver and then add the new numbers to the
`/sys/bus/usb-serial/drivers/ftdi_sio/new_id` virtual file.

I've amended my `udev` rule and it seesm to work.

Here the link I found explaining the change, for anyone else that's
searching the list for the same problem:
http://techtuxwords.blogspot.co.uk/2014/12/using-ftdisio-with-linux-kernel-312-and.html

Hwyl,
Roger

[Ftdi-usb-sio-devel] Problem passing custom VID/PID to ftdi-sio

[Roger O. J. M. <ro...@pp...>]

Hi,

We have a product where we connect a monitoring device to a
Raspberry Pi  via USB. The device uses serial commands to pass data back
and forth and  uses an FTDI chip with custom VID and PID to do this.

We've used a custom `udev` rule on the Pi to pass the correct VID
and  PID to the driver (as per the instructions in the "FTDI
Technical Note  101" and the ftdi-sio webpage) and this worked
previously on the 
Raspberry Pi Model B (raspbian with kernel
3.10.25+) but today I've  tried it on a Raspberry Pi A+ (raspbian with
kernel 3.18.11+) but get  errors in `dmesg` from the `udev` rule and the
device is not recognized. --8<----
# dmesg | grep ftdi
ftdi_sio: unknown parameter 'product' ignored
ftdi_sio: unknown
parameter 'vendor' ignored
usbcore: registered new interface driver
ftdi_sio
---->8--

Working driver version is
"srcversion: 118C2FFAFBDC88DB1344F66" whilst I  get errors with
"srcversion: B86D6B2E065168765812137".

Am I missing
something here? Have the parameter names changed perhaps?

Many
thanks,
Roger.






~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 PPM Technology Ltd.,                  | W = http://www.ppm-technology.com     
 Cibyn Industrial Estate,              | T = +44 (0)1286 676 999               
 Caernarfon. LL55 2BD.                 | F = +44 (0)1286 671 811               
 Wales/UK                              |                                       
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     Registered in Wales : 3743347     |      VAT Number : GB 713 750 842      
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 PPM Technology Ltd. reserves the right to monitor  all  e-mail communications 
 through its networks and servers.    All  orders arising  from a quotation or 
 prices   given by  PPM Technology Ltd.  in  or  with  this message (including 
 amendments and  variations  to existing  orders)  will  be   subject to   the 
 Conditions of Sale of PPM Technology Ltd.                                     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[Brett W. <wh...@ec...>]

Great suggestions. I am thinking that it is hardware at this point. I have removed the PI from the cabinet, and now that it is away from the other electronic devices, it is working correctly. I will continue to test. 
Thanks to all that have offered help and suggestions. 

Kind Regards, 

Brett Whittacre 
Vice President 
wh...@ec... 
ec 2 Software Solutions 
3035 E. Patrick 
Ste. 1 
Las Vegas, Nevada, 89120 
P : 1.866.791.3673 ext 200 | F: 1.702.947.7357 
www.ec2software.com 
Follow the rules. Exceed the standard . 

----- On Apr 10, 2015, at 9:13 AM, H McCurdy <hmc...@ya...> wrote: 

> My suggestion is to approach it as a hardware problem, if you haven't already.

> Does the USB->Serial adapter function properly on another Linux box? (Perhaps
> you did that and I missed where you said it.) If possible, did you try a
> different USB->Serial adapter? (Serial UARTS do fail, I've dealt with
> hundreds.)

> Is the garbage character always the same? If your software simply "eats" the
> first character, does it work OK after that? (If so, could be line noise. You
> wouldn't be the only person this ever happened to. I've seen code for embedded
> devices (M68K series microprocessors) that routinely clear unexpected
> characters from the incoming buffer.

> These are just suggestions. Hope they help.

> Hugh

> On Thursday, April 9, 2015 8:52 PM, Bill Ryder <bil...@gm...> wrote:

> Nope - that is pretty strange.

> Can you strace your program on a Pi? We can start by looking at what the system
> calls are returning.

> Alternatively you can load the driver in debug mode and a LOT more detail will
> be dumped in the buffer dmesg uses.

> But ideally start with strace to at least make sure it's the kernel sending you
> that data.

> On Fri, Apr 10, 2015 at 2:22 AM, Brett Whittacre < wh...@ec... > wrote:

>> Here is the Dmseg information about it. I looks to be the right driver to me.
>> Any other ideas of what it might be?

>> [ 3.822917] usbserial: USB Serial support registered for generic
>> [ 3.842095] usbcore: registered new interface driver ftdi_sio
>> [ 3.849420] usbserial: USB Serial support registered for FTDI USB Serial Device
>> [ 3.855792] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
>> [ 3.862030] usb 1-1.2: Detected FT232RL
>> [ 3.868149] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
>> [ 5.496995] random: nonblocking pool is initialized

>> Kind Regards,

>> Brett Whittacre
>> Vice President
>> wh...@ec...
>> ec 2 Software Solutions
>> 3035 E. Patrick
>> Ste. 1
>> Las Vegas, Nevada, 89120
>> P : 1.866.791.3673 ext 200 | F: 1.702.947.7357
>> www.ec2software.com
>> Follow the rules. Exceed the standard .

>> ----- On Apr 8, 2015, at 5:08 PM, Bill Ryder < bil...@gm... > wrote:

>>> At a guess the Pi isn't loading the right driver.

>>> Do you have the output from dmesg when the FTDI is plugged in?

>>> It should say something about a ftdi_sio device being attached.

>>> On Thu, Apr 9, 2015 at 9:40 AM, Brett Whittacre < wh...@ec... > wrote:

>>>> I am having a very strange issue with serial communication through a fdti FT232
>>>> device. I have created a serial program that communicated with a device. It is
>>>> set to blocking mode. When I run the program on a PC, it works just fine.
>>>> However, when I run the same program on a Raspberry pi 2, it always returns at
>>>> least one character, even though there is nothing on the line at that time. The
>>>> code below works on Ubuntu 14.04 with no issues. I get full blocking using
>>>> either a read of select call.

>>>> I am just wondering if I am doing something wrong on the PI....

>>>> Here is how I am connecting to the port.'

>>>> fd=open(sDev.c_str(), O_RDWR | O_NOCTTY );

>>>> struct termios options;
>>>> tcgetattr(fd, &options);

>>>> cfsetispeed(&options, B115200);
>>>> cfsetospeed(&options, B115200);
>>>> options.c_cflag |= (CLOCAL | CREAD );
>>>> options.c_cflag &= ~CSTOPB; //Set one stop bit
>>>> options.c_cflag &= ~CRTSCTS; //
>>>> options.c_cflag &= ~CSIZE; //Mask the character size bits
>>>> options.c_cflag |= (ICANON);
>>>> options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control
>>>> options.c_cc[VTIME]=0;
>>>> options.c_cc[VMIN]=1;

>>>> tcsetattr(fd, TCSANOW, &options);
>>>> int flags;
>>>> //clear DTR and RTS
>>>> flags &= ~(TIOCM_DTR | TIOCM_RTS);
>>>> ioctl(fd, TIOCMSET, &flags);
>>>> usleep(200);

>>>> //SET DTR
>>>> flags |= TIOCM_DTR;
>>>> ioctl(fd, TIOCMSET, &flags);
>>>> usleep(200);

>>>> //clear DTR
>>>> flags &= ~(TIOCM_DTR);
>>>> ioctl(fd, TIOCMSET, &flags);
>>>> usleep(200);

>>>> Kind Regards,

>>>> Brett Whittacre
>>>> Vice President
>>>> wh...@ec...
>>>> ec 2 Software Solutions
>>>> 3035 E. Patrick
>>>> Ste. 1
>>>> Las Vegas, Nevada, 89120
>>>> P : 1.866.791.3673 ext 200 | F: 1.702.947.7357
>>>> www.ec2software.com
>>>> Follow the rules. Exceed the standard .

>>>> Kind Regards,

>>>> Brett Whittacre
>>>> Vice President
>>>> wh...@ec...
>>>> ec 2 Software Solutions
>>>> 3035 E. Patrick
>>>> Ste. 1
>>>> Las Vegas, Nevada, 89120
>>>> P : 1.866.791.3673 ext 200 | F: 1.702.947.7357
>>>> www.ec2software.com
>>>> Follow the rules. Exceed the standard .

>>>> ------------------------------------------------------------------------------
>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>>>> Develop your own process in accordance with the BPMN 2 standard
>>>> Learn Process modeling best practices with Bonita BPM through live exercises
>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>>>> _______________________________________________
>>>> Ftdi-usb-sio-devel mailing list
>>>> Ftd...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

Re: [Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[H M. <hmc...@ya...>]

My suggestion is to approach it as a hardware problem, if you haven't already.
Does the USB->Serial adapter function properly on another Linux box?  (Perhaps you did that and I missed where you said it.)  If possible, did you try a different USB->Serial adapter?  (Serial UARTS do fail, I've dealt with hundreds.)
Is the garbage character always the same?  If your software simply "eats" the first character, does it work OK after that?  (If so, could be line noise.  You wouldn't be the only person this ever happened to.  I've seen code for embedded devices (M68K series microprocessors) that routinely clear unexpected characters from the incoming buffer.
These are just suggestions.  Hope they help.
Hugh
 


     On Thursday, April 9, 2015 8:52 PM, Bill Ryder <bil...@gm...> wrote:
   

 Nope - that is pretty strange.

Can you strace your program on a Pi? We can start by looking at what the system calls are returning.

Alternatively you can load the driver in debug mode and a LOT more detail will be dumped in the buffer dmesg uses.


But ideally start with strace to at least make sure it's the kernel sending you that data.


On Fri, Apr 10, 2015 at 2:22 AM, Brett Whittacre <wh...@ec...> wrote:

Here is the Dmseg information about it.  I looks to be the right driver to me.  Any other ideas of what it might be?
[ 3.822917] usbserial: USB Serial support registered for generic
[ 3.842095] usbcore: registered new interface driver ftdi_sio
[ 3.849420] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3.855792] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 3.862030] usb 1-1.2: Detected FT232RL
[ 3.868149] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 5.496995] random: nonblocking pool is initialized

Kind Regards,

Brett WhittacreVice Pre...@ec...
ec2 Software Solutions3035 E. Patrick 
Ste. 1Las Vegas, Nevada, 89120P: 1.866.791.3673 ext 200 | F: 1.702.947.7357
www.ec2software.com
 Follow the rules.  Exceed the standard.

----- On Apr 8, 2015, at 5:08 PM, Bill Ryder <bil...@gm...> wrote:

At a guess the Pi isn't loading the right driver. 

Do you have the output from dmesg when the FTDI is plugged in?

It should say something about a ftdi_sio device being attached.



On Thu, Apr 9, 2015 at 9:40 AM, Brett Whittacre <wh...@ec...> wrote:

I am having a very strange issue with serial communication through a fdti FT232 device.  I have created a serial program that communicated with a device.  It is set to blocking mode.  When I run the program on a PC, it works just fine.  However, when I run the same program on a Raspberry pi 2, it always returns at least one character, even though there is nothing on the line at that time.  The code below works on Ubuntu 14.04 with no issues.  I get full blocking using either a read of select call.
I am just wondering if I am doing something wrong on the PI....
Here is how I am connecting to the port.'

fd=open(sDev.c_str(), O_RDWR | O_NOCTTY );
struct termios options;
tcgetattr(fd, &options);
cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);options.c_cflag |= (CLOCAL | CREAD );
options.c_cflag &= ~CSTOPB; //Set one stop bit
options.c_cflag &= ~CRTSCTS; //options.c_cflag &= ~CSIZE; //Mask the character size bitsoptions.c_cflag |= (ICANON);
options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control
options.c_cc[VTIME]=0;
options.c_cc[VMIN]=1;
tcsetattr(fd, TCSANOW, &options);
int flags;
//clear DTR and RTS
flags &= ~(TIOCM_DTR | TIOCM_RTS);ioctl(fd, TIOCMSET, &flags);usleep(200);
//SET DTR
flags |= TIOCM_DTR;ioctl(fd, TIOCMSET, &flags);usleep(200);
//clear DTRflags &= ~(TIOCM_DTR);ioctl(fd, TIOCMSET, &flags);usleep(200);




Kind Regards,

Brett WhittacreVice Pre...@ec...
ec2 Software Solutions3035 E. Patrick 
Ste. 1Las Vegas, Nevada, 89120P: 1.866.791.3673 ext 200 | F: 1.702.947.7357
www.ec2software.com
Follow the rules.  Exceed the standard.

Kind Regards,

Brett WhittacreVice Pre...@ec...
ec2 Software Solutions3035 E. Patrick 
Ste. 1Las Vegas, Nevada, 89120P: 1.866.791.3673 ext 200 | F: 1.702.947.7357
www.ec2software.com
 Follow the rules.  Exceed the standard.

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Ftdi-usb-sio-devel mailing list
Ftd...@li...
https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel







------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Ftdi-usb-sio-devel mailing list
Ftd...@li...
https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel


  

Re: [Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[Bill R. <bil...@gm...>]

Nope - that is pretty strange.

Can you strace your program on a Pi? We can start by looking at what the
system calls are returning.

Alternatively you can load the driver in debug mode and a LOT more detail
will be dumped in the buffer dmesg uses.


But ideally start with strace to at least make sure it's the kernel sending
you that data.


On Fri, Apr 10, 2015 at 2:22 AM, Brett Whittacre <wh...@ec...>
wrote:

> Here is the Dmseg information about it.  I looks to be the right driver to
> me.  Any other ideas of what it might be?
>
> [ 3.822917] usbserial: USB Serial support registered for generic
> [ 3.842095] usbcore: registered new interface driver ftdi_sio
> [ 3.849420] usbserial: USB Serial support registered for FTDI USB Serial
> Device
> [ 3.855792] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
> [ 3.862030] usb 1-1.2: Detected FT232RL
> [ 3.868149] usb 1-1.2: FTDI USB Serial Device converter now attached to
> ttyUSB0
> [ 5.496995] random: nonblocking pool is initialized
>
> Kind Regards,
>
> *Brett Whittacre*
> Vice President
> wh...@ec...
> *ec2 Software Solutions*
> 3035 E. Patrick
> Ste. 1
> Las Vegas, Nevada, 89120
> *P*: 1.866.791.3673 ext 200 | *F:* 1.702.947.7357
> <http://www.ec2software.com>www.ec2software.com
> <http://www.ec2software.com> *Follow the rules.* * Exceed the standard**.*
>
>
> ----- On Apr 8, 2015, at 5:08 PM, Bill Ryder <bil...@gm...>
> wrote:
>
> At a guess the Pi isn't loading the right driver.
>
> Do you have the output from dmesg when the FTDI is plugged in?
>
> It should say something about a ftdi_sio device being attached.
>
>
>
> On Thu, Apr 9, 2015 at 9:40 AM, Brett Whittacre <wh...@ec...>
> wrote:
>
>> I am having a very strange issue with serial communication through a fdti
>> FT232 device.  I have created a serial program that communicated with a
>> device.  It is set to blocking mode.  When I run the program on a PC, it
>> works just fine.  However, when I run the same program on a Raspberry pi 2,
>> it always returns at least one character, even though there is nothing on
>> the line at that time.  The code below works on Ubuntu 14.04 with no
>> issues.  I get full blocking using either a read of select call.
>>
>> I am just wondering if I am doing something wrong on the PI....
>>
>> Here is how I am connecting to the port.'
>>
>>
>> fd=open(sDev.c_str(), O_RDWR | O_NOCTTY );
>>
>>
>> struct termios options;
>>
>> tcgetattr(fd, &options);
>>
>>
>> cfsetispeed(&options, B115200);
>>
>> cfsetospeed(&options, B115200);
>>
>> options.c_cflag |= (CLOCAL | CREAD );
>>
>> options.c_cflag &= ~CSTOPB; //Set one stop bit
>>
>> options.c_cflag &= ~CRTSCTS; //
>>
>> options.c_cflag &= ~CSIZE; //Mask the character size bits
>>
>> options.c_cflag |= (ICANON);
>>
>> options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control
>>
>> options.c_cc[VTIME]=0;
>>
>> options.c_cc[VMIN]=1;
>>
>>
>> tcsetattr(fd, TCSANOW, &options);
>>
>> int flags;
>>
>> //clear DTR and RTS
>>
>> flags &= ~(TIOCM_DTR | TIOCM_RTS);
>>
>> ioctl(fd, TIOCMSET, &flags);
>>
>> usleep(200);
>>
>>
>> //SET DTR
>>
>> flags |= TIOCM_DTR;
>>
>> ioctl(fd, TIOCMSET, &flags);
>>
>> usleep(200);
>>
>>
>> //clear DTR
>>
>> flags &= ~(TIOCM_DTR);
>>
>> ioctl(fd, TIOCMSET, &flags);
>>
>> usleep(200);
>>
>>
>>
>>
>>
>>
>> Kind Regards,
>>
>> *Brett Whittacre*
>> Vice President
>> wh...@ec...
>> *ec2 Software Solutions*
>> 3035 E. Patrick
>> Ste. 1
>> Las Vegas, Nevada, 89120
>> *P*: 1.866.791.3673 ext 200 | *F:* 1.702.947.7357
>> <http://www.ec2software.com/>www.ec2software.com
>> <http://www.ec2software.com/>*Follow the rules.* * Exceed the standard*
>> *.*
>>
>>
>> Kind Regards,
>>
>> *Brett Whittacre*
>> Vice President
>> wh...@ec...
>> *ec2 Software Solutions*
>> 3035 E. Patrick
>> Ste. 1
>> Las Vegas, Nevada, 89120
>> *P*: 1.866.791.3673 ext 200 | *F:* 1.702.947.7357
>> <http://www.ec2software.com>www.ec2software.com
>> <http://www.ec2software.com> *Follow the rules.* * Exceed the standard*
>> *.*
>>
>>
>>
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live
>> exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
>> event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>>
>>
>

Re: [Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[Brett W. <wh...@ec...>]

Here is the Dmseg information about it. I looks to be the right driver to me. Any other ideas of what it might be? 

[ 3.822917] usbserial: USB Serial support registered for generic 
[ 3.842095] usbcore: registered new interface driver ftdi_sio 
[ 3.849420] usbserial: USB Serial support registered for FTDI USB Serial Device 
[ 3.855792] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected 
[ 3.862030] usb 1-1.2: Detected FT232RL 
[ 3.868149] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0 
[ 5.496995] random: nonblocking pool is initialized 

Kind Regards, 

Brett Whittacre 
Vice President 
wh...@ec... 
ec 2 Software Solutions 
3035 E. Patrick 
Ste. 1 
Las Vegas, Nevada, 89120 
P : 1.866.791.3673 ext 200 | F: 1.702.947.7357 
www.ec2software.com 
Follow the rules. Exceed the standard . 

----- On Apr 8, 2015, at 5:08 PM, Bill Ryder <bil...@gm...> wrote: 

> At a guess the Pi isn't loading the right driver.

> Do you have the output from dmesg when the FTDI is plugged in?

> It should say something about a ftdi_sio device being attached.

> On Thu, Apr 9, 2015 at 9:40 AM, Brett Whittacre < wh...@ec... > wrote:

>> I am having a very strange issue with serial communication through a fdti FT232
>> device. I have created a serial program that communicated with a device. It is
>> set to blocking mode. When I run the program on a PC, it works just fine.
>> However, when I run the same program on a Raspberry pi 2, it always returns at
>> least one character, even though there is nothing on the line at that time. The
>> code below works on Ubuntu 14.04 with no issues. I get full blocking using
>> either a read of select call.

>> I am just wondering if I am doing something wrong on the PI....

>> Here is how I am connecting to the port.'

>> fd=open(sDev.c_str(), O_RDWR | O_NOCTTY );

>> struct termios options;

>> tcgetattr(fd, &options);

>> cfsetispeed(&options, B115200);

>> cfsetospeed(&options, B115200);

>> options.c_cflag |= (CLOCAL | CREAD );

>> options.c_cflag &= ~CSTOPB; //Set one stop bit

>> options.c_cflag &= ~CRTSCTS; //

>> options.c_cflag &= ~CSIZE; //Mask the character size bits

>> options.c_cflag |= (ICANON);

>> options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control

>> options.c_cc[VTIME]=0;

>> options.c_cc[VMIN]=1;

>> tcsetattr(fd, TCSANOW, &options);

>> int flags;

>> //clear DTR and RTS

>> flags &= ~(TIOCM_DTR | TIOCM_RTS);

>> ioctl(fd, TIOCMSET, &flags);

>> usleep(200);

>> //SET DTR

>> flags |= TIOCM_DTR;

>> ioctl(fd, TIOCMSET, &flags);

>> usleep(200);

>> //clear DTR

>> flags &= ~(TIOCM_DTR);

>> ioctl(fd, TIOCMSET, &flags);

>> usleep(200);

>> Kind Regards,

>> Brett Whittacre
>> Vice President
>> wh...@ec...
>> ec 2 Software Solutions
>> 3035 E. Patrick
>> Ste. 1
>> Las Vegas, Nevada, 89120
>> P : 1.866.791.3673 ext 200 | F: 1.702.947.7357
>> www.ec2software.com
>> Follow the rules. Exceed the standard .

>> Kind Regards,

>> Brett Whittacre
>> Vice President
>> wh...@ec...
>> ec 2 Software Solutions
>> 3035 E. Patrick
>> Ste. 1
>> Las Vegas, Nevada, 89120
>> P : 1.866.791.3673 ext 200 | F: 1.702.947.7357
>> www.ec2software.com
>> Follow the rules. Exceed the standard .

>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

Re: [Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[Bill R. <bil...@gm...>]

At a guess the Pi isn't loading the right driver.

Do you have the output from dmesg when the FTDI is plugged in?

It should say something about a ftdi_sio device being attached.



On Thu, Apr 9, 2015 at 9:40 AM, Brett Whittacre <wh...@ec...>
wrote:

> I am having a very strange issue with serial communication through a fdti
> FT232 device.  I have created a serial program that communicated with a
> device.  It is set to blocking mode.  When I run the program on a PC, it
> works just fine.  However, when I run the same program on a Raspberry pi 2,
> it always returns at least one character, even though there is nothing on
> the line at that time.  The code below works on Ubuntu 14.04 with no
> issues.  I get full blocking using either a read of select call.
>
> I am just wondering if I am doing something wrong on the PI....
>
> Here is how I am connecting to the port.'
>
>
> fd=open(sDev.c_str(), O_RDWR | O_NOCTTY );
>
>
> struct termios options;
>
> tcgetattr(fd, &options);
>
>
> cfsetispeed(&options, B115200);
>
> cfsetospeed(&options, B115200);
>
> options.c_cflag |= (CLOCAL | CREAD );
>
> options.c_cflag &= ~CSTOPB; //Set one stop bit
>
> options.c_cflag &= ~CRTSCTS; //
>
> options.c_cflag &= ~CSIZE; //Mask the character size bits
>
> options.c_cflag |= (ICANON);
>
> options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control
>
> options.c_cc[VTIME]=0;
>
> options.c_cc[VMIN]=1;
>
>
> tcsetattr(fd, TCSANOW, &options);
>
> int flags;
>
> //clear DTR and RTS
>
> flags &= ~(TIOCM_DTR | TIOCM_RTS);
>
> ioctl(fd, TIOCMSET, &flags);
>
> usleep(200);
>
>
> //SET DTR
>
> flags |= TIOCM_DTR;
>
> ioctl(fd, TIOCMSET, &flags);
>
> usleep(200);
>
>
> //clear DTR
>
> flags &= ~(TIOCM_DTR);
>
> ioctl(fd, TIOCMSET, &flags);
>
> usleep(200);
>
>
>
>
>
>
> Kind Regards,
>
> *Brett Whittacre*
> Vice President
> wh...@ec...
> *ec2 Software Solutions*
> 3035 E. Patrick
> Ste. 1
> Las Vegas, Nevada, 89120
> *P*: 1.866.791.3673 ext 200 | *F:* 1.702.947.7357
> <http://www.ec2software.com/>www.ec2software.com
> <http://www.ec2software.com/>*Follow the rules.* * Exceed the standard**.*
>
>
> Kind Regards,
>
> *Brett Whittacre*
> Vice President
> wh...@ec...
> *ec2 Software Solutions*
> 3035 E. Patrick
> Ste. 1
> Las Vegas, Nevada, 89120
> *P*: 1.866.791.3673 ext 200 | *F:* 1.702.947.7357
> <http://www.ec2software.com>www.ec2software.com
> <http://www.ec2software.com> *Follow the rules.* * Exceed the standard**.*
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

[Ftdi-usb-sio-devel] Raspberry Pi FDTI Driver issue

[Brett W. <wh...@ec...>]

I am having a very strange issue with serial communication through a fdti FT232 device. I have created a serial program that communicated with a device. It is set to blocking mode. When I run the program on a PC, it works just fine. However, when I run the same program on a Raspberry pi 2, it always returns at least one character, even though there is nothing on the line at that time. The code below works on Ubuntu 14.04 with no issues. I get full blocking using either a read of select call. 

I am just wondering if I am doing something wrong on the PI.... 

Here is how I am connecting to the port.' 




fd=open(sDev.c_str(), O_RDWR | O_NOCTTY ); 




struct termios options; 


tcgetattr(fd, &options); 




cfsetispeed(&options, B115200); 


cfsetospeed(&options, B115200); 

options.c_cflag |= (CLOCAL | CREAD ); 


options.c_cflag &= ~CSTOPB; //Set one stop bit 


options.c_cflag &= ~CRTSCTS; // 

options.c_cflag &= ~CSIZE; //Mask the character size bits 

options.c_cflag |= (ICANON); 


options.c_cflag &= ~(IXON| IXOFF |IXANY); //No software flow control 


options.c_cc[VTIME]=0; 


options.c_cc[VMIN]=1; 




tcsetattr(fd, TCSANOW, &options); 


int flags; 


//clear DTR and RTS 


flags &= ~(TIOCM_DTR | TIOCM_RTS); 

ioctl(fd, TIOCMSET, &flags); 

usleep(200); 




//SET DTR 


flags |= TIOCM_DTR; 

ioctl(fd, TIOCMSET, &flags); 

usleep(200); 




//clear DTR 

flags &= ~(TIOCM_DTR); 

ioctl(fd, TIOCMSET, &flags); 

usleep(200); 
















Kind Regards, 

Brett Whittacre 
Vice President 
wh...@ec... 
ec 2 Software Solutions 
3035 E. Patrick 
Ste. 1 
Las Vegas, Nevada, 89120 
P : 1.866.791.3673 ext 200 | F: 1.702.947.7357 
www.ec2software.com 
Follow the rules. Exceed the standard . 


Kind Regards, 

Brett Whittacre 
Vice President 
wh...@ec... 
ec 2 Software Solutions 
3035 E. Patrick 
Ste. 1 
Las Vegas, Nevada, 89120 
P : 1.866.791.3673 ext 200 | F: 1.702.947.7357 
www.ec2software.com 
Follow the rules. Exceed the standard . 

Re: [Ftdi-usb-sio-devel] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity

[<jen...@we...>]

Hi Bill,

Am 23.12.2014 um 22:59 schrieb Bill Ryder:
> Hi there,
>
> It looks like that device is not compatible with ftdi_sio
>
> When you are searching for this kind of problem you should look for:
>
> usb vid 1a86 pid 7523
>
> The vendor id (vid) and product id (pid) are the keys to figuring out what drive you need.
>
>
> Look at this;
>
> http://ubuntuforums.org/showthread.php?t=921409
>
>
> According to that ubuntu link it's a ch341 device so you want a driver for that.

Really.
I was so fixated to ftdi_sio (can anybody tell me, why?), that I did not see, there is special driver for this chip.
Now i build the ch431 module an it loaded perfectly. The communication works fine.

Thank you and Merry Christmas!

Re: [Ftdi-usb-sio-devel] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity

[Bill R. <bil...@gm...>]

Hi there,

It looks like that device is not compatible with ftdi_sio

When you are searching for this kind of problem you should look for:

usb vid 1a86 pid 7523

The vendor id (vid) and product id (pid) are the keys to figuring out what
drive you need.


Look at this;

http://ubuntuforums.org/showthread.php?t=921409


According to that ubuntu link it's a ch341 device so you want a driver for
that.

---
Bill


On Wed, Dec 24, 2014 at 3:13 AM, <jen...@we...> wrote:

> Hallo,
>
> I want to programm an "Arduino Nano" from a Thinkpad T420 running Gentoo
> Linux (Kernel: 3.16.5-gentoon und ftdi & co build as  modul, 64bit)
>
>
> This happens
>
> * Arduino plugged:
> [ 184.188033] usb 2-1.1: new full-speed USB device number 4 using ehci-pci
> [ 184.274623] usb 2-1.1: New USB device found, idVendor=1a86,
> idProduct=7523
> [ 184.274636] usb 2-1.1: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [ 184.274643] usb 2-1.1: Product: USB2.0-Serial
> => OK
>
> * modprobe ftdi-sio:
> [ 245.363725] usbcore: registered new interface driver usbserial
> [ 245.363785] usbcore: registered new interface driver usbserial_generic
> [ 245.363839] usbserial: USB Serial support registered for generic
> [ 245.366834] usbcore: registered new interface driver ftdi_sio
> [ 245.366872] usbserial: USB Serial support registered for FTDI USB Serial
> Device
> => OK
>
> * it does not recognize the device, so it needs a little help:
> * echo 1a86 7523 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
> [ 259.876146] ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
> [ 259.876300] usb 2-1.1: Detected FT8U232AM
> [ 259.876310] usb 2-1.1: Number of endpoints 3
> [ 259.876319] usb 2-1.1: Endpoint 1 MaxPacketSize 32
> [ 259.876328] usb 2-1.1: Endpoint 2 MaxPacketSize 32
> [ 259.876336] usb 2-1.1: Endpoint 3 MaxPacketSize 8
> [ 259.876344] usb 2-1.1: Setting MaxPacketSize 8
> [ 259.876531] ftdi_sio ttyUSB0: Unable to read latency timer: -32
> [ 259.876906] ftdi_sio ttyUSB0: Unable to write latency timer: -32
> [ 259.877099] usb 2-1.1: FTDI USB Serial Device converter now attached to
> ttyUSB0
> => OK
>
> * via "arduino"-IDE (last Beta 1.5.8 binary from arduino.cc)
> * Preferences: Board: Arduini Nano, Programmer: avrisp mkII, Port:
> /dev/ttyUSB0
> * load any example-programm to the board:
> [ 324.258430] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set
> databits/stopbits/parity
> [ 324.258769] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
> [ 324.259146] ftdi_sio ttyUSB0: urb failed to clear flow control
> [ 324.259891] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
> [ 324.260278] ftdi_sio ttyUSB0: urb failed to clear flow control
> [ 324.260645] ftdi_sio ttyUSB0: failed to get modem status: -32
> [ 324.511185] ftdi_sio ttyUSB0: failed to get modem status: -32
> [...]
> => NOT OK
> I can see the RX-led on the Arduino-board flashing - some informations
> seem to
> be sent to the device.
>
>
> On a Ubuntu 12.04 machine it all works without any problems - I can
> upload programs to the Arduino - so the hardware of the Arduino is ok.
>
> I could not find some helpful info at Google. Only the hint to press the
> reset-button on the board immetially before upload. But it does not help.
>
>
> Is there anybody who can give me a hint?
> Is it a Gentoo related problem?
> How can I check health of the tty USB0-device?
>
>
> whit helpless regards
>
> Jens
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

[Ftdi-usb-sio-devel] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity

[<jen...@we...>]

Hallo,

I want to programm an "Arduino Nano" from a Thinkpad T420 running Gentoo
Linux (Kernel: 3.16.5-gentoon und ftdi & co build as  modul, 64bit)


This happens

* Arduino plugged:
[ 184.188033] usb 2-1.1: new full-speed USB device number 4 using ehci-pci
[ 184.274623] usb 2-1.1: New USB device found, idVendor=1a86, idProduct=7523
[ 184.274636] usb 2-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 184.274643] usb 2-1.1: Product: USB2.0-Serial
=> OK

* modprobe ftdi-sio:
[ 245.363725] usbcore: registered new interface driver usbserial
[ 245.363785] usbcore: registered new interface driver usbserial_generic
[ 245.363839] usbserial: USB Serial support registered for generic
[ 245.366834] usbcore: registered new interface driver ftdi_sio
[ 245.366872] usbserial: USB Serial support registered for FTDI USB Serial Device
=> OK

* it does not recognize the device, so it needs a little help:
* echo 1a86 7523 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
[ 259.876146] ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
[ 259.876300] usb 2-1.1: Detected FT8U232AM
[ 259.876310] usb 2-1.1: Number of endpoints 3
[ 259.876319] usb 2-1.1: Endpoint 1 MaxPacketSize 32
[ 259.876328] usb 2-1.1: Endpoint 2 MaxPacketSize 32
[ 259.876336] usb 2-1.1: Endpoint 3 MaxPacketSize 8
[ 259.876344] usb 2-1.1: Setting MaxPacketSize 8
[ 259.876531] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[ 259.876906] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[ 259.877099] usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
=> OK

* via "arduino"-IDE (last Beta 1.5.8 binary from arduino.cc)
* Preferences: Board: Arduini Nano, Programmer: avrisp mkII, Port: /dev/ttyUSB0
* load any example-programm to the board:
[ 324.258430] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[ 324.258769] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[ 324.259146] ftdi_sio ttyUSB0: urb failed to clear flow control
[ 324.259891] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[ 324.260278] ftdi_sio ttyUSB0: urb failed to clear flow control
[ 324.260645] ftdi_sio ttyUSB0: failed to get modem status: -32
[ 324.511185] ftdi_sio ttyUSB0: failed to get modem status: -32
[...]
=> NOT OK
I can see the RX-led on the Arduino-board flashing - some informations seem to
be sent to the device.


On a Ubuntu 12.04 machine it all works without any problems - I can
upload programs to the Arduino - so the hardware of the Arduino is ok.

I could not find some helpful info at Google. Only the hint to press the
reset-button on the board immetially before upload. But it does not help.


Is there anybody who can give me a hint?
Is it a Gentoo related problem?
How can I check health of the tty USB0-device?


whit helpless regards

Jens

Re: [Ftdi-usb-sio-devel] [SOLVED] Baudrate setting is broken.

[Teunis v. B. <te...@gm...>]

>> You should remove the baudr from your c_cflag setting also because you
>> might be settings things you don't want to accidentally.

Thanks Bill, I'll do that.
Much appreciated.

Best Regards

Teunis van Beelen



On Tue, Sep 30, 2014 at 7:02 AM, Bill Ryder <bil...@gm...> wrote:
> Hi there,
>
> The c_cflag settings don't set the baud rate.
>
> They set other communications modes like stop bits, parity etc.
>
> So you can't set the baudrate in c_cflag.
>
> You've solved the problem yourself by calling the speed setting functions.
>
> You should remove the baudr from your c_cflag setting also because you
> might be settings things you don't want to accidentally.
>
>
>
> Here's the posix documentation
>
> http://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html
>
> and the linux documentation
>
> http://man7.org/linux/man-pages/man3/termios.3.html
>
>
> Enjoy serial programming!
>
> Bill
>
>
> On Tue, Sep 30, 2014 at 4:58 AM, Teunis van Beelen <te...@gm...> wrote:
>> Dear maintainers,
>>
>> It looks like I solved the problem.
>>
>> I was using this code to set the params for the serial port:
>>
>>   new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;
>>   new_port_settings.c_iflag = IGNPAR;
>>   new_port_settings.c_oflag = 0;
>>   new_port_settings.c_lflag = 0;
>>   new_port_settings.c_cc[VMIN] = 0;      /* block untill n bytes are received */
>>   new_port_settings.c_cc[VTIME] = 0;     /* block untill a timer
>> expires (n * 100 mSec.) */
>>   cfsetispeed(&new_port_settings, baudr);
>>   cfsetospeed(&new_port_settings, baudr);
>>   error = tcsetattr(Cport[comport_number], TCSANOW, &new_port_settings);
>>
>> After adding the next two lines to my sourcecode, it works fine:
>>
>> cfsetispeed(&new_port_settings, baudr);
>> cfsetospeed(&new_port_settings, baudr);
>>
>> So, this means that setting the baudrate with:
>>
>> new_port_settings.c_cflag = baudr | cbits | cpar | bstop | CLOCAL | CREAD;
>>
>> is not sufficient??
>>
>> (baudr is an int that contains the value B9600 or B19200, etc.)
>>
>> Sorry for bothering,
>>
>> Best Regards,
>>
>> Teunis van Beelen
>>
>>
>> --
>> "C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel



-- 
"C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"