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

I hope to be able to start adapting it to my project within the next
couple of days -- one of the most interesting things that will come
out of that will be a good notion of how well it moves across
projects.

From my perspective, the license isn't important -- I'll be releasing
my code under the GPL anyway.  But I can certainly see an argument for
making libraries available under LGPL.

Peter Stuge writes:
>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
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>

Já Concluído.

Flávio Nunes



2012/8/10 Joe Pfeiffer ####@####.####

> I hope to be able to start adapting it to my project within the next
> couple of days -- one of the most interesting things that will come
> out of that will be a good notion of how well it moves across
> projects.
>
> From my perspective, the license isn't important -- I'll be releasing
> my code under the GPL anyway.  But I can certainly see an argument for
> making libraries available under LGPL.
>
> Peter Stuge writes:
> >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
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: ####@####.####
> >For additional commands, e-mail: ####@####.####
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>

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

Hi,

HID is now removed from the master branch in the repository. The device
has the vendor specific bDeviceClass 0xFF and is accessed on Windows and
Linux with the libusb 1.0 API.

I created a branch named 'hid' for the "old" implementation. (Uses the
HID.DLL on Windows and bDeviceClass HID. Also on Linux still libusb-0.1
is used on that branch.)

Best Regards,
Holger.

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

iEYEARECAAYFAlAlf/IACgkQHdk+97UOUalyyQCeMJNeK+E0KoP1XqMFZYGlrO0R
+TAAoI0JxGOUeSo1NF8zkBgSjK0qn6vI
=vLy5
-----END PGP SIGNATURE-----

Holger Oehm wrote:
> HID is now removed from the master branch in the repository. The device
> has the vendor specific bDeviceClass 0xFF and is accessed on Windows and
> Linux with the libusb 1.0 API.

On Mac OS X, and all BSD systems too! :)


//Peter

Joe Pfeiffer wrote:
> I hope to be able to start adapting it to my project within the next
> couple of days -- one of the most interesting things that will come
> out of that will be a good notion of how well it moves across
> projects.

Optimizing for that, making the code a library of sorts, is basically
why I suggest making it a separate project, or product if you will.


> From my perspective, the license isn't important -- I'll be releasing
> my code under the GPL anyway.  But I can certainly see an argument for
> making libraries available under LGPL.

My argument is for something even more permissive, such as MIT, BSD
2-clause or such. LGPL is still too restrictive for a proprietary
project developer to be able to use the code and contribute, then
it's fine to stay on GPLv3+. I'm not pushing this very hard, but I
do think it's worthwhile to consider. If it were my code I would
go for more permissive, anything embedded is already very niche, so
I think it's important to gather as many contributors as possible.


//Peter

Holger Oehm wrote:
> > 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).

The difference will only be very small, but the point would be to
focus on the USB code as a library to be used by other projects,
rather than focus on one project which uses the library, if that
makes sense. I'm absolutely not expecting you to do this, it's merely
an idea, but I think the work is very valuable, and the small change
of focus again is to make it super easy to reuse the code.


> The previous version worked just fine and the device now has its
> generic WinUSB driver.

All right!


> Now I can start to re-write the java part for windows. Thanks for the tip!

The libusb-1.0 bindings are https://github.com/trygvis/javax-usb-libusb1
but I guess you may have already found them. :)


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

Ok. Well yes then building a cross toolchain is a bit more effort,
but you could of course make use of some of the tools which were
created by other distributions. Gentoo for example has the 'crossdev'
tool which fully automates the building of a cross toolchain.

Source code: git://git.overlays.gentoo.org/proj/crossdev.git

Build a 32-bit MinGW toolchain: crossdev -t i686-mingw32
Build a 64-bit MinGW-W64 toolchain: crossdev -t x86_64-w64-mingw32


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

MinGW is also available as native compiler of course. Along with MSYS
you get bash, and a fairly decent GNU-like environment. Just MinGW is
enough to compile simple programs.


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

Hehe, yes. :)


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

I'm happy to cross build libwdi. What exactly do you need? Have a
look at the wdi-simple.c example from libwdi - is that already
enough?


//Peter

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

On 11.08.2012 02:51, Peter Stuge wrote:
> Holger Oehm wrote:
>> Now I can start to re-write the java part for windows. Thanks for the tip!
> 
> The libusb-1.0 bindings are https://github.com/trygvis/javax-usb-libusb1
> but I guess you may have already found them. :)

I just had a deeper look into that project, and decided against using
it. Anyway, I do not need most of the stuff that it offers, so the
current approach using JNA to access libusb-1.0 and picking only the
subset needed to send control messages to the device is good enough for now.

> I'm happy to cross build libwdi. What exactly do you need? Have a
> look at the wdi-simple.c example from libwdi - is that already
> enough?

I think so. (More like to many options :-)). To automate the driver
installation on Windows I can think of the following two options:

1. execute a new process from java, like a statically linked
wdi-simple.exe (?).

2. use JNA again to call functions from a shared library (libwdi.dll in
this case). This means to execute the same steps as wdi-simple.c does,
but in Java.

My preference would be 2., as that would give me more control in Java
over what is happening. So what I needed for this is a libwdi-32.dll and
a libwdi-64.dll that can be loaded from Java (32 bit or 64 bit
executable). This libwdi-xx.dll needs only to be able to complete the
installation of the WinUSB driver on Windows Vista and Windows 7.

I would add those libwdi binaries in the git repository and package them
within the jar file that is created during the build.

Then at run time, first load libusb.dll and try to access the device. If
that fails load libwdi.dll and use it to install the WinUSB driver. If
that is successful, re-try to access the device.

Does that sound to you as if it makes sense?

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

iEYEARECAAYFAlAmpIoACgkQHdk+97UOUamfzACfZ9ex/fT8PWXXJdd8tjWl7nFv
hXIAoJ5wjC/y52ANNPn/dE3MTfzVs0mA
=jzR3
-----END PGP SIGNATURE-----

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

Hi,

My next PIC project using gputils on github just became useful: An USB
boot loader firmware for PICs (specifically for the 18F13K50).

Project page: https://github.com/holgero/PicUsbBootloader
The license is Apache License, Version 2.0.

It is completely written in assembler and needs only gputils (gpasm and
gplink). Communication with the firmware is done as USB bulk transfers.
The format and the commands are compatible with fsusb[1], which in turn
claims to be compatible with the "PICDEM Full Speed USB" demo board from
Microchip.

Best Regards,
Holger Oehm.

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

iEYEARECAAYFAlBLnBkACgkQHdk+97UOUaknXQCgkLyabca2aeP+SwkI05HDB7RJ
K4AAn3+oRr0jBKz686ngV3HhOqsnGUJT
=WVUG
-----END PGP SIGNATURE-----

Wow!  Releasing the code you're writing is a fantastic service to the
community!

Holger Oehm writes:
>
>My next PIC project using gputils on github just became useful: An USB
>boot loader firmware for PICs (specifically for the 18F13K50).
>
>Project page: https://github.com/holgero/PicUsbBootloader
-- 
Joseph J. Pfeiffer, Jr., Ph.D.                 http://pfeifferfamily.net/
1440 Tierra del Sol Dr                         575.525.2764 (H)
Las Cruces, NM 88007                           575.496.3501 (C)