gnupic: Thread: Traffic lights as extreme feedback device controlled by a PIC via USB

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just put a project of mine using gputils on github:
Project page: https://github.com/holgero/XFD
Wiki:         https://github.com/holgero/XFD/wiki
The license is GPLv3.

I believe it may be interesting for others because it contains an USB
HID firmware implementation that needs only gpasm (no need for SDCC,
MPASM or C18-compiler). The implementation is done for both pic18f2550
and pic18f13k50.
The second thing worth mentioning is that it is controlled by a java
application on the host side (and the host software works on Linux and
Windows). There is no need to install any drivers or similar on the host
side.

Best regards,
Holger.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAeZkAACgkQHdk+97UOUam2cwCggcX8vZDCWR59eLNOkP+PPHuD
260AniLRl1pVUErFJ0d7nVNsoH+nFF61
=3awh
-----END PGP SIGNATURE-----

Hi Holger,

Full disclosure: I'm the current libusb maintainer.

Holger Oehm wrote:
> an USB HID firmware implementation that needs only gpasm

A gpasm USB firmware is really really awesome! Thank you for publishing!

Get your product id here: http://wiki.openmoko.org/wiki/USB_Product_IDs


I have reservations against using the HID bDeviceClass however.

The device is not a Human Input Device, so it is a poor fit to use
all the operating system code for handling input devices. I know
how easy it is to be lured into the HID mess because of Windows, but
if anything other than Windows matters in a project then there are
significantly better alternatives.

The HID class is not very portable and not very convenient, neither
for host software nor firmware. It is optimizing specifically for
Windows and if the kernel input subsystem is not intended to be used
with the device then HID seems like crossing the bridge to get water.

See also
http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass


> controlled by a java application on the host side
> (and the host software works on Linux and Windows).

Note that it is since Mac OS X 10.6 (or is it 10.7?) no longer
possible to communicate with HID class devices using libusb. On
previous versions it works, after writing a special codeless kext and
rebooting the system.

For cases where a given HID class device is unchangeable I strongly
recommend using the C library HIDAPI, which uses native HID APIs.
(Windows, Linux, Mac OS X, and BSD)

But when you can influence the firmware then I very strongly
recommend to skip the HID class and instead use the vendor specific
bDeviceClass, 0xff.

This allows completely effortless programming from userspace, with or
without libusb, on Linux, Mac OS X, and BSD. No drivers involved.


> There is no need to install any drivers or similar on the host side.

This is true also with a vendor specific bDeviceClass, on all
systems, including Windows, starting with Windows 8.

Windows XP (sp3 IIRC) and later sends a request for string descriptor
number 0xee the first time that a device is attached.

Microsoft has created this extension to standard USB descriptors
called MOD, Microsoft Operating system Descriptor. The string
descriptor contains structured information which together with one
type=vendor destination=device control request will tell Windows
which driver should be used for the device. Microsoft calls a
device which implements the descriptor and the control request per
their extension a "WinUSB Device" [1] and for such devices Windows
loads and binds the driver automatically, without any user
interaction. Plug and play for USB finally also on Windows.

The requirement for this to work is that the driver that the device
says should be used has been set up correctly in the Windows registry
- note driver, not device. The setup is needed only one time per
driver, regardless of how many different devices use that driver.

Windows 8 ships with Microsoft's WinUSB driver (for userspace USB
communication) set up correctly for this out of the box. This means
that if your device has the correct 0xee string descriptor and the
correct control request, according to the Microsoft USB extension,
meaning that it is a WinUSB device, then WinUSB is loaded and bound
to your device immediately and transparent to the user when the
device is plugged in to a Windows 8 system.

Previous Windows versions (since XP sp3 IIRC) can be set up to have
the same user experience as Windows 8 comes with out of the box. In
the libusb community we have some little hope that Microsoft will
sometime roll out this WinUSB driver setup as part of a Windows
Update also for the older systems. That would be very nice. Meanwhile
it is easy to do manually or in an application, thanks to the libwdi [2]
project.

libusb-1.0 works on Windows since some time, with all devices that
use the WinUSB driver. (Please don't confuse libusb-1.0 with the
separate libusb-win32, libusbK, and libusbx projects. libusb-1.0
is the continuation of the original libusb-0.1 project, and is
actively developed.) libusb does not care *how* the WinUSB driver
was bound to a device, the Microsoft OS descriptor and control
request is not required for libusb to work, only for the WinUSB
driver to be loaded automatically.

The libusb-1.0 API is (like the libusb-0.1 API) intended for USB
level communication with devices which have no driver in the kernel,
meaning that the API offers primitives such as
libusb_control_transfer(), libusb_interrupt_transfer(), and so on,
which all device classes build on, and which are very easy to use.
It's a lot simpler than dealing with the HID class encapsulation and
restrictions for what can be done over USB.

One of the authors of WinUSB support in libusb-1.0 is also the author
of the libwdi project. He invented and uses the term "WCID device"
instead of using Microsoft's term "WinUSB Device". (He doesn't want
to work with me and libusb anymore, and strongly promotes his fork
libusbx.) I prefer Microsoft's terminology "WinUSB Device" since it
is after all their extension. Anyway, on the libwdi wiki [3] there is
more detail about how WinUSB Devices work, and links to Microsoft's
authoritative documentation.


IMO, bDeviceClass=0xff plus WinUSB Device Microsoft extension is an
excellent alternative to using HID class, because the device becomes
truly portable, and developing both host software and device firmware
allows working directly with the USB layer instead of caring about
limits introduced by the HID class.


Kind regards

//Peter


[1] http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799(v=vs.85).aspx
[2] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Main_Page
[3] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=WCID_devices

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter,

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... :-). (I also applied at Microchip for a PID, but got no
answer from them either.) And special thanks for calling it awesome, of
course! :-)))

> I have reservations against using the HID bDeviceClass however.

Yes, you are right, of course I did this because of Windows only. 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. So I wrote the HID descriptor for
my device using that page. It's not as if anything would really make use
of the description, but it works for me. 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 (on
Linux I added a udev rule for the device to get the permissions right)).
The only drawback is that this HID stuff is a little bit bloated for no
real benefit (other than enabling the device to run on Windows out of
the box).

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. 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?

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? I
doubt that I can manage to make this as easy to use as it is right now.
Additionally Windows 8 is not that wide spread at the moment that I
could assume that this WinUSB driver was already present, right?

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 on my PC at work or
a Mac being present at home). Would that be all right with you?

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?

Best Regards,
Holger.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAep24ACgkQHdk+97UOUanFAQCZAa2wguqcg6xtPg0W2UB3qWve
Er8AnjNmP3ucT5W26YT/gTrOWRxSVila
=BqCp
-----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter!

Thank you very much for discussing this with me!

> 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. :)

Well I didn't write the firmware from scratch, it is derived from an
implementation by Bradley A. Minch (see CREDITS[1]). I asked him for
permission to publish my project under GPLv3 and under my name.
So I am not sure if I am free to choose another license for the project.
But of course I can ask him again if he would agree to other licenses,
too. I would like to stick to something recognized by the FSF and
compatible with GPL[2] (e.g. the Apache License, Version 2.0[3], would
that work for you?).

> step 0: install java ;)

Ah, that is not necessary on a system I own (or where I have sufficient
permissions). ;)

> 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.

I should check out those bindings, that might be better than using JNA
to access libusb.so.

> 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.

I dont know if I want to go through the hassle to set up a cross
compiler for Windows, so a ready made binary were much easier. What
about that Zadig standalone driver installer? Could I point to that for
driver installation?
But if I have to make my own installer then Vista and up would be enough
for the Windows PCs I use.

> 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.)

I appreciate this information, I didn't know anything about WinUSB and
this MS USB extension descriptor.

And I think you convinced me now, switching to the vendor specific class
is the better option. I am going to change the firmware and it is on the
TODO list now (literally: [4]).

What remains to do for me is now:
1. change the firmware: change the device class, add the 0xee string
   and the descriptor that says that the device wants the WinUSB driver.
2. describe (for windows users) how to use that Zadig standalone
   driver installer.
Or better: configure libwdi to setup the WinUSB driver on
   Windows Vista and Windows 7, setup my Linux box to cross-compile
   it and create an installer. In the java application check if the
   driver is present and if not run that installer.
3. Get rid of that HID descriptor!

Would that sum it up?

Best regards,
Holger.


[1]: https://github.com/holgero/XFD/blob/master/CREDITS
[2]: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
[3]: http://www.apache.org/licenses/LICENSE-2.0
[4]: https://github.com/holgero/XFD/blob/master/TODO
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAezq8ACgkQHdk+97UOUakKpQCfdL166i7utfGY3eXDHXLT/rAZ
3pAAoJJZ6/4FEgKOjhQhBpwb1bZQ98w3
=XZoN
-----END PGP SIGNATURE-----

Wow!  Thanks so much to both of you.

Holger -- I've been working on and off on a design for a shop oven for
solder reflow and powdercoating.  I realized a little while back that
I could reduce my parts count by using USB instead of a serial
interface, but haven't a chance to try to figure out the USB subsystem
to proceed from there.  Finding a good, basic implementation using
gpasm is a tremendous help to me.

Peter -- learning I can get a product ID for the oven is also terrific
news.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06.08.2012 19:23, Joe Pfeiffer wrote:
> Peter -- learning I can get a product ID for the oven is also terrific
> news.

And I can confirm that asking openmoko for a PID really works (and
within only a week)! Today my device got its own address: 1d50:6039.
Many thanks to openmoko!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAgEccACgkQHdk+97UOUanl9gCePhTW4LhrejoW7LN390dvxuMj
7bMAn1yXwpC+ez4C0cXh/fF0PQrYqNCj
=uBdX
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 05.08.2012 21:51, Holger Oehm wrote:
> What remains to do for me is now:
> 1. change the firmware: change the device class, add the 0xee string
>    and the descriptor that says that the device wants the WinUSB driver.
> 2. describe (for windows users) how to use that Zadig standalone
>    driver installer.
> Or better: configure libwdi to setup the WinUSB driver on
>    Windows Vista and Windows 7, setup my Linux box to cross-compile
>    it and create an installer. In the java application check if the
>    driver is present and if not run that installer.
> 3. Get rid of that HID descriptor!

ad 1.+3.: Done.

I created a branch named noHid [1] for the removal of the HID stuff from
the project. In that branch I changed the firmware to use the vendor
specific class (0xFF) and also added the string descriptor and the
compatibility descriptor stuff. This seems to work, as zadig[2]
recognizes the device as a WCID and also I can see in the windows
registry all of the described entries (CompatibleIDs contains that
USB\MS_COMP_WINUSB entry).

ad 2.: No success so far.

So far so good, but I cannot get zadig to install the WinUSB driver
successfully. Using the advanced option and turning the debug level to
debug I see that the driver installation complains about a file not
found (from my memory: it was something like
C:\usb_driver\Winusb_.....inf). But I could open the file in question
with an editor, it was there. I have no idea what went wrong.

I am kinda stuck there, do you think I should open an issue at libwdi[3]?

And for the option to include libwdi to automate WinUSB driver
installation: I understand that I need to have:
1. Windows DDK (download ISO image from MS, burn DVD, etc. etc.)
2. A cross compiler environment set up to compile it

And I don't see how I can integrate all that stuff into the CI build of
the project[4]. So I think I wont do that part. This of course means for
a user of the device on windows the usage experience will definitely be
somewhat worse than now (as long as WinUSB is not pre-installed).

Best regards,
Holger.

[1]: https://github.com/holgero/XFD/tree/noHid
[2]: https://github.com/pbatard/libwdi/wiki/Zadig
[3]: https://github.com/pbatard/libwdi/issues
[4]: http://travis-ci.org/#!/holgero/XFD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAlA1IACgkQHdk+97UOUak8/ACeJquQQq7DTOj2T2f05ILYBBN3
RykAn2WpNU4Vedid5aT2H152NZ2iZmfx
=a0ts
-----END PGP SIGNATURE-----

Hi Holger,

Holger Oehm wrote:
> > What remains to do for me is now:
> > 1. change the firmware: change the device class, add the 0xee string
> >    and the descriptor that says that the device wants the WinUSB driver.
> > 2. describe (for windows users) how to use that Zadig standalone
> >    driver installer.
> > Or better: configure libwdi to setup the WinUSB driver on
> >    Windows Vista and Windows 7, setup my Linux box to cross-compile
> >    it and create an installer. In the java application check if the
> >    driver is present and if not run that installer.
> > 3. Get rid of that HID descriptor!
> 
> ad 1.+3.: Done.
> 
> I created a branch named noHid [1] for the removal of the HID stuff from
> the project. In that branch I changed the firmware to use the vendor
> specific class (0xFF) and also added the string descriptor and the
> compatibility descriptor stuff.

Wow, OK, as the final test you could try a Windows 8 Preview
installation if Microsoft still make that available. It should
then be enough to simply plug the device in, to make it run.

How do you feel about the idea to make the generic USB stack a
separate project? I think it would be fantastic, and a very nice way
to spread gputils even wider in the industry if the license is also
less restrictive. (I very much think that it is worthwhile to make a
separate project even without changing the license.)


> ad 2.: No success so far.
> 
> So far so good, but I cannot get zadig to install the WinUSB driver
> successfully.

Huh - strange - that has always worked for me when other things
failed. If the device is attached, you have to manually select
'display attached devices' or somesuch in the menu, after that
it's literally just one click on the install button.

Ah - are you doing the system-wide COMP_WINUSB setup, or an explicit
setup for the device? I've so far only tried the latter.


> Using the advanced option and turning the debug level to
> debug I see that the driver installation complains about
> a file not found (from my memory: it was something like
> C:\usb_driver\Winusb_.....inf). But I could open the file in question
> with an editor, it was there. I have no idea what went wrong.
> 
> I am kinda stuck there, do you think I should open an issue at libwdi[3]?

Perhaps you can try one or two older versions of the zadig build? I
didn't use it for maybe a month or so, but the latest version at that
time worked for me, for device-specific driver installation.


> And for the option to include libwdi to automate WinUSB driver
> installation: I understand that I need to have:
> 1. Windows DDK (download ISO image from MS, burn DVD, etc. etc.)
> 2. A cross compiler environment set up to compile it

What is your development environment? Linux? Which distribution?
Or do you develop also on a Windows system?

Many Linux distributions already have a mingw cross-toolchain
packaged.

As for the DDK, it would be enough to download the ISO and mount it
using loopback, if you are on Linux. IIRC the needed files are
available directly, without having to install everything.


> And I don't see how I can integrate all that stuff into the CI build of
> the project[4].

Yes, adding a cross-toolchain may be tricky if you don't control the
CI system. :\


> So I think I wont do that part.

Well, maybe someone can help do it!


> This of course means for a user of the device on windows the usage
> experience will definitely be somewhat worse than now (as long as
> WinUSB is not pre-installed).

Hopefully doesn't have to happen. Let's see.


//Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter,

> How do you feel about the idea to make the generic USB stack a
> separate project? I think it would be fantastic, and a very nice way
> to spread gputils even wider in the industry if the license is also
> less restrictive. (I very much think that it is worthwhile to make a
> separate project even without changing the license.)

The modules in the project are already pretty much isolated. Therefore
if the license is not standing in your way, you can already use the
device folder alone and ignore the rest (or see it as an example for
host programs or as documentation). There is no real assembly into a
single artifact either, the folders more or less stand side by side and
the top level Makefile just runs make sequentially in the folders. This
means also that separating the modules into different projects would be
no problem at all. If you say it helps to have separate projects, I will
give it a try at the weekend. (Even if I am not sure how it helps).


> Perhaps you can try one or two older versions of the zadig build? I
> didn't use it for maybe a month or so, but the latest version at that
> time worked for me, for device-specific driver installation.

Yes, that did it! The previous version worked just fine and the device
now has its generic WinUSB driver. Now I can start to re-write the java
part for windows. Thanks for the tip!


> What is your development environment? Linux? Which distribution?
> Or do you develop also on a Windows system?

It is a Linux From Scratch[1], so it is pretty much my decision what to
include and what not (and my effort to get it to compile from sources).
My PC at home is setup to dual boot also a Windows 7 installation, but I
don't use that for development. (The only exception is that I recently
installed Java and Eclipse on it, to develop the windows part of the
host program for the device.) But I have no C compiler or similar
installed on my windows partition.


>> And I don't see how I can integrate all that stuff into the CI
>> build of the project[4].
>
> Yes, adding a cross-toolchain may be tricky if you don't control the
> CI system. :\

And having a working CI build is important (this is after all the
premise of the device! :-)).


> Well, maybe someone can help do it!

Yes, that would be great! I would certainly pull a automated windows
driver installation, if someone can contribute that.

Best Regards,
Holger.

[1]: http://www.linuxfromscratch.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAlAlORYACgkQHdk+97UOUanwOwCgkw3s/f5IrUZ/nzLz9p8uj/Gg
GPoAmKoe79Y+DuSQrmoD//8TKCN7KCo=
=eHhV
-----END PGP SIGNATURE-----