Subject:
Re: Traffic lights as extreme feedback device controlled by a PIC
via USB
From:
Peter Stuge ####@####.####
Date:
5 Aug 2012 17:38:37 -0000
Message-Id: <20120805173833.30140.qmail@stuge.se>
Hi Holger!
Holger Oehm wrote:
> thank you for your long answer and also thanks for the hint with
> openmoko.org. Actually, I am already waiting for their answer to my
> application... :-).
All right! It will probably not take very long.
> And special thanks for calling it awesome, of course! :-)))
I think it is something that has been missing for a long time; a
minimal gpasm USB stack. I would like to suggest that you make it a
completely separate project, and to make XFD use it as a library. I
think it's a very useful project for open source devices.
If you had picked a less restrictive license (MIT, BSD, etc) then I
believe that you would also see many commercial products use the
stack, and perhaps get some contributions back from those users.
The license is entirely your choice and I respect the GPL, but for
embedded it unfortunately means that the whole project is not usable
for professional users who develop proprietary products, and for
things I do I like to try to include them too. :)
> Yes, you are right, of course I did this because of Windows only.
If Windows is your primary market then it's a good and wise choice.
(But then the portability of Java is also somehow lost.)
> But when I looked into the HID specification I saw that there were
> at least usages that were not such a bad fit for the device: There
> is this "LED Page (0x08)" in the "HID Usage Tables" which describes
> the device (apart from the exact colors) quite nicely.
Very true! The problem is more that almost nothing of all the HID
usage table complexity is exposed in userspace input subsystem APIs. :\
Even on Linux, where there is even a dedicated LED subsystem, I don't
believe that this works transparently, so the host program is doomed
to handle all the HID class communication on it's own.
> And it is fairly easy to use: (step 1: plug-in the device, step 2:
> download the jar file, step 3: run java with the jar file and the
> url of the build server as arguments
step 0: install java ;)
> (on Linux I added a udev rule for the device to get the permissions
> right)).
I would encourage you to look at HIDAPI. It calls native HID APIs on
Windows and Mac OS X, and can be built to use hidraw on Linux. Then
you don't need a udev rule.
Devices with bDeviceClass=0xff usually end up with permissions on
Linux that allow a generic usb, plugdev, or console group to access
them without udev rule - but details vary slightly between
distributions.
> I have to admit though, that I completely forgot about Macs. It looks to
> me, that changing the device class would involve quite some effort and,
> frankly, I am not sure if it is worth that.
Moving from HID to vendor specific would primarily consist of taking
things away. :)
> I just published the project and I cant know if there will be any
> demand at all from Mac users for it. Everybody else should be just
> fine (as long as HID.DLL or libusb.so are present in their systems),
> or am I missing something here?
I think that's correct. On a side note libusb.so is the libusb-0.1
library, an API which has been deprecated for very many years
already. There are Java bindings also for the libusb-1.0 API.
> Also I am not sure if I understood the libwdi project pages correctly,
> but it seems that I would need to cross-compile the stuff there and ship
> shared libraries on windows together with the java application, right?
It depends on how much of libwdi you would like to use, and on which
versions of Windows you require compatibility with. The older Windows
the more work. :)
> I doubt that I can manage to make this as easy to use as it is right now.
No, I believe the plug and play user experience would actually become
even better than with the current solution, not only seamless but
also truly cross-platform. For the whole shebang with compatibility
back to XP the download will indeed grow, but not by extremely much.
> Additionally Windows 8 is not that wide spread at the moment that I
> could assume that this WinUSB driver was already present, right?
The WinUSB driver is included in every Windows since Vista, but it is
only in Windows 8 that Microsoft has out-of-the-box support for
WinUSB Devices with the special descriptor+control request. Ie. on
older versions they already shipped the driver, but they didn't have
it configured so that it would be automatically bound to any devices.
(Even though they have been asking the device for the special info
ever since XP sp3!)
libwdi can easily configure older systems to support WinUSB Devices.
It can be built both with and without the WinUSB driver included in
the library. If built with the driver included then it'll work from
XP and up. If built without, then the driver needs to be on the
system already; ie. will work from Vista and up.
> So, at this time I would rather leave the HID description in the
> firmware as it is and wait a bit (either until Macintosh users demand
> to be able to use the device or Windows 8 being present onery my PC
> at work or a Mac being present at home). Would that be all right with
> you?
You decide this of course! :) I just wanted to share the info about
libusb-1.0, WinUSB and WinUSB devices since it is not so widely known
yet, and since it really is a huge step forward in both user
experience on Windows and in portability for devices - while at the
same time allowing to use much more of the broad spectrum of
communications that USB offers. (The WinUSB driver doesn't support
isochronous transfers, and has a few other odd limitations, but it's
still a huge step up from HID.)
> BTW: The need for permissions on Linux would not go away when I no
> longer need libusb to disconnect the kernel HID driver, or would it?
It depends on the distribution - but yes, on some distributions it
would, because the desktop user often gets access to local devices.
Unfortunately I don't have the data to give a quick overview on what
happens where. :\ I'd appreciate any info anyone has about this!
//Peter
