sukumar gudugunta wrote:
can we do all these ioctls setting n getting the baudrates by sending
URbs to the host controller driver in lower edze…
Do you realize that no one on this group can possibly answer that question? We have no idea what your device is, let alone what mechanism it requires to communicate serial state information to it. Only you can really figure this out. Why don’t you have this information already if you’ve been tasked to write the driver for tihs device?
On Fri, Jul 04, 2008 at 06:20:37AM -0400, xxxxx@lntemsys.com wrote:
> your function driver will accept RS-232 ioctls from above,
> and will make USB requests belowto make this possible i am following wdm samples...becz in kmdf URB(usb
request blocks ) r hidden by providing framework objects.
"Hidden" is not really accurate. Better, perhaps, is "wrapped". Requests
still use URBs, but KMDF helps you create and manage the URBs. There is
no way to send USB requests other than by using URBs.
and i found one statement that
"USB client drivers set up USB request blocks (URBs) to send requests
to the host controller driver. The URB structure defines a format for
all possible commands that can be sent to a USB device."
can u tell meis it the right way to solve the issue?
What issue?
can we do all these ioctls setting n getting the baudrates by sending URbs
to the host controller driver in lower edze..
What, exactly, is your hardware? If you have a simple USB cable that just
acts like a serial port, then it won't have a baud rate. You can fake the
baud rate ioctls. If you really do have a physical serial port at some
point, then YOU need to know what commands to send to it to select a
baud rate. We can't answer that.
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.
yes…
we have a usb cable has to act like a serial port…n it is a device of bulk data tranfer type…
i am developind the driver on host side only…
you can fake the baud rate controls
can u brief about this …i mean to ask that if we return the status as successful wihout forwarding the inf does it make sense?
sukumar gudugunta wrote:
can u brief about this …i mean to ask that if we return the status as successful
wihout forwarding the inf does it make sense?
For about the fifth time now, we don’t know if that makes sense, because we don’t know your device.
xxxxx@lntemsys.com wrote:
yes…
we have a usb cable has to act like a serial port…n it is a device of bulk data tranfer type…
i am developind the driver on host side only…> you can fake the baud rate controls
>
can u brief about this …i mean to ask that if we return the status as successful wihout forwarding the inf does it make sense?
You certainly cannot forward the IRP! It should be obvious that the USB
driver stack does not understand serial port IRPs. Your job is to
TRANSLATE the serial port requests into whatever USB commands are needed
to satisfy the request. The only thing you are allowed to send down are
URBs.
If there is no real RS-232 cable involved, then most of the serial port
IRPs have no use, and you can just return success.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
> i mean to ask that if we return the status as successful wihout
> forwarding the inf does it make sense?You certainly cannot forward the IRP! It should be obvious that
the USB driver stack does not understand serial port IRPs.
Note that he said “forward the inf,” as in forward the “information” about the baud rate. At least, that’s the way I took it. Although I don’t doubt he would try forwarding IOCTL_SERIAL_SET_BAUD_RATE down to usbhub.
thanq for ur answers…
i completed all the ioctl’s n external naming as comport. n my doubt is if irp comes as IRP_MJ_WRITE
Input Parameters:
The Parameters.Write.Length member is set to the number of bytes to copy from a client-allocated write buffer to a serial device.
The AssociatedIrp.SystemBuffer member points to a client-allocated write buffer from which Serial copies data to the serial device.
by getting this parameters we can do the USB implementation to send data to the device…right? i mean to ask that in serial sample code he created so many buffers to do this…is it need?
and in serial code some IRP’s r given as
IRP_MN_READ_CONFIG
IRP_MN_WRITE_CONFIG
To access device configuration space at IRQL = PASSIVE_LEVEL, you must use IRP_MN_READ_CONFIG and IRP_MN_WRITE_CONFIG. You indicate in the IRP stack which configuration space you wish to access and where the I/O buffer is. i got this info from doc…
what does it mean----PASSIVE_LEVEl…shall we need to take care of these to minor functions ?
can we trace this code without installation? is it possible?
i thought of installing this driver in port class…am i right?
plz don’t feel so many doubts…it’s my first exp with drivers so…
sukumar gudugunta wrote:
what does it mean----PASSIVE_LEVEl
Well, I’m out. This thread already has 27 posts and you’re asking this question. I just can’t bear to continue.
it’s my first exp with drivers so…
Starting with a USB serial driver, then, is probably unwise.