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

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

--- On Tue, 11/16/10, Michael Plante <mic...@gm...> wrote:
> Again, I would suggest that you consider using a non-blocking form,
> and schedule multiple read requests.
> 
> http://developer.intra2net.com/git/?p=libftdi-1.0
> 
> Consider ftdi_read_data_submit,
> ftdi_transfer_data_done, etc.

Hello again Michael,

FYI:  I took your suggestion and tried libftdi-1.0 asynchronous calls.  My "ping pong rate" improved slightly from the synchronous calls (as you predicted), but they still are not near the ftdi_sio rates:

1. libftdi-0.1, sync read, single thread: ~300Hz

2. libftdi-0.1, sync read, reads on separate thread in an infinite loop: ~300Hz

3. libftdi-1.0, async read (as you recommended): ~500Hz

4. ftdi_sio, sync read, single thread: ~1000Hz

5. ftdi_sio, sync read, reads on separate thread in an infinite loop: ~1000Hz

Note: Operations 4 and 5 run at 1000Hz most of the time, but experience a second or two of ~500Hz rates every 10 seconds or so.

Thank you all for your help,

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

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

Chris Stankevitz wrote:
>> I suspect the reason for the difference in performance is due to the
>> fact that my use of ftdi_sio involves non-blocking, CPU gobbling read
>> operations from within a while loop while libftdi appears to use some
>> kind of CPU-friendly blocking read.

Again, I would suggest that you consider using a non-blocking form, and
schedule multiple read requests.  To do this, you will need to download
version 1.0, which is currently only in git:

http://developer.intra2net.com/git/?p=libftdi-1.0

The idea is that the kernel needs to have a read request already ready to go
when the time comes for the next frame.  There is a separate mailing list
for this, and there may be people with more insight there if you want to
pursue it.  Consider ftdi_read_data_submit, ftdi_transfer_data_done, etc.  I
assume you are making your assessment of which frame a packet is in using
your sniffer, rather than when your application sees it, but, when you get
to that point, there may be a few more things you need to do to make sure it
gets to you quickly.

Michael

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

--- On Thu, 11/11/10, Michael Plante <mic...@gm...> wrote:
> I'd be surprised if there's anything the FTDI hardware can
> accomplish with
> ftdi-usb-sio, but not with libftdi.

Michael,

My application sends a 2 byte message to a device and receiving a 62 byte response ("ping pong") as fast as possible.

Most of the time ftdi_sio can process the "ping pong" within one full speed 1ms USB frame.

The libftdi library, on average, takes three ms per "ping pong".

I suspect the reason for the difference in performance is due to the fact that my use of ftdi_sio involves non-blocking, CPU gobbling read operations from within a while loop while libftdi appears to use some kind of CPU-friendly blocking read.

Source attached for those interested.

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

From: Bill Ryder <bil...@gm...>
BR> CS> My goal is to get a message to the FT245RL and
BR> CS> back to the host within each 1ms full speed frame.
BR> 
BR> I see. That will be quite tricky I suspect.

Using a Beagle USB 480 (and the output of the ftdi_sio driver debug log), I confirmed that I am able to do this most of the time.

The Beagle USB 480 is a device that sits inline on a USB cable and records the traffic.  This screenshot was made with traffic from the application whose source I posted a couple days ago:

http://img709.imageshack.us/img709/6199/outinsingleframe.png

Note that each frame (identified by "SOF") contains:
1. the OUT request for data (0x87 0x3E)
2. The IN reply (62 byte data, 2 byte FTDI status)
3. An additional IN FTDI status (0x31 0x60)

Although this screenshot does not show it, some frames even contain two of these "ping pong" messages.  However, they are always followed by a frame containing only (0x31 0x60) limiting my "ping pong rate" to 1000 Hz.

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

> From: Michael Plante <mic...@gm...>
>
> I'd be surprised if there's anything the FTDI hardware can
> accomplish with ftdi-usb-sio, but not with libftdi.

Michael,

To get the best results with POSIX sockets, I call a non-blocking read from inside a while loop with c_cc[VMIN]=0.  It gobbles a lot of CPU but is the only way I found to get the low latency "send and receive bulk data on the same USB frame".  I will check if libftdi replicates my low latency POSIX results and report back to the list.

Another idea I had and will try is to start an asynch read before I write the request.

Thank you,

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

BR> CS> My goal is to get a message to the FT245RL and back to the host
BR> CS> within each 1ms full speed frame.
BR>
BR> I see. That will be quite tricky I suspect.

About half the time I can do it... at least according to my interpretation of the following:

I have an FPGA device that uses FT245RL part.  It waits for a 2 byte "request" and ~immediately replies with a 62 byte message.  62 bytes was chosen because, once the 2 bytes of USB status message is appended, will fill up the outgoing FTDI buffer and not need to await a latency timer event.

I want to maximize the "ping pong rate" -- the rate at which I can send a request and get a response to one request and one reply per 1ms USB full speed frame (the part runs at full speed).  Here is pseudocode for a program I wrote to measure this rate (source attached):

fd = Open("ftdi_sio device");

set_serial_parms();

while (true)
{
  // busyloop calling write() until all data written
  write(fd, "two byte packet requesting 62 bytes");

  // busyloop calling read() until 62 read
  read(fd, "62 bytes");
}

Results:

The "ping pong rate" is 1000Hz for a few seconds, implying a reply and response within a 1ms frame.  The rate then switches to 300-700Hz for a few seconds, then back to 1000Hz.

source code: attached

program output:
1000.370137
1000.050003
1000.050003
1000.050003
1000.050003
1000.040002
980.430605
900.941484
613.549630
499.990000
393.720938
335.562587
645.177940
1000.030001
1000.060004
1000.030001
1000.040002
1000.050003
1000.040002

ftdi_sio debug output: attached.  It implies that when things are running at 1KHz I am sending the OUT and receiving the IN message in one frame.  When things are not running at 1KHz, it appears the IN message comes in on the subsequent frame.

I have a Beagle USB 480 which I am going to use to try to figure out exactly what is going on. http://www.totalphase.com/products/beagle_usb480/

My next idea is to start an asynchronous read before sending the write.

Your thoughts are appreciated!

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

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

On Fri, Nov 12, 2010 at 8:34 AM, Chris Stankevitz <chr...@ya...
> wrote:

>
> Is it possible for a userland program that is communicating with FTDI using
> open/close/ioctl/tcsetattr type calls to issue an FTDI reset or purge?
>
>
When the port is opened the driver issues a FTDI_SIO_RESET but it doesn't
purge it

You'd have to change the driver (the ftdi_open function in
drivers/usb/serial/ftdi_sio.c) and sent it three resets. The two purges and
the normal one.



> My application does not use libftdi (currently).  I am trying to get low
> latency comms with an FT245RL (only full speed) and I suspected libftdi
> wasn't up to the task (but that was when I knew relatively little about this
> process.  I should try again).  My goal is to get a message to the FT245RL
> and back to the host within each 1ms full speed frame.
>

I see. That will be quite tricky I suspect.

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

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

Chris Stankevitz wrote:
>> I suspected libftdi wasn't up to the task (but that was when I knew
relatively little
>> about this process.  I should try again).

I'd be surprised if there's anything the FTDI hardware can accomplish with
ftdi-usb-sio, but not with libftdi.  The kernel driver is for convenience,
as I understand it.  And when it does what you need, it's very convenient,
but I think its scope is limited (as it should be).

Now, in the realm of functionality common to both, for all I know, maybe one
piece of software has a bug the other doesn't and vice-versa, if that's what
you're saying...

Regards,
Michael

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

Bill Ryder <bil...@gm...> wrote:
> Have a look here:
> http://ftdi-usb-sio.sourceforge.net/#sec4
> which refers you to:
> http://www.intra2net.com/en/developer/libftdi/links.php.

Thank you.  I should have been more clear in my request:

Is it possible for a userland program that is communicating with FTDI using open/close/ioctl/tcsetattr type calls to issue an FTDI reset or purge?

My application does not use libftdi (currently).  I am trying to get low latency comms with an FT245RL (only full speed) and I suspected libftdi wasn't up to the task (but that was when I knew relatively little about this process.  I should try again).  My goal is to get a message to the FT245RL and back to the host within each 1ms full speed frame.

Thank you,

Chris


      

Re: [Ftdi-usb-sio-devel] Resetting the FTDI

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

Have a look here:

http://ftdi-usb-sio.sourceforge.net/#sec4

which refers you to:


http://www.intra2net.com/en/developer/libftdi/links.php.

That API has a way to issue a reset

[Ftdi-usb-sio-devel] Resetting the FTDI

[Chris S. <chr...@ya...>]

Hello,

How does my userland application issue an FTDI reset command?  ftdi_sio.h hints that it is possible:

 /* FTDI_SIO_RESET */
 #define FTDI_SIO_RESET_REQUEST FTDI_SIO_RESET
 #define FTDI_SIO_RESET_REQUEST_TYPE 0x40
 #define FTDI_SIO_RESET_SIO 0
 #define FTDI_SIO_RESET_PURGE_RX 1
 #define FTDI_SIO_RESET_PURGE_TX 2

Perhaps a better question: Where would I look to find the answer to this myself?  I assume the method involves ioctl() or sysfs, but I am not sure where in the source to find out the method.  If you can just refer me to a source to learn about this sort of thing, I'd be happy to RTFM.

Thank you,

Chris


      

[Ftdi-usb-sio-devel] FTDI one-way device issue

[Orjan F. <of...@fl...>]

Hi,

I came across this LKML/linux-usb post regarding FTDI flow control: 
http://marc.info/?l=linux-usb&m=127581718124328&w=2.

I'm facing a very similar situation (one way device, the data transfer 
stops but can be woken up by writing a character on the port (which I 
know the device ignores)).

Was there a off-list resolution to this?

I noticed there was some recent activity regarding FTDI and flow 
control, but the revert suggested here doesn't do it for me: 
http://marc.info/?l=linux-usb&m=128283105213206&w=2

Thanks,
Orjan


(I wasn't subscribed to LKML at the time and so couldn't reply to the 
original mail.  Also, I tried sending this in private to Ruud Linders 
but his e-mail address doesn't seem to work anymore.)

-- 
Orjan Friberg
FlatFrog Laboratories AB

[Ftdi-usb-sio-devel] New Vendor/Product ids

[Alexey K. <ale...@gm...>]

Hello!

Not sure if it is aright place to request IDs addition :)


But please add the following IDs to the driver:

Money Controls PayLink interface
http://www.moneycontrols.com/en/products/view/28/PayLink+USB+Integration+Module

Current module control program is based on libftdi binary,
which requires /proc/usb (not available in modern distros)

#define FTDI_MONEYCONTROLS_PAYLINK_PID	0XDE50	/* MoneyControls PayLink */



NEURON Japan MSA790U Bank Card Reader
Built-in ftdi serial-usb converter
http://www.neuron.co.jp/Neuron-USA/MotorizedHybrid/MotorizedHybrid.html

#define NEURON_VID		0x0804	/* NEURON Japan Inc */
#define NEURON_MSA790U_PID	0x0008	/* NEURON MSA790U Bank Card Reader */

[Ftdi-usb-sio-devel] Regarding power driving capability(FT232RL)

[Kiran P <kir...@gm...>]

Hi All,

Myself doing a project on serial to USB conversion using FT232RL IC...

I have connected my RF module on one end and the other end has a USB
connector which is connected to PC USB port.

Used the Bus powered configuration given in the FT232R data sheet section
6.0

Initially at power up, inrush current to my module is nearly 250mA , so this
makes my module to reset at start...

So now i am planning to move to configuration shown in section 6.3 , i.e it
uses a MOSFET for soft switching.....

Has anyone used this type , please can u help me out in this.......

And i have to change my Imax current register to 300mA using Mprog
utility.... ll it work????

The data sheet doc...

http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf



-- 
(¨`•.•´¨) Always
`•.¸(¨`•.•´¨) Keep
(¨`•.•´¨)¸.•´ Smiling!
`•.¸.•´

With Regards,
Kiran.P

$# K|tTy$#

[Ftdi-usb-sio-devel] hi

[Kiran P <kir...@gm...>]

-- 
(¨`•.•´¨) Always
`•.¸(¨`•.•´¨) Keep
(¨`•.•´¨)¸.•´ Smiling!
`•.¸.•´

With Regards,
Kiran.P

$# K|tTy$#

[Ftdi-usb-sio-devel] About ftdi hardware flow control

[Tao J. <jin...@gm...>]

Hi all 

I have a ft232RL chip that converts USB to uart.  I am trying ti use the hardware flow control. 

I connect the RTS pin on FT232RL to the CTS pin of my serial device, and CTS of FT232RL to RTS of my serial device. 

I use oscilloscope to monitor the signals. I saw that when RTS pin of my device toggles high, FT232RL chip is still sending bits. 

Do I need to do anything in my C program to access the ftdi flow control feature?  Or I just need to hook up all the pins. 

Thanks a lot in advance!

Jintao

Re: [Ftdi-usb-sio-devel] about XON/XOFF

[Tao J. <jin...@gm...>]

Hi,

I figured out why.

Besides setting IXON IXOFF flags, I also need to specify the VSTART
and VSTOP value in c_cc option.

Now it works.

thanks,

jintao

On Thu, Jul 8, 2010 at 10:50 AM, Tao Jin <jin...@gm...> wrote:
> thanks bill!
> I set the IXON and IXOFF flags in my our serial io program by doing
> c_flag |= IXON | IXOFF
> But when the serial dev sends XOFF, the pc still can send bytes to the
> serial dev
> Is this the right way to do this?
> Thanks again
> Jintao
>
>
> On Jul 8, 2010, at 3:08, Bill Ryder <bil...@gm...> wrote:
>
> Usually you use the kernel serial stack to handle xon/off
>
> Search google for
>
> termios xon
>
> eg
> http://homepages.cwi.nl/~aeb/linux/man2html/man3/termios.3.html
> and
> http://en.wikibooks.org/wiki/Serial_Programming/termios
>
>
> for example.
>
>
>
> On Thu, Jul 8, 2010 at 11:44 AM, Tao Jin <jin...@gm...> wrote:
>>
>> Dear all,
>>
>> I have a question about serial software flow control.  Here is my
>> experiment setup.
>>
>> PC < ---- > serial device
>>
>> PC1 talks to serial device through minicom.
>>
>> When I send a byte in minicom, the serial device toggle LED to
>> indicate the reception of new byte
>>
>> When serial device receives up to 10 byte, serial device sends
>> XOFF(0x13) byte to PC.
>>
>> I have already enabled software flow control in minicom, so I expect
>> that next time when I send another byte from minicom, the serial
>> device is NOT supposed to receive anything.  b/c the serial driver
>> received XOFF earlier.
>>
>> But XOFF doesn't work for me.
>>
>> My question is should my program takes care of XOFF?  or the serial
>> driver actually takes care of that automatically?
>>
>> thanks a lot in advance!
>>
>> jintao
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

Re: [Ftdi-usb-sio-devel] about XON/XOFF

[Tao J. <jin...@gm...>]

thanks bill!

I set the IXON and IXOFF flags in my our serial io program by doing
c_flag |= IXON | IXOFF

But when the serial dev sends XOFF, the pc still can send bytes to the serial dev

Is this the right way to do this?

Thanks again

Jintao


On Jul 8, 2010, at 3:08, Bill Ryder <bil...@gm...> wrote:

> Usually you use the kernel serial stack to handle xon/off
> 
> Search google for 
> 
> termios xon
> 
> eg
> http://homepages.cwi.nl/~aeb/linux/man2html/man3/termios.3.html
> and
> http://en.wikibooks.org/wiki/Serial_Programming/termios
> 
> 
> for example.
> 
> 
> 
> On Thu, Jul 8, 2010 at 11:44 AM, Tao Jin <jin...@gm...> wrote:
> Dear all,
> 
> I have a question about serial software flow control.  Here is my
> experiment setup.
> 
> PC < ---- > serial device
> 
> PC1 talks to serial device through minicom.
> 
> When I send a byte in minicom, the serial device toggle LED to
> indicate the reception of new byte
> 
> When serial device receives up to 10 byte, serial device sends
> XOFF(0x13) byte to PC.
> 
> I have already enabled software flow control in minicom, so I expect
> that next time when I send another byte from minicom, the serial
> device is NOT supposed to receive anything.  b/c the serial driver
> received XOFF earlier.
> 
> But XOFF doesn't work for me.
> 
> My question is should my program takes care of XOFF?  or the serial
> driver actually takes care of that automatically?
> 
> thanks a lot in advance!
> 
> jintao
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
> 

Re: [Ftdi-usb-sio-devel] about XON/XOFF

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

Usually you use the kernel serial stack to handle xon/off

Search google for

termios xon

eg
http://homepages.cwi.nl/~aeb/linux/man2html/man3/termios.3.html
and
http://en.wikibooks.org/wiki/Serial_Programming/termios


for example.



On Thu, Jul 8, 2010 at 11:44 AM, Tao Jin <jin...@gm...> wrote:

> Dear all,
>
> I have a question about serial software flow control.  Here is my
> experiment setup.
>
> PC < ---- > serial device
>
> PC1 talks to serial device through minicom.
>
> When I send a byte in minicom, the serial device toggle LED to
> indicate the reception of new byte
>
> When serial device receives up to 10 byte, serial device sends
> XOFF(0x13) byte to PC.
>
> I have already enabled software flow control in minicom, so I expect
> that next time when I send another byte from minicom, the serial
> device is NOT supposed to receive anything.  b/c the serial driver
> received XOFF earlier.
>
> But XOFF doesn't work for me.
>
> My question is should my program takes care of XOFF?  or the serial
> driver actually takes care of that automatically?
>
> thanks a lot in advance!
>
> jintao
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

[Ftdi-usb-sio-devel] about XON/XOFF

[Tao J. <jin...@gm...>]

Dear all,

I have a question about serial software flow control.  Here is my
experiment setup.

PC < ---- > serial device

PC1 talks to serial device through minicom.

When I send a byte in minicom, the serial device toggle LED to
indicate the reception of new byte

When serial device receives up to 10 byte, serial device sends
XOFF(0x13) byte to PC.

I have already enabled software flow control in minicom, so I expect
that next time when I send another byte from minicom, the serial
device is NOT supposed to receive anything.  b/c the serial driver
received XOFF earlier.

But XOFF doesn't work for me.

My question is should my program takes care of XOFF?  or the serial
driver actually takes care of that automatically?

thanks a lot in advance!

jintao

Re: [Ftdi-usb-sio-devel] latency on serial port

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

Unfortunately strace doesn't decode the TIOCSSERIAL structure.

However setserial is not the right thing for this anyway. It's more for
traditional serial ports - ie not USB ones. It's a way to communicate with
the serial chip. The only use in the USB driver I've seen is to set
nonstandard baudrates.

stty is the correct program to use.

You have to set the VMIN/VTIME values (which stty calls time and min)

man termios

describes the ioctls stty uses.

Re: [Ftdi-usb-sio-devel] latency on serial port

[Tao J. <jin...@gm...>]

Hi guys,

Here is some update.

1)  I tried setserial low_latency on my linksys router, which has
onboard serial port.  It works and the RTT time is reduced down to
below 1ms

2)  I tried setserial on PC with a FTDI-serial device, it doesn't work
at all.  I think I might need to modify the FTDI driver?

Hi Bill,

Here is the strace log. If you could take a look at this, I would
really appreciate it!

$ sudo strace -v setserial /dev/ttyUSB0 low_latency

execve("/bin/setserial", ["setserial", "/dev/ttyUSB0", "low_latency"],
["TERM=xterm", "LS_COLORS=rs=0:di=01;34:ln=01;36"...,
"PATH=/usr/local/sbin:/usr/local/"..., "LANG=en_US.utf8",
"HOME=/home/taojin", "DISPLAY=:0.0",
"XAUTHORITY=/var/run/gdm/auth-for"..., "COLORTERM=gnome-terminal",
"SHELL=/bin/bash", "LOGNAME=root", "USER=root", "USERNAME=root",
"SUDO_COMMAND=/usr/bin/strace -v "..., "SUDO_USER=taojin",
"SUDO_UID=1000", "SUDO_GID=1000"]) = 0
brk(0)                                  = 0x2319000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb9f504c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_dev=makedev(8, 1), st_ino=31328821, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=216,
st_size=109259, st_atime=2010/06/24-11:36:40,
st_mtime=2010/06/22-11:33:39, st_ctime=2010/06/22-11:33:39}) = 0
mmap(NULL, 109259, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb9f5031000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\355\1\0\0\0\0\0"...,
832) = 832
fstat(3, {st_dev=makedev(8, 1), st_ino=59638010, st_mode=S_IFREG|0755,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=3064,
st_size=1568136, st_atime=2010/06/23-17:09:20,
st_mtime=2010/05/21-05:06:49, st_ctime=2010/06/10-16:47:40}) = 0
mmap(NULL, 3676200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fb9f4aac000
mprotect(0x7fb9f4c24000, 2097152, PROT_NONE) = 0
mmap(0x7fb9f4e24000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178000) = 0x7fb9f4e24000
mmap(0x7fb9f4e29000, 18472, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb9f4e29000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb9f5030000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb9f502f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb9f502e000
arch_prctl(ARCH_SET_FS, 0x7fb9f502f700) = 0
mprotect(0x7fb9f4e24000, 16384, PROT_READ) = 0
mprotect(0x604000, 4096, PROT_READ)     = 0
mprotect(0x7fb9f504e000, 4096, PROT_READ) = 0
munmap(0x7fb9f5031000, 109259)          = 0
open("/dev/ttyUSB0", O_RDWR|O_NONBLOCK) = 3
ioctl(3, TIOCGSERIAL, 0x7fff97a2bea0)   = 0
ioctl(3, TIOCSSERIAL, 0x7fff97a2be50)   = 0
close(3)                                = 0
exit_group(0)                           = ?


On Wed, Jun 23, 2010 at 2:47 AM, Bill Ryder <bil...@gm...> wrote:
> Y
>
> On Wed, Jun 23, 2010 at 5:36 PM, Tao Jin <jin...@gm...> wrote:
>>
>> Hi Bill,
>>
>> Thanks a lot for your quick response!  I set VMIN=1, VTIME=0 so the
>> serial device works in block mode.
>>
>> I just tried the serial echo test on my linksys linux router, which
>> has onboard serial port.  setserial works for me and the RTT latency
>> can be reduced down to below 1ms
>>
>> But when I did the same test on my laptop with a FT232RL usb-to-serial
>> adapter, the setserial doesn't work.   Probably the usb serial device
>> works in different way?  Sorry I am new to Linux kernel
>
> Y ou could try using stty instead of setserial.
>
> I can't remember the calls setserial makes. It's possible one is not
> supported by the driver.
>
> I think stty does it using supported calls.
>
>
> If you could send an output of
>
> strace -v setserial what ever options you used
>
> it'll give me a hint.
>
> Also you might need to hold the device open. (in a separate window run
> cat > /dev/ttyUSBthenumberoftheport
> and just leave it running - it's doing nothing except holding the port open)
>
> then try setserial or stty and your test program
>
>
>
>
>
>>
>> Thanks again!
>>
>> jintao
>>
>> On Wed, Jun 23, 2010 at 1:14 AM, Bill Ryder <bil...@gm...>
>> wrote:
>> > Have a look at this:
>> >
>> > http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>> >
>> > You are probably setup to do 0.1s timeout when reading the port which is
>> > the
>> > default.
>> >
>> > you need to set  VMIN/VTIME properly.
>> >
>> >
>> >
>> >
>> > On Wed, Jun 23, 2010 at 4:57 PM, Tao Jin <jin...@gm...> wrote:
>> >>
>> >> Dear all,http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>> >>
>> >> I am trying to get my laptop running Ubuntu to communicate with a
>> >> sensor through serial interface.  I used usb-to-serial adapter to
>> >> connect the laptop and sensor serial RX/TX pins.  I observed a long
>> >> latency when I do a one-byte serial echo test, around 10ms.
>> >>
>> >> I googled a bit, and seems a lot of people had the same issue. someone
>> >> said setserial /dev/ttyS* low_latency can get the serial device work
>> >> in low latency mode, with higher CPU load.  I tried, that doesn't work
>> >> for me.
>> >>
>> >> Anyone here know about this latency issue on serial link?  Could you
>> >> please provide some guidance to resolve this issue?
>> >>
>> >> Thanks a lot in advance!
>> >>
>> >> jintao
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> >> lucky parental unit.  See the prize list and enter to win:
>> >> http://p.sf.net/sfu/thinkgeek-promo
>> >> _______________________________________________
>> >> Ftdi-usb-sio-devel mailing list
>> >> Ftd...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>> >
>> >
>
>

Re: [Ftdi-usb-sio-devel] latency on serial port

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

Y

On Wed, Jun 23, 2010 at 5:36 PM, Tao Jin <jin...@gm...> wrote:

> Hi Bill,
>
> Thanks a lot for your quick response!  I set VMIN=1, VTIME=0 so the
> serial device works in block mode.
>
> I just tried the serial echo test on my linksys linux router, which
> has onboard serial port.  setserial works for me and the RTT latency
> can be reduced down to below 1ms
>
> But when I did the same test on my laptop with a FT232RL usb-to-serial
> adapter, the setserial doesn't work.   Probably the usb serial device
> works in different way?  Sorry I am new to Linux kernel
>

Y ou could try using stty instead of setserial.

I can't remember the calls setserial makes. It's possible one is not
supported by the driver.

I think stty does it using supported calls.


If you could send an output of

strace -v setserial what ever options you used

it'll give me a hint.

Also you might need to hold the device open. (in a separate window run
cat > /dev/ttyUSBthenumberoftheport
and just leave it running - it's doing nothing except holding the port open)

then try setserial or stty and your test program






> Thanks again!
>
> jintao
>
> On Wed, Jun 23, 2010 at 1:14 AM, Bill Ryder <bil...@gm...>
> wrote:
> > Have a look at this:
> >
> > http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
> >
> > You are probably setup to do 0.1s timeout when reading the port which is
> the
> > default.
> >
> > you need to set  VMIN/VTIME properly.
> >
> >
> >
> >
> > On Wed, Jun 23, 2010 at 4:57 PM, Tao Jin <jin...@gm...> wrote:
> >>
> >> Dear all,http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
> >>
> >> I am trying to get my laptop running Ubuntu to communicate with a
> >> sensor through serial interface.  I used usb-to-serial adapter to
> >> connect the laptop and sensor serial RX/TX pins.  I observed a long
> >> latency when I do a one-byte serial echo test, around 10ms.
> >>
> >> I googled a bit, and seems a lot of people had the same issue. someone
> >> said setserial /dev/ttyS* low_latency can get the serial device work
> >> in low latency mode, with higher CPU load.  I tried, that doesn't work
> >> for me.
> >>
> >> Anyone here know about this latency issue on serial link?  Could you
> >> please provide some guidance to resolve this issue?
> >>
> >> Thanks a lot in advance!
> >>
> >> jintao
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> >> lucky parental unit.  See the prize list and enter to win:
> >> http://p.sf.net/sfu/thinkgeek-promo
> >> _______________________________________________
> >> Ftdi-usb-sio-devel mailing list
> >> Ftd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
> >
> >
>

Re: [Ftdi-usb-sio-devel] latency on serial port

[BillRebey <Bi...@Re...>]

jintao,

I'm watching this thread with great interest.  

If you happen to solve the problem outside the context of this thread, thus
"obscuring " the solution from the rest of us, would you be so kind as to
document your findings here and post the solution for the rest of us?

Thanks!

Bill Rebey  (Not to be confused with Bill Ryder - the other poster)


-----Original Message-----
From: Tao Jin [mailto:jin...@gm...] 
Sent: Wednesday, June 23, 2010 1:36 AM
To: Bill Ryder
Cc: ftd...@li...
Subject: Re: [Ftdi-usb-sio-devel] latency on serial port

Hi Bill,

Thanks a lot for your quick response!  I set VMIN=1, VTIME=0 so the
serial device works in block mode.

I just tried the serial echo test on my linksys linux router, which
has onboard serial port.  setserial works for me and the RTT latency
can be reduced down to below 1ms

But when I did the same test on my laptop with a FT232RL usb-to-serial
adapter, the setserial doesn't work.   Probably the usb serial device
works in different way?  Sorry I am new to Linux kernel

Thanks again!

jintao

On Wed, Jun 23, 2010 at 1:14 AM, Bill Ryder <bil...@gm...> wrote:
> Have a look at this:
>
> http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>
> You are probably setup to do 0.1s timeout when reading the port which is
the
> default.
>
> you need to set  VMIN/VTIME properly.
>
>
>
>
> On Wed, Jun 23, 2010 at 4:57 PM, Tao Jin <jin...@gm...> wrote:
>>
>> Dear all,http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>>
>> I am trying to get my laptop running Ubuntu to communicate with a
>> sensor through serial interface.  I used usb-to-serial adapter to
>> connect the laptop and sensor serial RX/TX pins.  I observed a long
>> latency when I do a one-byte serial echo test, around 10ms.
>>
>> I googled a bit, and seems a lot of people had the same issue. someone
>> said setserial /dev/ttyS* low_latency can get the serial device work
>> in low latency mode, with higher CPU load.  I tried, that doesn't work
>> for me.
>>
>> Anyone here know about this latency issue on serial link?  Could you
>> please provide some guidance to resolve this issue?
>>
>> Thanks a lot in advance!
>>
>> jintao
>>
>>
>>
----------------------------------------------------------------------------
--
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>

----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Ftdi-usb-sio-devel mailing list
Ftd...@li...
https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel

__________ Information from ESET Smart Security, version of virus signature
database 5220 (20100623) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Re: [Ftdi-usb-sio-devel] latency on serial port

[Tao J. <jin...@gm...>]

Hi Bill,

Thanks a lot for your quick response!  I set VMIN=1, VTIME=0 so the
serial device works in block mode.

I just tried the serial echo test on my linksys linux router, which
has onboard serial port.  setserial works for me and the RTT latency
can be reduced down to below 1ms

But when I did the same test on my laptop with a FT232RL usb-to-serial
adapter, the setserial doesn't work.   Probably the usb serial device
works in different way?  Sorry I am new to Linux kernel

Thanks again!

jintao

On Wed, Jun 23, 2010 at 1:14 AM, Bill Ryder <bil...@gm...> wrote:
> Have a look at this:
>
> http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>
> You are probably setup to do 0.1s timeout when reading the port which is the
> default.
>
> you need to set  VMIN/VTIME properly.
>
>
>
>
> On Wed, Jun 23, 2010 at 4:57 PM, Tao Jin <jin...@gm...> wrote:
>>
>> Dear all,http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/index.html
>>
>> I am trying to get my laptop running Ubuntu to communicate with a
>> sensor through serial interface.  I used usb-to-serial adapter to
>> connect the laptop and sensor serial RX/TX pins.  I observed a long
>> latency when I do a one-byte serial echo test, around 10ms.
>>
>> I googled a bit, and seems a lot of people had the same issue. someone
>> said setserial /dev/ttyS* low_latency can get the serial device work
>> in low latency mode, with higher CPU load.  I tried, that doesn't work
>> for me.
>>
>> Anyone here know about this latency issue on serial link?  Could you
>> please provide some guidance to resolve this issue?
>>
>> Thanks a lot in advance!
>>
>> jintao
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Ftdi-usb-sio-devel mailing list
>> Ftd...@li...
>> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>
>