HI All,
I would like to implement class driver for USB, which is enumerated as
virtaul com port which in tunr is enumerated as modem. Can anyone suggest
me how to go about it?How to use CDC ACM for modem class driver?
Thanks,
Shruthi
On Thu, Dec 26, 2013 at 10:14 AM, shruthi kl wrote:
>
> HI All,
>
> I would like to implement class driver for USB, which is enumerated as
> virtaul com port which in tunr is enumerated as modem. Can anyone suggest
> me how to go about it?How to use CDC ACM for modem class driver?This driver
> is implemented for windows 7 64 bit PC.
>
> Thanks,
> Shruthi
>
>
>
>
shruthi kl wrote:
I would like to implement class driver for USB, which is enumerated
as virtaul com port which in tunr is enumerated as modem. Can anyone
suggest me how to go about it? How to use CDC ACM for modem class driver?
First, let me ask you to step back and talk about what you are really
trying to accomplish. Serial ports are a terrible way to communicate,
whether they are real or virtual. For gosh sakes, the RS-232 standard
was introduced more than 50 years ago. We’re a lot smarter now.
If you have a piece of equipment you want to communicate with, the right
answer is to use USB the way it was designed to be used, not cripple it
by forcing it to simulate a 50-year-old technology. So, WHY do you
think you need a virtual COM port? It is not any easier to use than a
DLL wrapping WinUSB.
I would also point out that Thesycon already has a USB CDC ACM class driver:
http://www.thesycon.de/eng/usb_cdcacm.shtml
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
I completely agree that serial ports are a terrible way to communicate.
However, on several occasions I have been forced to use serial to
communicate with a USB device, because that’s what the hardware designer
wanted.
I’m curious how you deal with this? What concrete arguments do you use
to try and steer the hardware folk away from throwing in a USB CDC chip,
and calling it done?
Cheers,
–mkj
On 12/26/2013 12:45 PM, Tim Roberts wrote:
First, let me ask you to step back and talk about what you are really
trying to accomplish. Serial ports are a terrible way to communicate,
whether they are real or virtual. For gosh sakes, the RS-232 standard
was introduced more than 50 years ago. We’re a lot smarter now.If you have a piece of equipment you want to communicate with, the right
answer is to use USB the way it was designed to be used, not cripple it
by forcing it to simulate a 50-year-old technology. So, WHY do you
think you need a virtual COM port? It is not any easier to use than a
DLL wrapping WinUSB.I would also point out that Thesycon already has a USB CDC ACM class driver:
http://www.thesycon.de/eng/usb_cdcacm.shtml
–
– mkj
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
Michael Jones wrote:
I completely agree that serial ports are a terrible way to communicate.
However, on several occasions I have been forced to use serial to
communicate with a USB device, because that’s what the hardware designer
wanted.I’m curious how you deal with this? What concrete arguments do you use
to try and steer the hardware folk away from throwing in a USB CDC chip,
and calling it done?
A PIC 18F2550 isn’t very expensive. It has a couple of UARTs, plus I2C
and SPI, plus an analog/digital converter, and it can be driven using a
modern software paradigm instead of a simulated serial port.
A Cypress FX2 is a little more expensive, but now you have a high-speed
parallel interface to work with, as well as I2C and SPI.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I have programmed serial ports from every level to low-level ISR-based
drivers to high-level protocols implemented in apps. There is nothing
good to say about the technique. I well-and-truly hated when a client
came to me with a “simple serial port interface” device. It was rarely
simple. The number of problems it has are considerable.
Trying to simulate a serial port is nontrivial, because you have to
properly simulate all its deficiencies. Which are considerable.
joe
shruthi kl wrote:
>
>
> I would like to implement class driver for USB, which is enumerated
> as virtaul com port which in tunr is enumerated as modem. Can anyone
> suggest me how to go about it? How to use CDC ACM for modem class
> driver?First, let me ask you to step back and talk about what you are really
trying to accomplish. Serial ports are a terrible way to communicate,
whether they are real or virtual. For gosh sakes, the RS-232 standard
was introduced more than 50 years ago. We’re a lot smarter now.If you have a piece of equipment you want to communicate with, the right
answer is to use USB the way it was designed to be used, not cripple it
by forcing it to simulate a 50-year-old technology. So, WHY do you
think you need a virtual COM port? It is not any easier to use than a
DLL wrapping WinUSB.I would also point out that Thesycon already has a USB CDC ACM class
driver:
http://www.thesycon.de/eng/usb_cdcacm.shtml–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks for that; it’s useful to have part numbers to quote.
A recent project where this was an issue used a Silicon Labs chip that
talked USB CDC out one end, and was a serial UART on the other. So, the
argument went, no firmware to write, and easy to interface
(electrically) to the equipment they were building.
I couldn’t really argue with that, except to say that talking to an
instrument using a command-response protocol over a serial link with no
concept of packets means writing more software than a simple USB-based
packet interface, so they are not really saving anything (except the
electrical interfacing, which I could not comment on, since they weren’t
interested in discussing hardware changes at this point).
I guess there’s no real way to deal with that sort of bias in design.
Perhaps we all tend to gravitate to what we know (especially when you’re
a small start-up trying to ship it’s first instrument). On the one
hand, that’s what keeps me in business. On the other hand, it is not
very satisfying to build klunky solutions.
Cheers,
–mkj
On 12/26/2013 4:31 PM, Tim Roberts wrote:
Michael Jones wrote:
> I completely agree that serial ports are a terrible way to communicate.
> However, on several occasions I have been forced to use serial to
> communicate with a USB device, because that’s what the hardware designer
> wanted.
>
> I’m curious how you deal with this? What concrete arguments do you use
> to try and steer the hardware folk away from throwing in a USB CDC chip,
> and calling it done?A PIC 18F2550 isn’t very expensive. It has a couple of UARTs, plus I2C
and SPI, plus an analog/digital converter, and it can be driven using a
modern software paradigm instead of a simulated serial port.A Cypress FX2 is a little more expensive, but now you have a high-speed
parallel interface to work with, as well as I2C and SPI.
–
– mkj
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
xxxxx@flounder.com wrote:
I have programmed serial ports from every level to low-level ISR-based
drivers to high-level protocols implemented in apps. There is nothing
good to say about the technique. I well-and-truly hated when a client
came to me with a “simple serial port interface” device. It was rarely
simple. The number of problems it has are considerable.
Yes. Twenty years ago, we used to plan that the first two days of every
project would be blown trying to get kernel debugging to work over
whatever serial port was on the systems we were using.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.