Serial driver increase baud limit

NTDEV
1

I have an FPGA that I have programmed a UART core to communicate at 921.6kbaud using the RS422 or RS485 standard (my transceiver supports both, no plans yet for any networks). FPGA to FPGA communication works just fine, however I run into a road block when trying to communicate with my PC through its RS422/RS485 port.

My PC’s motherboard uses a Winbond W83627DHG I/O transceiver that supports up to 1.5Mbaud. First I tried using a USB-RS485 converter and I was able to communicate at 921.6kbaud, but the 1ms latency of USB made it impossible to use.

My Windows program compiles with baud rates over 115.2kbaud, however when it tries to connect to the port it always quits with an exception. I believe the standard windows serial driver is holding me back, so I am looking to add support for a baud rate up to 921.6kbaud.

I am basically wondering if this is even possible and that I’m heading in the right direction. I have downloaded the Windows DDK and have been stumbling around the sample serial driver for a week now but without much process. I have also been reading as much as possible on the internet about windows driver development and the ball is slowly rolling along.

I apologize for any ignorance of mine as I have never programmed Windows drivers before, so this is all a learning experience for me.

2

On 10-Oct-2012 02:36, xxxxx@gmail.com wrote:

I have an FPGA that I have programmed a UART core to communicate at 921.6kbaud using the RS422 or RS485 standard (my transceiver supports both, no plans yet for any networks). FPGA to FPGA communication works just fine, however I run into a road block when trying to communicate with my PC through its RS422/RS485 port.

My PC’s motherboard uses a Winbond W83627DHG I/O transceiver that supports up to 1.5Mbaud. First I tried using a USB-RS485 converter and I was able to communicate at 921.6kbaud, but the 1ms latency of USB made it impossible to use.

My Windows program compiles with baud rates over 115.2kbaud, however when it tries to connect to the port it always quits with an exception. I believe the standard windows serial driver is holding me back, so I am looking to add support for a baud rate up to 921.6kbaud.

I am basically wondering if this is even possible and that I’m heading in the right direction. I have downloaded the Windows DDK and have been stumbling around the sample serial driver for a week now but without much process. I have also been reading as much as possible on the internet about windows driver development and the ball is slowly rolling along.

I apologize for any ignorance of mine as I have never programmed Windows drivers before, so this is all a learning experience for me.

You definitely do not want to start hacking the Windows serial driver
just to connect a FPGA.
Have you seen the new FTDI USB adapters/cables? they support high
speed USB (FT2232H, FT4232H, FT2232D) and come with ready Windows drivers.
– pa

3

“All” I want is a baud rate of 916.2k. Still a “standard” baud rate, and I don’t want any additional functions (more data bits per frame, interrupts, etc.). I realize hacking the windows serial driver is far from ideal but I am convinced it is the bottleneck.

The problem with anything USB is the 1ms minimum interval that exists between data frames for synchronization. This means that in between instructions for read/write over USB there is a mandatory 1ms wait before sending/receiving more data.

This is no problem when dealing with large data sizes, but when dealing with a low data count of only 4 bytes it creates a significant delay. If I was sending a large amount of data that could occupy that 1ms gap it would be fine. USB is completely out of the option.

I will reiterate that my requirements are for 32 bits to be sent/received in less than 60us.

4

The in box serial driver controls a 16550 uart and nithing else. From what I understand from what you described, this is not going over an rs232 port. I would strongly consider a 3rd party PCI(e) device that has deeper buffers and can handle your baud rate. Also remember that windows is not an rtos, so your 60us requirement might hard to meet even if you have the right underlying hw.

d

debt from my phone

From: xxxxx@gmail.com
Sent: 10/9/2012 9:57 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial driver increase baud limit

“All” I want is a baud rate of 916.2k. Still a “standard” baud rate, and I don’t want any additional functions (more data bits per frame, interrupts, etc.). I realize hacking the windows serial driver is far from ideal but I am convinced it is the bottleneck.

The problem with anything USB is the 1ms minimum interval that exists between data frames for synchronization. This means that in between instructions for read/write over USB there is a mandatory 1ms wait before sending/receiving more data.

This is no problem when dealing with large data sizes, but when dealing with a low data count of only 4 bytes it creates a significant delay. If I was sending a large amount of data that could occupy that 1ms gap it would be fine. USB is completely out of the option.

I will reiterate that my requirements are for 32 bits to be sent/received in less than 60us.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Thank you for your recommendation Doron.

Right now PCI is my backup option, but I would ideally like to use the built in 16550 UART. I would earnestly like to test out this baud rate using the standard windows UART to see its limitations first hand, if there are any. Then after thorough testing move on to PCI if necessary.

Unfortunately moving away from Windows is out of the option too. Currently I have a parallel connection setup using an ISA bus at around 60us. I am trying to move to a serial connection to accommodate improvements on the board the FPGA is on.

Since this is my first time being exposed to Windows drivers, any recommendations on setting out how to add the higher baud rate? I have been trying to digest the serial.sys sample driver but it’s difficult trying to follow the program’s flow. Unfortunately there isn’t a whole lot of documentation on the subject either that I can find.

6

d

debt from my phone

From: xxxxx@gmail.com
Sent: 10/9/2012 11:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial driver increase baud limit

Thank you for your recommendation Doron.

Right now PCI is my backup option, but I would ideally like to use the built in 16550 UART. I would earnestly like to test out this baud rate using the standard windows UART to see its limitations first hand, if there are any. Then after thorough testing move on to PCI if necessary.

Unfortunately moving away from Windows is out of the option too. Currently I have a parallel connection setup using an ISA bus at around 60us. I am trying to move to a serial connection to accommodate improvements on the board the FPGA is on.

Since this is my first time being exposed to Windows drivers, any recommendations on setting out how to add the higher baud rate? I have been trying to digest the serial.sys sample driver but it’s difficult trying to follow the program’s flow. Unfortunately there isn’t a whole lot of documentation on the subject either that I can find.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

16550 uart datasheets should be readily available on the internet. That will show you what bits to poke on the hw. As an anecdotal datapoint, folks used to crank the kernel debugger baud rate to 115.2K and it was problematic to say the least…lost bits, corrupt data, etc. That speed was pretty unreliable

d

debt from my phone

From: xxxxx@gmail.com
Sent: 10/9/2012 11:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial driver increase baud limit

Thank you for your recommendation Doron.

Right now PCI is my backup option, but I would ideally like to use the built in 16550 UART. I would earnestly like to test out this baud rate using the standard windows UART to see its limitations first hand, if there are any. Then after thorough testing move on to PCI if necessary.

Unfortunately moving away from Windows is out of the option too. Currently I have a parallel connection setup using an ISA bus at around 60us. I am trying to move to a serial connection to accommodate improvements on the board the FPGA is on.

Since this is my first time being exposed to Windows drivers, any recommendations on setting out how to add the higher baud rate? I have been trying to digest the serial.sys sample driver but it’s difficult trying to follow the program’s flow. Unfortunately there isn’t a whole lot of documentation on the subject either that I can find.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

You might try a wired Ethernet to serial adapter, which would avoid the USB polling latency.

I thought the standard serial driver looked as the hardware to determine the maximum realistic baud rate. Some chips may claim 916k baud, but only if you run them at specific clock speeds (due to timing accuracy requirements of low clock divisors).

A typical serial port also has increased latency from the FIFO. There might be a way to turn off the FIFO (registry option), although this potentially risks dropping bytes if the interrupt response isn’t fast enough.

You realize Windows is not a hard real-time OS and you may not consistently get a 60 usec I/O latency. Sorry to be a messenger of reality.

You say you want to send/receive 32-bits in less than 60 usec, which back of envelope calculations say you will need a serial baud rate of > 60 usec / 32 (half a megabaud), which would also be about 15 usec per byte, which if you get a processor interrupt on every byte would be an interrupt rate of 66,666 interrupts sec, which is a pretty hefty interrupt rate. If you are going to both send 4 bytes and receive 4 bytes, a byte at a time, every 60 usec, that’s essentially greater than 125K I/Os/sec, getting out of the slow device range. Even if you read and write 4 bytes per I/O request, in a single interrupt, that’s approaching 20,000 interrupts/sec. Ethernet devices frequently throttle interrupt rates to something like 5000 interrupts/sec.

You might consider using a $5 microcontroller, which you download/upload batches of data to, and it can just sit there and talk to you FPGA. Your latency requirements are in kind of an ugly range, pretty slow for a real ($$) bus master DMA controller, but too fast for a slow dumb controller (serial port) or USB (slave polling latency latency). Perhaps one of the USB expert folks here could comment if USB interrupt endpoints might have less latency (Wikepedia claims < 1 usec latency, but that seems rather low).

You sound like a typical embedded hardware designer with not such a good grasp of the I/O realities of general purpose OSs. For you, 15 usec is pretty slow, to the OS, having to respond to 66K interrupts sec is pretty fast. The OS pretty much assumes I/O will either be trivia (like 115kbaud serial on a 16 byte FIFO, which is like a thousand interrupts/sec), or else there is a smart controller than handles the time critical stuff, and the OS deals with batches of data. Something like a storage or network controller can process millions of requests/sec, but only in batches with latency rather longer.

So can you tell us more, does there have to a user mode app to FPGA round trip every 60 usec?

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, October 09, 2012 10:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial driver increase baud limit

“All” I want is a baud rate of 916.2k. Still a “standard” baud rate, and I don’t want any additional functions (more data bits per frame, interrupts, etc.). I realize hacking the windows serial driver is far from ideal but I am convinced it is the bottleneck.

The problem with anything USB is the 1ms minimum interval that exists between data frames for synchronization. This means that in between instructions for read/write over USB there is a mandatory 1ms wait before sending/receiving more data.

This is no problem when dealing with large data sizes, but when dealing with a low data count of only 4 bytes it creates a significant delay. If I was sending a large amount of data that could occupy that 1ms gap it would be fine. USB is completely out of the option.

I will reiterate that my requirements are for 32 bits to be sent/received in less than 60us.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

The Winbond W83627DHG transceiver I am using now, is that not the 16550 UART that Windows would use for transmission? If so, it’s rated for speeds up to 1.5Mbaud.

From my tests 115.2k seems very reliable and I haven’t noticed any data degradation.

10

I had never thought to use an ethernet-to-serial adapter. Originally I had wanted to use ethernet, but then trying to implement an ethernet core on an FPGA is either too expensive or too complicated for me. How would the interaction with the PC work? Standard TCP/IP protocol, or would it appear as a virtual COM port, etc.?

Yes the chip claims 1.5Mbaud, but that’s using the 24MHz internal clock source. Through looking at the standard serial driver I can see it rejects the baud rate if when divided by the clock speed it creates too much of an error, but I also see the struct SUPPORTED_BAUD_RATES that supports up to a 128K baud rate. I assumed the 128K didn’t work with my application because it creates too much of a baud error. Would the windows serial driver be in charge of changing the UART’s clock source? I have read the UART’s data sheets on customizing the configuration register, but I never read exactly /how/ I would do that.

At 115.2K when I hooked up my serial port to my oscilloscope I never noticed any significant latancy like I did with the USB-Serial converter. Would the FIFO latency become apparent at speeds >115.2k?

And if I could I would just send a batch of data to the FPGA and let it handle the rest, but unfortunately I do need a user app round trip in <60us.

I am currently an internship student working on an independent company project. My focus has most definitely been on the hardware side (specifically FPGAs) and any OS programming I have done was always in Linux. This is my first real exposure to Windows in this sort of use…

Faster than 60us would work as well. 60us is just the slowest my application is allowed to run. If I can communicate any faster I can just use the FPGA to clock it and let it be the governor.

11

AFAIR it is possible to get much lower latency than 1ms from USB. For example, you can set up to stream isochronous data to/from a set of buffers which you can read/write “just in time” as the data is actually received / going to be sent. This establishes a very low latency pipe to/from the target device. The problem is knowing exactly where in the buffers the isochronous stream is writing/reading, but it can be done. I can’t see why this can’t also apply to asynchronous transfers, though you don’t then have the guarantee of bandwidth. You should be able to queue one or more buffers per microframe then access them from the app “just in time”. Of course, with Windows you have to cater for missing the slot when the OS is busy and with asynch you have to allow for USB retries, as you don’t know if the transfer was successful until after you will have started consuming / sending the data.

Mike

----- Original Message -----
From: xxxxx@gmail.com
To: Windows System Software Devs Interest List
Sent: Wednesday, October 10, 2012 6:01 AM
Subject: RE:[ntdev] Serial driver increase baud limit

“All” I want is a baud rate of 916.2k. Still a “standard” baud rate, and I don’t want any additional functions (more data bits per frame, interrupts, etc.). I realize hacking the windows serial driver is far from ideal but I am convinced it is the bottleneck.

The problem with anything USB is the 1ms minimum interval that exists between data frames for synchronization. This means that in between instructions for read/write over USB there is a mandatory 1ms wait before sending/receiving more data.

This is no problem when dealing with large data sizes, but when dealing with a low data count of only 4 bytes it creates a significant delay. If I was sending a large amount of data that could occupy that 1ms gap it would be fine. USB is completely out of the option.

I will reiterate that my requirements are for 32 bits to be sent/received in less than 60us.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

12

You know, when I think it about, why don’t you just program an Ethernet Arduino (or I suppose a more hefty ARM processor like a Rasberry Pi) with some TCP to FPGA interface code (like via SPI or I2C) and send your 4 bytes back and forth on a LAN. Those gadgets are like $65, and easily available from someplace like adafruit.com. I don’t off the top of my head know what the round trip latency would be like, so you would need to look into it. Actually, I’ve known companies that made products that directly interface an FPGA to an Ethernet chip, I assume those have pretty low latency.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, October 10, 2012 12:13 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial driver increase baud limit

I had never thought to use an ethernet-to-serial adapter. Originally I had wanted to use ethernet, but then trying to implement an ethernet core on an FPGA is either too expensive or too complicated for me. How would the interaction with the PC work? Standard TCP/IP protocol, or would it appear as a virtual COM port, etc.?

Yes the chip claims 1.5Mbaud, but that’s using the 24MHz internal clock source. Through looking at the standard serial driver I can see it rejects the baud rate if when divided by the clock speed it creates too much of an error, but I also see the struct SUPPORTED_BAUD_RATES that supports up to a 128K baud rate. I assumed the 128K didn’t work with my application because it creates too much of a baud error. Would the windows serial driver be in charge of changing the UART’s clock source? I have read the UART’s data sheets on customizing the configuration register, but I never read exactly /how/ I would do that.

At 115.2K when I hooked up my serial port to my oscilloscope I never noticed any significant latancy like I did with the USB-Serial converter. Would the FIFO latency become apparent at speeds >115.2k?

And if I could I would just send a batch of data to the FPGA and let it handle the rest, but unfortunately I do need a user app round trip in <60us.

I am currently an internship student working on an independent company project. My focus has most definitely been on the hardware side (specifically FPGAs) and any OS programming I have done was always in Linux. This is my first real exposure to Windows in this sort of use…

Faster than 60us would work as well. 60us is just the slowest my application is allowed to run. If I can communicate any faster I can just use the FPGA to clock it and let it be the governor.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

13

Some very good advice has already been supplied. This serial port idea is not likely to work well in the end. Let me explain some Windows OS fundamental reasons why this is so.

The Windows serial port driver supports baud rates up to 115.2K out of the box – Not only would you have to correctly program the hardware to support higher baud rates (that is, bang the right bits in the proper register), but you’d also have to be sure the overall design of the serial port driver properly accomdated the (significantly) higher throughout you’re looking for. Knowing the heritage of the Windows serial port driver, I suspect this may be problematic.

Even more to the point, one thing that folks responding here know that you probably don’t is that Windows total interrupt servicing latencies (most especially latency from ISR to DPC) are *extremely* variable. While typical latencies can be just a few micro-seconds, the tails of the distribution can be very, very, lengthy. The bottom line is that it’s quite easy to engineer a solution that works “most of the time” but dramatically fails “once in a while.”

The solution to this is a design that anticipates and handles these occasional extreme latencies. The typical approach here is deep FIFOs (as Mr. Holan recommended). There are other, implementation specific, approaches as well (such as dropping data at extreme latencies… obviously this works only if this is acceptable to your application).

Bottom line: I’d forget about the Windows serial port. I’m sure it sounds simple and elegant. I’m afraid it’ll be just simple and problematic. I like Mr. Bottorff’s analysis. Pavel A’s idea to use one of the “out of the box” FTDI USB-to-Serial cables and their driver is an EXCELLENT suggestion… it’s cheap and you can try it quickly to see how you like it. I’ve used FTDI’s stuff before with excellent results. FWIW, they have a whole custom API for their driver OR it can look like a Windows serial port. Why not try that and see how it works.

Bottom line: You need a systems approach to solving your end-to-end engineering problem. You can’t merely focus on the FPGA side and then say “and then I’ll just plug this into a serial port, write a program, and grab the data”… acquiring data reliably at that rate depends on a whole series of factors. It’s no problem at all if you want to use an interface that’s been designed for the latencies and throughputs that you’re expecting. But using a many decade old serial port via a driver that’s been effectively (if not technically) deprecated raises challenges the type of which I don’t think you really want to grapple.

14

<mr. bottorff>You sound like a typical embedded hardware designer with not such a good grasp of the I/O realities of general purpose OSs.</mr.> This was clearly not meant as a slight and I greatly appreciate that Mr. Bottoroff would deliver it without it being so. I run into this issue frequently enough to recognize how hard it is to deliver this message to very smart and talented ES or HW folks. My it would be handy at times to have a concise and well presented article entitled roughly “The things you should have known about Windows before you designed your hardware” to diffuse the blow-back from delivering that message that invariantly occurs. Cheers Jan. Dave Cattley

15

+1.

Heck, +2.

–mkj

On 10/10/2012 10:07 AM, Dave Cattley wrote:

My it would be handy at times to have a concise and well presented
article entitled roughly

“The things you should have known about Windows before you designed
> your hardware”
>
> to diffuse the blow-back from delivering that message that invariantly
> occurs.
>
> Cheers Jan.
>
> Dave Cattley
>
>
>
>

–

“I can answer any question, so long as you agree that
‘I don’t know’ is an answer.”
– Isaac Asimov


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

16

Like.
– pa

On 10-Oct-2012 16:10, Michael Jones wrote:

+1.

Heck, +2.

–mkj

On 10/10/2012 10:07 AM, Dave Cattley wrote:
>
> My it would be handy at times to have a concise and well presented
> article entitled roughly
>
> “The things you should have known about Windows before you designed
>> your hardware”
>>
>> to diffuse the blow-back from delivering that message that invariantly
>> occurs.
>>
>> Cheers Jan.
>>
>> Dave Cattley

17

On 10-Oct-2012 15:14, xxxxx@osr.com wrote:
[snip]

Pavel A’s idea to use one of the “out of the box” FTDI USB-to-Serial cables and their driver is
an EXCELLENT suggestion… it’s cheap and you can try it quickly to see how you like it.
I’ve used FTDI’s stuff before with excellent results. FWIW, they have a whole custom API for their driver
OR it can look like a Windows serial port. Why not try that and see how it works.
[snip]

Thank you, Peter.
Just thought it’s worth to mention that FTDI currently does not endorse
any customization of their drivers, the host-USB protocol is closed;
no driver sources even for Linux, no support for WinUSB…
All this is as bad as it sounds.
But the data sheets for their high speed chips/cables look very
interesting for connecting simple synchronous buses, besides of the
traditional UART.

Regards,
– pa

18

You don’t want to use isoch. There are no crc checks, so unless you are wrapping your data in a crc protocol (SLIP or PPP anyone :stuck_out_tongue: ?), the speed gains mean easy data loss

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, October 10, 2012 1:42 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Serial driver increase baud limit

AFAIR it is possible to get much lower latency than 1ms from USB. For example, you can set up to stream isochronous data to/from a set of buffers which you can read/write “just in time” as the data is actually received / going to be sent. This establishes a very low latency pipe to/from the target device. The problem is knowing exactly where in the buffers the isochronous stream is writing/reading, but it can be done. I can’t see why this can’t also apply to asynchronous transfers, though you don’t then have the guarantee of bandwidth. You should be able to queue one or more buffers per microframe then access them from the app “just in time”. Of course, with Windows you have to cater for missing the slot when the OS is busy and with asynch you have to allow for USB retries, as you don’t know if the transfer was successful until after you will have started consuming / sending the data.

Mike

----- Original Message -----
From: xxxxx@gmail.commailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Wednesday, October 10, 2012 6:01 AM
Subject: RE:[ntdev] Serial driver increase baud limit

“All” I want is a baud rate of 916.2k. Still a “standard” baud rate, and I don’t want any additional functions (more data bits per frame, interrupts, etc.). I realize hacking the windows serial driver is far from ideal but I am convinced it is the bottleneck.

The problem with anything USB is the 1ms minimum interval that exists between data frames for synchronization. This means that in between instructions for read/write over USB there is a mandatory 1ms wait before sending/receiving more data.

This is no problem when dealing with large data sizes, but when dealing with a low data count of only 4 bytes it creates a significant delay. If I was sending a large amount of data that could occupy that 1ms gap it would be fine. USB is completely out of the option.

I will reiterate that my requirements are for 32 bits to be sent/received in less than 60us.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

19

Mike Kemp wrote:

AFAIR it is possible to get much lower latency than 1ms from USB. For
example, you can set up to stream isochronous data to/from a set of
buffers which you can read/write “just in time” as the data is
actually received / going to be sent. This establishes a very low
latency pipe to/from the target device. The problem is knowing exactly
where in the buffers the isochronous stream is writing/reading, but it
can be done.

Have you ever done that? I’m not saying it’s impossible, but I’d wager
that it can’t be done in practical terms. Different host controllers do
their isochronous timing in slightly different ways.

The original poster’s problem is that he is using a USB-to-serial
converter, which means it is Communication Device Class, which means he
is locked into bulk pipes.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

20

Not only is he locked into bulk pipes, but most, if not all, USB -> Serial chips are Full Speed devices (even though they are USB 2.0). That means they operate on 1 mS frames so no better than 1 mS guaranteed resolution. Jitter can be from nearly 0 mS up to 2 mS.

Greg

— xxxxx@probo.com wrote:

From: Tim Roberts
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Serial driver increase baud limit
Date: Wed, 10 Oct 2012 11:54:06 -0700

Mike Kemp wrote:
> AFAIR it is possible to get much lower latency than 1ms from USB. For
> example, you can set up to stream isochronous data to/from a set of
> buffers which you can read/write “just in time” as the data is
> actually received / going to be sent. This establishes a very low
> latency pipe to/from the target device. The problem is knowing exactly
> where in the buffers the isochronous stream is writing/reading, but it
> can be done.

Have you ever done that? I’m not saying it’s impossible, but I’d wager
that it can’t be done in practical terms. Different host controllers do
their isochronous timing in slightly different ways.

The original poster’s problem is that he is using a USB-to-serial
converter, which means it is Communication Device Class, which means he
is locked into bulk pipes.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer