On Mon, Jun 18, 2012 at 6:08 PM, Jach Fong jf...@ms4.hinet.net 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
On Sun, Jun 17, 2012 at 10:33 PM, Ellis Whitehead
ellis.whiteh...@gmail.com 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:
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
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
there may
On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard p...@akeo.ie 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
On Mon, Jun 18, 2012 at 10:49 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard p...@akeo.ie 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
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, no
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
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 let
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 the
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
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 our
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
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 to
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 before, it
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 the
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 way
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!
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 xusb as
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 Tue, Jun 19, 2012 at 8:08 AM, Markus li...@neuronenwerk.de 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
21 matches
Mail list logo
