Henque | 3 Jul 15:23 2010
Picon

Re: problem open DeviceDescriptor


Hello Summer,

Have you resolved your problem? I have a similar one and I would that you
help me to resolve my problem.

Thanks in advance,
Hector.
--

-- 
View this message in context: http://libusb.6.n5.nabble.com/problem-open-DeviceDescriptor-tp9738p547200.html
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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
Xiaofan Chen | 3 Jul 15:34 2010
Picon

Re: problem open DeviceDescriptor

On Sat, Jul 3, 2010 at 9:23 PM, Henque <he_laos <at> hotmail.com> wrote:
> Hello Summer,
>
> Have you resolved your problem? I have a similar one and I would that you
> help me to resolve my problem.

We will have idea what you are talking about here.

If possible, please do not use Nabble to post. You can subscribe to
libusb-win32 mailing list directly here.
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

You must be replying to a certain thread there. But then you have to
refer to the thread.

So this is the link you are replying to.
http://libusb.6.n5.nabble.com/problem-open-DeviceDescriptor-td9738.html

Please post the output of testlibusb-win.exe and tell us
your version of OS. Thanks.

--

-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/

------------------------------------------------------------------------------
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
H Martin Reekie | 7 Jul 20:22 2010
Picon
Picon

Slightly different question ...

Folks,

I am in a hurry to get 256 bytes of data from a PC to a PIC, and 128
bytes back again.  Also I want priority of the bus, as it's busy.
I thought I would therefore set up 6 endpoints on the PIC, 4 OUT and
2 IN, and would give a series of commands like:
ret = usb_interrupt_write(dev, EP3_OUT, EP3_data, 0x40, 200);
ret = usb_interrupt_write(dev, EP4_OUT, EP4_data, 0x40, 200);
ret = usb_interrupt_write(dev, EP5_OUT, EP5_data, 0x40, 200);
ret = usb_interrupt_write(dev, EP6_OUT, EP6_data, 0x40, 200);
ret = usb_interrupt_read(dev, EP3_IN, EP3_indata, 0x40, 200);
hoping they would all go into one, 1ms, USB frame.  I am coming
to the conclusion that this does not work and they *seem* to go
one per frame.

Am I being over-ambitious?!

Martin
--

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

------------------------------------------------------------------------------
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
Xiaofan Chen | 8 Jul 01:29 2010
Picon

Re: Slightly different question ...

On Thu, Jul 8, 2010 at 2:22 AM, H Martin Reekie <H.M.Reekie <at> ed.ac.uk> wrote:
> I am in a hurry to get 256 bytes of data from a PC to a PIC, and 128
> bytes back again.  Also I want priority of the bus, as it's busy.
> I thought I would therefore set up 6 endpoints on the PIC, 4 OUT and
> 2 IN, and would give a series of commands like:
> ret = usb_interrupt_write(dev, EP3_OUT, EP3_data, 0x40, 200);
> ret = usb_interrupt_write(dev, EP4_OUT, EP4_data, 0x40, 200);
> ret = usb_interrupt_write(dev, EP5_OUT, EP5_data, 0x40, 200);
> ret = usb_interrupt_write(dev, EP6_OUT, EP6_data, 0x40, 200);
> ret = usb_interrupt_read(dev, EP3_IN, EP3_indata, 0x40, 200);
> hoping they would all go into one, 1ms, USB frame.  I am coming
> to the conclusion that this does not work and they *seem* to go
> one per frame.

What if you increase the buffersize to more, say 640 or 6400?

The other possibility is to use async API to see if that helps.

You may also check your firmware to see if it is the problem
or not.

--

-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/

------------------------------------------------------------------------------
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
H Martin Reekie | 8 Jul 09:29 2010
Picon
Picon

Re: Slightly different question ...

Xiaofan,

As I understand it, the USB spec says that one 64-byte packet can can be
transmitted to/from one endpoint per 1ms frame when using interrupt
transfers.  However, these transfers get priority.  I thought I could
get six, 64-byte, packets per frame if I used 6 endpoints, but that
doesn't seem to work.  I wondered if that was part of libusb.

Increasing the buffer size wouldn't help as it would (should?) split the
data over multiple frames.

Bulk transfers certainly allow more packets per frame, but don't get the
priority.  Nonetheless, I may have to go down that path and try and keep
the USB port/bus/tree/whatever free of other traffic.

I think the firmware is OK, so far as I can influence it.  It has been
well thrashed in other applications.

I find async API very scary as I don't understand the queuing system at
the PC end.  I gather that async requests are just thrown into a queue
for the kernel(?) to deal with, and then the PC gets on with other
stuff, a bit like a non-blocking assignment in Verilog.  Great idea - I
would love to do that.  However, I don't know the PC timing, so I could
throw another USB request into the queue before the first was dealt with
and end up with an overflowing queue.  If I knew the number of requests
currently in the queue I could easily aviod that, but I don't know how
to get that.

Ignorance is a terrible thing ... !!

(Continue reading)

Xiaofan Chen | 8 Jul 09:37 2010
Picon

libusb-win32 v1.2.0.0 released with signed driver

libusb-win32 v1.2.0.0 has been released. This is the first release with
a signed driver (using GlobalSign digital certificate). Now libusb0.sys
has the embedded signature and it can be used on x64 version of
Windows (eg: 64bit Windows Vista or Windows 7 which run on
Intel/AMD 64bit CPUs) machines which require signed driver.

When you use the inf wizard to generate the driver package,
you can install the driver package under 64bit Windows Vista
and Windows 7.

For those who want to pursue WHQL, you can sign the driver
package with a proper digital signature and go through the
necessary testing.

If you encounter problems with libusb-win32, please report
to the libusb-win32 mailing list for support. Thanks.

LibUsb-Win32 Change Log

V1.2.0.0 (07/07/2010)
=======================
* First signed driver release! The libusb-win32 kernel driver (libusb0.sys)
  can now be used on x64 Windows machines that require signed drivers.

* Fixed 2128187 reported by Tim Green. usb_get_descriptor() can fail
  because the given buffer of 8 bytes is too small.

* Fixed 2928293 reported by Tim Green. Sometimes the call to
  usb_fetch_and_parse_descriptors() in usb_find_devices() can fail. This
  patch moves the LIST_ADD to after a successful read of the device's
(Continue reading)

LibUsbDotNet Support | 8 Jul 12:11 2010
Picon

Re: Slightly different question ...


> Martin wrote:
> As I understand it, the USB spec says that one 64-byte packet can can be
> transmitted to/from one endpoint per 1ms frame when using interrupt
> transfers.  However, these transfers get priority.  I thought I could
> get six, 64-byte, packets per frame if I used 6 endpoints, but that
> doesn't seem to work.  I wondered if that was part of libusb.

Hmm.  I think this should work.  I tested this with my benchmark firmware 
which was configured for 2 interfaces each with 2 int endpoints (1 IN, 1 
OUT).  Using async transfers it will sustain 64,000 bytes/sec for each 
endpoint (PIC18F). 64,000 x 4 = 256,000 total bytes/sec

Granted, this test is a bit different and with only 4 endpoints.

> Martin wrote:
> Increasing the buffer size wouldn't help as it would (should?) split the
> data over multiple frames.

Correct.

> I think the firmware is OK, so far as I can influence it.  It has been
> well thrashed in other applications.
>

It  will need to be quick too! ;)

> I find async API very scary as I don't understand the queuing system at
> the PC end.  I gather that async requests are just thrown into a queue
> for the kernel(?) to deal with, and then the PC gets on with other
(Continue reading)

David Novak | 8 Jul 15:25 2010

Re: libusb-win32 v1.2.0.0 released with signed driver

Great work. Thank you!

On 7/8/2010 3:37 AM, Xiaofan Chen wrote:
> libusb-win32 v1.2.0.0 has been released. This is the first release with
> a signed driver (using GlobalSign digital certificate). Now libusb0.sys
> has the embedded signature and it can be used on x64 version of
> Windows (eg: 64bit Windows Vista or Windows 7 which run on
> Intel/AMD 64bit CPUs) machines which require signed driver.
>
> When you use the inf wizard to generate the driver package,
> you can install the driver package under 64bit Windows Vista
> and Windows 7.
>
> For those who want to pursue WHQL, you can sign the driver
> package with a proper digital signature and go through the
> necessary testing.
>
> If you encounter problems with libusb-win32, please report
> to the libusb-win32 mailing list for support. Thanks.
>
>
> LibUsb-Win32 Change Log
>
> V1.2.0.0 (07/07/2010)
> =======================
> * First signed driver release! The libusb-win32 kernel driver (libusb0.sys)
>   can now be used on x64 Windows machines that require signed drivers.
>
> * Fixed 2128187 reported by Tim Green. usb_get_descriptor() can fail
>   because the given buffer of 8 bytes is too small.
(Continue reading)

Mark Brooks | 8 Jul 21:23 2010

Trying to install libusb 1.2.0.0

Firstly, thanks so much for your work on getting a signed driver for us
tring to use Windows 7 and libusb. We really appreciate the efforts.

Now to my problem....

I think I have installed libusb-win32 1.2.0.0.

I run the test program and it is able to see quite a few devices. I install
another device for like a Cypress FX2 device and it does not see it. Is
this expected?

I was thinking this was because i need to create a new .inf file for my
device so I create a .inf file but when the system tries to use it it seems
to complain about the .cat file note being signed. I see this in
windows\inf\setupapi.dev.log.
>>>  [Build Driver List - USB\VID_04B4&PID_1004\5&1CD8866A&0&2]
>>>  Section start 2010/07/08 20:31:13.192
      cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
     cpy: Policy is set to make all digital signatures equal.
!    sig: Verifying file against specific (valid) catalog failed!
(0x00000057)
!    sig: Verifying file against specific Authenticode(tm) catalog failed!
(0x80092003)
<<<  Section end 2010/07/08 20:31:13.192
<<<  [Exit status: SUCCESS]

You say that 
"When you use the inf wizard to generate the driver package,
you can install the driver package under 64bit Windows Vista
and Windows 7."
(Continue reading)

LibUsbDotNet Support | 8 Jul 22:37 2010
Picon

Re: Trying to install libusb 1.2.0.0

> Firstly, thanks so much for your work on getting a signed driver for us
> tring to use Windows 7 and libusb. We really appreciate the efforts.
>
> Now to my problem....
> I think I have installed libusb-win32 1.2.0.0.
> I run the test program and it is able to see quite a few devices.

You must have used the filter installer. correct? 
(libusb-win32-devel-filter-1.2.0.0.zip)

>  I install another device for like a Cypress FX2 device and it
> does not see it. Is this expected?

With the filter serivce yes.  This is because your Cypress FX2 has its own 
class guid (custom usb device)
To resolve this do the following:

1) Start->Programs->Libusb-Win32-≥Disable Filter (you must right click and 
run as administrator)

2) Reboot

3) Start->Programs->Libusb-Win32-≥Enable Filter (you must right click and 
run as administrator)

The filter service works great for developers but should be avoided in a 
production environment.

> "When you use the inf wizard to generate the driver package,
> you can install the driver package under 64bit Windows Vista
(Continue reading)


Gmane