Linked URB's question.

message unavailable

Henry Van Dyke wrote:

"Alexander wrote:

: I have a trouble with High speed USB device.

What kind of trouble ?

: As I know 6.2.1 does not supports linked URBs, am I right?

Yes you are correct.

: And when it will be realiased?

Maybe you could explain why you need this feature.
You can call usbd_io for multple URBs and the USB
stack will keep requests enqueued for an endpoint.

I have a USB that works with raw data bitrate 128kb/s and I need
to recieve it in real time. Device works ok with Win9x, but in 6.2.1
I have many lost packets.

Can u explain to me why I can allocate (usbd_alloc)
more memory for data transfers then endpoint.wMaxPacketSize
for Bulk transfers? For example buffer 8064 bytes. And after
usbd_urb_status( urb, &ustatus, &alen ) i get whole 8064 bytes.
In case of > then 8064 bytes usbd_alloc returns addres of
allocated buffer, but usbd_urb_status returns 0 bytes recieved.
In case of 64b buffer transfer speed is very low. Is there any way
to solve this problem?

They should be on the third party CD IIRC.

Erick.

Davide <doesnot@exist.spam> wrote:

Chris McKillop wrote:

Nick Lovejoy <> nlovejoy@syscor.com> > wrote:

Sean Boudreau wrote:

I thank everyone for their help but my actual question was never
answered.

How do I compile? Is “qcc -shared filename” all I need to do.

Also, could someone provide some boiler plate for an io-net filter or
some code that is more relavent than the device driver code that is
provided with the DDK. I’m making best guesses as to what I need and
don’t need and the errors that are being returned when I try to mount
are not what I would call informative eg…


Take a look at > http://staff.qnx.com/~xtang/> . I belive that the
binaries and source to bpf/tcpdump can be found there.


Does anyone know if the source code to tcpdump/bpf is still available?
I have been looking around but not been able to find it.

Regards,
Davide


/------------------------------------------------------------

  • Davide Ancri - Prisma Engineering
  • email = davidea AT prisma DASH eng DOT it
    ------------------------------------------------------------/

Erick Muis
Hardware Group
QNX Software Systems Ltd.
Email: emuis at qnx.com

Chris McKillop wrote:

Nick Lovejoy <> nlovejoy@syscor.com> > wrote:

Sean Boudreau wrote:

I thank everyone for their help but my actual question was never
answered.

How do I compile? Is “qcc -shared filename” all I need to do.

Also, could someone provide some boiler plate for an io-net filter or
some code that is more relavent than the device driver code that is
provided with the DDK. I’m making best guesses as to what I need and
don’t need and the errors that are being returned when I try to mount
are not what I would call informative eg…


Take a look at > http://staff.qnx.com/~xtang/> . I belive that the
binaries and source to bpf/tcpdump can be found there.

Does anyone know if the source code to tcpdump/bpf is still available?
I have been looking around but not been able to find it.

Regards,
Davide


/------------------------------------------------------------

  • Davide Ancri - Prisma Engineering
  • email = davidea AT prisma DASH eng DOT it
    ------------------------------------------------------------/

Erick Muis wrote:

They should be on the third party CD IIRC.

Sorry, but I can’t find them there. Looking at my 3rd party cd and e.g.
tcpdump in particular I am not able to find any source code.

tar ztf tcpdump-3.6.2-public.qpk

public/
public/tcpdump/
public/tcpdump/core-3.6.2/
public/tcpdump/core-3.6.2/MANIFEST
public/tcpdump/core-3.6.2/usr/
public/tcpdump/core-3.6.2/usr/man/
public/tcpdump/core-3.6.2/usr/man/man1/
public/tcpdump/core-3.6.2/usr/man/man1/tcpdump.1

tar ztf tcpdump-3.6.2-x86-public.qpk

public/
public/tcpdump/
public/tcpdump/core-3.6.2/
public/tcpdump/core-3.6.2/x86/
public/tcpdump/core-3.6.2/x86/MANIFEST
public/tcpdump/core-3.6.2/x86/lib/
public/tcpdump/core-3.6.2/x86/lib/dll/
public/tcpdump/core-3.6.2/x86/lib/dll/nfm-bpf.so
public/tcpdump/core-3.6.2/x86/usr/
public/tcpdump/core-3.6.2/x86/usr/bin/
public/tcpdump/core-3.6.2/x86/usr/bin/tcpdump

Davide


Davide <> doesnot@exist.spam> > wrote:
Chris McKillop wrote:

Nick Lovejoy <> nlovejoy@syscor.com> > wrote:

Sean Boudreau wrote:

I thank everyone for their help but my actual question was never
answered.

How do I compile? Is “qcc -shared filename” all I need to do.

Also, could someone provide some boiler plate for an io-net filter or
some code that is more relavent than the device driver code that is
provided with the DDK. I’m making best guesses as to what I need and
don’t need and the errors that are being returned when I try to mount
are not what I would call informative eg…


Take a look at > http://staff.qnx.com/~xtang/> . I belive that the
binaries and source to bpf/tcpdump can be found there.


Does anyone know if the source code to tcpdump/bpf is still available?
I have been looking around but not been able to find it.

/------------------------------------------------------------

  • Davide Ancri - Prisma Engineering
  • email = davidea AT prisma DASH eng DOT it
    ------------------------------------------------------------/

Sorry, but I can’t find them there. Looking at my 3rd party cd and e.g.
tcpdump in particular I am not able to find any source code.

There is a separate source tarball on the ISO.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop <cdm@qnx.com> wrote:

Sorry, but I can’t find them there. Looking at my 3rd party cd and e.g.
tcpdump in particular I am not able to find any source code.


There is a separate source tarball on the ISO.

As mentioned in this news post:
http://www.openqnx.com/Article117.html
you can download the source code separately if you don’t already have
the CD.

Frank Liu wrote:

Chris McKillop <> cdm@qnx.com> > wrote:

Sorry, but I can’t find them there. Looking at my 3rd party cd and e.g.
tcpdump in particular I am not able to find any source code.


There is a separate source tarball on the ISO.


As mentioned in this news post:
http://www.openqnx.com/Article117.html
you can download the source code separately if you don’t already have
the CD.

I have managed to download the tcpdump source code. Looking at it though
I realize that bpf is not supported here.
Does anyone know if the source code to nfm-bpf.so is publicly available?
nfm-bpf.so is included in the tcpdump binary package but not in the
tcpdump source package.

Regards,
Davide

/------------------------------------------------------------

  • Davide Ancri - Prisma Engineering
  • email = davidea AT prisma DASH eng DOT it
    ------------------------------------------------------------/

Alexander Arkhipov <arkhipov@tst.spb.su> wrote in message
news:bulcov$a7c$1@inn.qnx.com

Henry Van Dyke wrote:
"Alexander wrote:

: I have a trouble with High speed USB device.

What kind of trouble ?

: As I know 6.2.1 does not supports linked URBs, am I right?

Yes you are correct.

: And when it will be realiased?

Maybe you could explain why you need this feature.
You can call usbd_io for multple URBs and the USB
stack will keep requests enqueued for an endpoint.

I have a USB that works with raw data bitrate 128kb/s and I need
to recieve it in real time. Device works ok with Win9x, but in 6.2.1
I have many lost packets.

Can u explain to me why I can allocate (usbd_alloc)
more memory for data transfers then endpoint.wMaxPacketSize
for Bulk transfers?
You can enqueue transfers of larger than MaxPacket size. That USB

controller/stack will complete the transcation when it receives/sends
the complete data or gets a short packet on and IN transfer.

For example buffer 8064 bytes. And after

usbd_urb_status( urb, &ustatus, &alen ) i get whole 8064 bytes.
In case of > then 8064 bytes usbd_alloc returns addres of
allocated buffer, but usbd_urb_status returns 0 bytes recieved.
In case of 64b buffer transfer speed is very low. Is there any way
to solve this problem?

Is your USB controller UHCI or OHCI ?

To achieve better performance what you can do is allocate and enqueue
multiple URBs. This way the USB stack will have requests enqueued on
the endpoint while a URB completes. The bus then wont be idle while
your driver gets notified of a single completed URB. This is what
our USB network drivers do to get acceptable performance.

Alexander Arkhipov <> arkhipov@tst.spb.su> > wrote in message
news:bulcov$a7c$> 1@inn.qnx.com> …

Henry Van Dyke wrote:
"Alexander wrote:

: I have a trouble with High speed USB device.

What kind of trouble ?

: As I know 6.2.1 does not supports linked URBs, am I right?

Yes you are correct.

: And when it will be realiased?

Maybe you could explain why you need this feature.
You can call usbd_io for multple URBs and the USB
stack will keep requests enqueued for an endpoint.

I have a USB that works with raw data bitrate 128kb/s and I need
to recieve it in real time. Device works ok with Win9x, but in 6.2.1
I have many lost packets.

Can u explain to me why I can allocate (usbd_alloc)
more memory for data transfers then endpoint.wMaxPacketSize
for Bulk transfers?
You can enqueue transfers of larger than MaxPacket size. That USB
controller/stack will complete the transcation when it receives/sends
the complete data or gets a short packet on and IN transfer.

For example buffer 8064 bytes. And after
usbd_urb_status( urb, &ustatus, &alen ) i get whole 8064 bytes.
In case of > then 8064 bytes usbd_alloc returns addres of
allocated buffer, but usbd_urb_status returns 0 bytes recieved.
In case of 64b buffer transfer speed is very low. Is there any way
to solve this problem?

Is your USB controller UHCI or OHCI ?

Class = Serial Bus (Universal Serial Bus)
Vendor ID = e11h, Compaq Computer Corp.
Device ID = a0f8h, ZFMicro USB Open Host Controller
PCI index = 0h
Class Codes = 0c0310h
Revision ID = 6h
Bus number = 0
Device number = 19
Function num = 0
Status Reg = 280h
Command Reg = 7h
I/O space access enabled
Memory space access enabled
Bus Master enabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Checking disabled
Data/Address stepping disabled
SERR# driver disabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI Mem Address = db024000h 32bit length 4096 enabled
Subsystem Vendor ID = e11h
Subsystem ID = a0f8h
Max Lat = 80ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 11
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

To achieve better performance what you can do is allocate and enqueue
multiple URBs. This way the USB stack will have requests enqueued on
the endpoint while a URB completes. The bus then wont be idle while
your driver gets notified of a single completed URB. This is what
our USB network drivers do to get acceptable performance.

Something like this? :wink:
for (i = 0; i < MAX_ISO_BUFS; i++)
{
urb = pdev->sbuf_.urb;
usbd_setup_bulk(urb, USB_DIR_IN, pdev->sbuf.data,
pdev->vmax_packet_size);
usbd_io(urb, pdev->ep_bulk_pipe, bulk_cbf, pdev->sbuf.data,
USBD_TIME_INFINITY);
}

And few more question: should I use the same callback and
wait functions structure for bulk transfers like at prinnter USB driver example?
What the point of re-hook’ing of endpoint? Should I use it in my callback?

Thanx._

Alexander Arkhipov <arkhipov@tst.spb.su> wrote in message
news:bv3008$a8m$1@inn.qnx.com

Alexander Arkhipov <> arkhipov@tst.spb.su> > wrote in message
news:bulcov$a7c$> 1@inn.qnx.com> …

Henry Van Dyke wrote:
"Alexander wrote:

: I have a trouble with High speed USB device.

What kind of trouble ?

: As I know 6.2.1 does not supports linked URBs, am I right?

Yes you are correct.

: And when it will be realiased?

Maybe you could explain why you need this feature.
You can call usbd_io for multple URBs and the USB
stack will keep requests enqueued for an endpoint.

I have a USB that works with raw data bitrate 128kb/s and I need
to recieve it in real time. Device works ok with Win9x, but in 6.2.1
I have many lost packets.

Can u explain to me why I can allocate (usbd_alloc)
more memory for data transfers then endpoint.wMaxPacketSize
for Bulk transfers?
You can enqueue transfers of larger than MaxPacket size. That USB
controller/stack will complete the transcation when it receives/sends
the complete data or gets a short packet on and IN transfer.

For example buffer 8064 bytes. And after
usbd_urb_status( urb, &ustatus, &alen ) i get whole 8064 bytes.
In case of > then 8064 bytes usbd_alloc returns addres of
allocated buffer, but usbd_urb_status returns 0 bytes recieved.
In case of 64b buffer transfer speed is very low. Is there any way
to solve this problem?

Is your USB controller UHCI or OHCI ?

Class = Serial Bus (Universal Serial Bus)
Vendor ID = e11h, Compaq Computer Corp.
Device ID = a0f8h, ZFMicro USB Open Host Controller
PCI index = 0h
Class Codes = 0c0310h
Revision ID = 6h
Bus number = 0
Device number = 19
Function num = 0
Status Reg = 280h
Command Reg = 7h
I/O space access enabled
Memory space access enabled
Bus Master enabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Checking disabled
Data/Address stepping disabled
SERR# driver disabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI Mem Address = db024000h 32bit length 4096 enabled
Subsystem Vendor ID = e11h
Subsystem ID = a0f8h
Max Lat = 80ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 11
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

To achieve better performance what you can do is allocate and enqueue
multiple URBs. This way the USB stack will have requests enqueued on
the endpoint while a URB completes. The bus then wont be idle while
your driver gets notified of a single completed URB. This is what
our USB network drivers do to get acceptable performance.

Something like this? > :wink:
for (i = 0; i < MAX_ISO_BUFS; i++)
{
urb = pdev->sbuf> .urb;
usbd_setup_bulk(urb, USB_DIR_IN, pdev->sbuf> .data,
pdev->vmax_packet_size);
usbd_io(urb, pdev->ep_bulk_pipe, bulk_cbf, pdev->sbuf> .data,
USBD_TIME_INFINITY);
}

Yes. You can either usbd_alloc() one large buffer and point each usbd_io

call a a portion of the buffer, or usbd_alloc smaller buffers for each of
the
transfers

And few more question: should I use the same callback and
wait functions structure for bulk transfers like at prinnter USB driver
example?
What the point of re-hook’ing of endpoint? Should I use it in my callback?

Use the same callback for all URBs and re-hook them in the callback.

Thanx.


\

5000 Euro Belohnung / 5000 Euro Reward --------------------------------------Ich biete eine Belohnung von 5000 Euro wenn mir jemand verraetwie ein Streetgame (International Money Game) die Leute um den Spieler herrum beeinflusst.Ich stecke in genau diesem Unfug drin und irgendjemand manipuliertalle Leute, denen ich begegne und Radio bzw. Fernsehprogramme, dieich beobachte.I offer a reward of 5000 Euro if anybody tells me how a streetgame(International Money Game) manipulates the people around the player.I’m currently trapped in something like that and somebody manipulateseverybody I meet and radio or TV programs I watch or listen to.http://www.fastenrath.net/, http://slashdot.org/~fastenrath/Bernhard FastenrathSteinfelder Gasse 1, 50670 Koeln, Germanyfon: +49-173-5166326fax: +49-69-13306976636email: fasten@hrs.com

Hi everybody,


I’m looking for source code of a driver using the libhid interface. I
would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.

Hi everybody,


I’m looking for source code of a driver using the libhid interface. I
would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.

Hi everybody,


I’m looking for source code of a driver using the libhid interface. I
would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.

Hi John,
It would be a very good starting point for us. I’m waiting it
with impatience.

John Nagle a écrit :

Someone asked for our old joystick driver, and I really
should make that code generally available. Maybe next week.
Or perhaps, you can send it to me by email ?

Thank you very much.

John Nagle

Peter wrote:

Hi everybody,


I’m looking for source code of a driver using the libhid interface. I
would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.

A copy has been sent to what seems to be the correct E-mail address,
but due to ambiguous address obfusication the E-mail may be lost.

John Nagle

Peter wrote:

Hi John,
It would be a very good starting point for us. I’m waiting it
with impatience.

John Nagle a écrit :

Someone asked for our old joystick driver, and I really
should make that code generally available. Maybe next week.

Or perhaps, you can send it to me by email ?

Thank you very much.


John Nagle

Peter wrote:

Hi everybody,


I’m looking for source code of a driver using the libhid interface. I
would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.

Hello John,

I am curious about your approach to developing the driver, since I had
written one of my own and use it with the robots in my lab here. Do you
plan to make your driver publicly available.

Thanks
Vilas

http//www.ces.clemson.edu/~cvilas

John Nagle wrote:

A copy has been sent to what seems to be the correct E-mail address,
but due to ambiguous address obfusication the E-mail may be lost.

John Nagle


Peter wrote:

Hi John,
It would be a very good starting point for us. I’m waiting it
with impatience.

John Nagle a écrit :

Someone asked for our old joystick driver, and I really
should make that code generally available. Maybe next week.

Or perhaps, you can send it to me by email ?

Thank you very much.


John Nagle

Peter wrote:

Hi everybody,


I’m looking for source code of a driver using the libhid interface.
I would like to wrote a driver for an USB digital I/O device using the
HID protocol.

Thanks in advance.