On Mon, Jun 18, 2012 at 4:56 PM, Peter Stuge wrote:
> Peter Stuge wrote:
> > Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
> >
> > It's done unconditionally now, which seems to be the right way to go
> > so that the 31 error happens for one less reason.
>
> On the other ha
On 2012.06.19 00:07, Peter Stuge wrote:
> Do you know all possible reasons are for that error code?
Do I know the content of MSDN by heart? Do I believe that the WinUSB DLL
designers have documented all the possible reasons under which this
error code to be returned? Do I even believe that the e
On Tue, Jun 19, 2012 at 7:24 AM, Xiaofan Chen wrote:
> On Tue, Jun 19, 2012 at 12:05 AM, Pete Batard wrote:
If I use the libusb-1.0.dll MinGW 32bit dll from the binary distribution
with the MinGW.org build xusb.exe and then xusb.exe will work fine.
>>
>> So your MinGW-w64 compiled xusb
On Tue, Jun 19, 2012 at 8:08 AM, Markus wrote:
> On Tue, 19 07:35 , Xiaofan Chen wrote:
>> > http://argh.target23.de/data/fx3.png
>>
>> That still shows High Speed USB, have you tried it with
>> the USB 3.0 SuperSpeed port?
>>
>
> The device is attached to a SuperSpeed hostcontroller here.
> But
On Tue, 19 07:35 , Xiaofan Chen wrote:
> > http://argh.target23.de/data/fx3.png
>
> That still shows High Speed USB, have you tried it with
> the USB 3.0 SuperSpeed port?
>
The device is attached to a SuperSpeed hostcontroller here.
But apparantly, the FX3 bootloader firmware is coming up as
a
Peter Stuge wrote:
> Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
>
> It's done unconditionally now, which seems to be the right way to go
> so that the 31 error happens for one less reason.
On the other hand, do other backends automatically clear stalls? If
no then Windo
Orin Eman wrote:
> > > > What does GetLastError() return in the relevant cases after the
> > > > WinUsb functions return FALSE?
>
> FWIW, WinUsb_ReadPipe() will return 22 immediately if the device is
> disconnected, BUT a pending overlapped WinUsb_ReadPipe() may* complete
> with error 31 - ERROR_G
On Mon, Jun 18, 2012 at 4:07 PM, Peter Stuge wrote:
> Pete Batard wrote:
> > > What does GetLastError() return in the relevant cases after the
> > > WinUsb functions return FALSE?
> >
> > I'd expect "[22] The device does not recognize the command".
>
> Do you know all possible reasons are for tha
On Tue, Jun 19, 2012 at 3:24 AM, Markus wrote:
> After starting to integrate it into cycfx2prog
> (http://www.triplespark.net/elec/periph/USB-FX2/software/)
> I realized that I lack the time to do this cleanly at the moment.
cycfx2prog works under Linux and Windows. And I like it better
than fxlo
On Mon, Jun 18, 2012 at 11:30 PM, Markus wrote:
> I managed to bring the FX3 firmware upload into a working state
> now. Instead of making it a commandline tool on its own, I decided
> to diff it against xusb.c, as the amount of code is limited:
>
> http://argh.target23.de/data/xusb.diff
> http://
On Tue, Jun 19, 2012 at 12:05 AM, Pete Batard wrote:
>>> If I use the libusb-1.0.dll MinGW 32bit dll from the binary distribution
>>> with the MinGW.org build xusb.exe and then xusb.exe will work fine.
>
> So your MinGW-w64 compiled xusb is 32 bit then. It's unlikely to work
> with a 32 bit DLL ot
Pete Batard wrote:
> > What does GetLastError() return in the relevant cases after the
> > WinUsb functions return FALSE?
>
> I'd expect "[22] The device does not recognize the command".
Do you know all possible reasons are for that error code?
> > The topic is that transfers don't complete at
On 2012.06.18 20:31, Peter Stuge wrote:
> What does GetLastError() return in the relevant cases after the
> WinUsb functions return FALSE?
I'd expect "[22] The device does not recognize the command".
> In any case, if transfers have been submitted and are on the flying
> list, and if timeouts are
On Mon, 18 18:01 , Pete Batard wrote:
>
> Still, I agree with Peter that having separate samples dedicated to
> FX2/FX3 devices would be a plus, as there's a lot more we could do with
> those besides uploading firmware. But if you don't have much of a chance
> or time to produce one, using xus
Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?
Can you provide a debug log? I assume you check for submit errors,
and I'm interested in seeing what happens to those later 13.
Thanks!
//P
Pete Batard wrote:
> > Hotplug isn't there yet, and Liam's problem is because the Windows
> > backend doesn't currently implement what the libusb-1.0 API currently
> > offers. Without hotplug. This is a bug in the Windows backend.
>
> Implementing this will require some form of hotplug handling in
On Mon, 18 18:43 , Peter Stuge wrote:
>
> I guess that the fx2load package would welcome a patch! :)
There's already a patch for it:
http://www.cypress.com/?app=forum&id=167&rID=53996
> If you prefer to add an fx3load example to libusb instead then I
> would welcome that, but on the other han
Pete Batard wrote:
> But wouldn't that require at least one manual installation of the filter
> driver by the user, and therefore equate what we can already provide
> with WCID on non Windows platforms, where one WCID WinUSB driver
> installation is enough the make the platform behave the same w
philip.jos...@microchip.com wrote:
> devices that do not have such descriptors will apparently still
> require an INF file for install purposes.
Yes, that is true. At least the problem is going away in the future.
> Having a single API and "single library" across platforms would
> still provide
On 2012.06.18 18:38, Tim Roberts wrote:
> philip.jos...@microchip.com wrote:
>> Just a note in regards to WinUSB and Windows 8. It would appear that a
>> device will not need to provide an INF as long as it provides Windows
>> specific info in its OS descriptors...
>
> When we talked about this bef
philip.jos...@microchip.com wrote:
> Just a note in regards to WinUSB and Windows 8. It would appear that a
> device will not need to provide an INF as long as it provides Windows
> specific info in its OS descriptors...
When we talked about this before, it was mentioned that it would be
possible
Thanks for your comments.
Just a note in regards to WinUSB and Windows 8. It would appear that a
device will not need to provide an INF as long as it provides Windows
specific info in its OS descriptors (refer to Microsoft tech note
http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799
Hi Philip,
philip.jos...@microchip.com wrote:
> the incentive to uncomplicated the user's experience has driven
> many implementers to HID on Windows.
Yes, this is easy to understand. I think by far the best solution to
communicate with HID class devices "manually" is to use HIDAPI.
> Even with
> I created ticket #29 [1] to add your patch against the 1.0.13 milestone,
[1] https://sourceforge.net/apps/trac/libusbx/ticket/29
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways to
On 2012.06.18 17:43, Peter Stuge wrote:
> Markus wrote:
>> I managed to bring the FX3 firmware upload into a working state now.
>> Instead of making it a commandline tool on its own, I decided
>> to diff it against xusb.c
>
> I guess that the fx2load package would welcome a patch! :)
>
> If you pre
Markus wrote:
> I managed to bring the FX3 firmware upload into a working state now.
> Instead of making it a commandline tool on its own, I decided
> to diff it against xusb.c
I guess that the fx2load package would welcome a patch! :)
If you prefer to add an fx3load example to libusb instead th
On 2012.06.18 16:00, Xiaofan Chen wrote:
> On Mon, Jun 18, 2012 at 10:49 PM, Xiaofan Chen wrote:
>> On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
>>> It is my pleasure to announce the release of libusbx v1.0.12.
>>>
>>
>> I found a strange problem under XP 64bit with MinGW.org toolchain.
>>
One of the major factors in using HID in unorthodox ways is that there
is no need for the Windows INF/driver install business. This has always
been a potential problem with a customer's machine (permissions and the
like). I agree that many devices using this class might be better served
using bulk,
On 2012.06.18 16:31, Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?
> If Windows only returns "unlugged" status for one transfer
> and forgets the other ones, can't you just fix this up in t
On 2012.06.18 15:37, Peter Stuge wrote:
> Hotplug isn't there yet, and Liam's problem is because the Windows
> backend doesn't currently implement what the libusb-1.0 API currently
> offers. Without hotplug. This is a bug in the Windows backend.
After 2 similar issues, you still don't get it, so l
On Mon, Jun 18, 2012 at 02:39:45PM +0100, Pete Batard wrote:
> On 2012.06.18 11:50, Peter Stuge wrote:
> >Liam Staskawicz wrote:
> >> This works as intended on OS X, but on Windows I only ever see 3
> >> transfers complete
> >
> > If the later 13 were successfully submitted then that is a bug in th
Hi there,
I managed to bring the FX3 firmware upload into a working state
now. Instead of making it a commandline tool on its own, I decided
to diff it against xusb.c, as the amount of code is limited:
http://argh.target23.de/data/xusb.diff
http://argh.target23.de/data/fx3.png
Starting out deve
On Sat, 16 Jun 2012 11:49:50 +0800, Xiaofan Chen said:
>clang: warning: argument unused during compilation: '-std=gnu99'
>make[2]: Nothing to be done for `all-am'.
>
>-std=gnu99 warning does not seem to be a problem to me.
>When using Apple's llvm based gcc 4.2.1 (default) and the
>Apple gcc 4.2.1
On Mon, Jun 18, 2012 at 10:49 PM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
>> It is my pleasure to announce the release of libusbx v1.0.12.
>>
>
> I found a strange problem under XP 64bit with MinGW.org toolchain.
> On the other hand, I am not so sure if this is a
On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
> It is my pleasure to announce the release of libusbx v1.0.12.
>
I found a strange problem under XP 64bit with MinGW.org toolchain.
On the other hand, I am not so sure if this is a real issue since there
is doubt whether XP 64bit officially sup
Hotplug isn't there yet, and Liam's problem is because the Windows
backend doesn't currently implement what the libusb-1.0 API currently
offers. Without hotplug. This is a bug in the Windows backend.
> >> - is this an appropriate way to manage the process of closing my device?
> >
> > Yes, it is.
On Mon, Jun 18, 2012 at 9:44 PM, Pete Batard wrote:
> On 2012.06.17 14:00, Xiaofan Chen wrote:
In any case, the modification is benign and will work
with different version of dlltool, so I think it is good
to change libusb-1.0.def.
>
> I'm still on the fence there.
>
> I'd rather wa
On 2012.06.17 14:00, Xiaofan Chen wrote:
>>> In any case, the modification is benign and will work
>>> with different version of dlltool, so I think it is good
>>> to change libusb-1.0.def.
I'm still on the fence there.
I'd rather wait a few weeks and see if dlltool are going to fix this, as
the
On 2012.06.18 11:50, Peter Stuge wrote:
>> This works as intended on OS X, but on Windows I only ever see 3
>> transfers complete
>
> If the later 13 were successfully submitted then that is a bug in the
> Windows backend.
Or rather, this is because OS-X has some pre-emptive implementation of
hot
Right now libusbx does not have an example to show how to use
the aysnc API. And some users may want to have some simple
examples than dpfp to start with. And 1.0.13 will hopefully
add libusb0.sys and libusbK.sys with isochronous transfer support.
So I think it will be good to add one example in t
CC libusbx. Maybe Pete and others can give you better answers there.
On Tue, Jun 5, 2012 at 11:09 PM, Liam Staskawicz wrote:
> Hi,
>
> I'm using libusb 1.0.9 on windows7 (building a Qt app with msvc2010), and
> things are largely working just as expected - thanks for a lovely library
> with winus
On Sun, Jun 17, 2012 at 10:33 PM, Ellis Whitehead
wrote:
>>> You can produce detailed debug log if you set the environmental
>>> variable LIBUSB_DEBUG to 4. That debug log may help to identify
>>> the potential problem.
>
> Ok, I've uploaded it here:
> http://gcead.sourceforge.net/libusbx-debug-20
On Mon, Jun 18, 2012 at 6:08 PM, Jach Fong wrote:
> I test it today on using the Borland C++ 5.0 (My previous tests
> were done on another language).
Wow, that is very old toolchain. Any reason you want to use it?
> At first, the BC++ linker complains about the libusb-1.0.lib
> with "conta
43 matches
Mail list logo
