Smalltalk › Instantiations

LibUSB Interface

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Louis LaBrunda

LibUSB Interface

Hi All,

Seth and I will be posting to this thread to describe and in a small way document our efforts to create a VA Smalltalk interface to the LibUSB system. LibUSB is a library written for Linux that has been ported to Windows. We are both working on Windows in VA Smalltalk V8.6.2 (in a previous post I fat fingered and typed v8.5.2 not 8.6.2, that post explains why v8.6.2 is needed). Our interface binds to libusb-1.0.20. You can get the binaries here: http://libusb.info/ (Downloads -> Latest Windows Binaries), I got my DLL from the MS32 folder of the zip file. We hope the interface will work with 32 bit Windows and Linux and with the new 64 bit VM when it is released. Seth's 64 bit tests look good so far.

In the other thread I mentioned that we have added instance and class variables to the OSStructure sub-classes we define. We added many instance variables and a few class variables. I will explain how some of them are used now and probably others in future posts.

LibUSB requires programs initialize a connection to the library. Initializing returns a context. We map the context in KscLibUsbContext. We added a class variable called #Default. #Default holds an instance of KscLibUsbContext that is the current context. KscLibUsbContext>default answers (or creates) the current context. In this way any time the current context is needed you can get it with:

KscLibUsbContext default.

LibUSB has structs for USB devices and a description of the device. We use KscLibUsbDevice and KscLibUsbDeviceDescriptor to map these structures. KscLibUsbDevice is basically a pointer used to identify the device in LibUSB. KscLibUsbDeviceDescriptor contains some information that describes the device. We added context and deviceDescriptor instance variables to KscLibUsbDevice to hold the context the device (pointer) is referenced in and a description (KscLibUsbDeviceDescriptor) of the device. The description allows one to find a USB device by things like vendor and product codes. We have methods that help search a list of devices to find the one you want to talk to.

I hope this is a good start. Let us know if it needs to be more or less detailed.

It turns out that I have time to work on this during the week and Seth has time on the weekend. I will probably post a version to VA Smalltalk Goodies with my changes for the week on Friday night and Seth will post his weekend changes on Sunday. It is a work in progress, so don't expect too much too soon. But so far we can connect to the library, list the USB devices and get some information about them. We hope to be able to send and receive data to and from a USB device soon.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Louis LaBrunda

Re: LibUSB Interface

A little more about LibUSB context and our KscLibUsbContext>default and class variable Default. LibUSB wants to be initialized with the libusb_init function. You can call this function with a zero/null and be using what LibUSB calls their default context. If you call libusb_init with a pointer to some memory it will store a pointer to a new context. This is what we do and what we call out default context. They are two different contexts. When using most of the methods we will be creating, you won't care. Hopefully, we will be able to wrap LibUSB enough that you won't need to do anything with the context.

I just want to be clear that what LibUSB calls a "default context" in their documentation and what we call our default are both contexts but not the same one.

Lou

Seth Berman

Re: LibUSB Interface

Hi All,

LibUSB Update for the week.

Lou added some handy APIs to find a specific usb device by vendorId, productId or a name pattern.
For example, if I wanted to find all the playstation 3 controllers that were connected to my machine, I could just type

KscLisbUsbContext default devicesNamed: '*Playstation*3*'

which would return a sequenceable collection of 0 or more usb device objects.

We were getting far enough along that we didn't want to proceed any further without writing more formalized tests so

I reworked the project into 3 applications
KscLibUsbApp - Native Binding Interface App
KscLibUsbExamplesApp - Hold various examples...I will be using this to build a PS3 controller that sends events to the CommonWidgets layer of the product to get game controller support.
TestKscLibUsbApp - SUnit Test Suite

There are several categories of communication with a USB device...you would want to communicate with a USB mass storage device differently than a game controller so I'm in the middle of

defining a transfer request builder that constructs a specific type of transfer request which is then submitted.

LibUSB has 2 models for communication...synchronous and asynchronous.
The async version, while harder to implement, will be more pleasurable to work with because you will get callbacks based on transfer events and is non-blocking.
The sync version will require using a separate process to communicate with the device in a way that doesn't block all the smalltalk processes since it will block and wait once you submit a transfer request.

It's coming along nicely and should be fun to play with if we get enough examples.

-- Seth

On Thursday, February 18, 2016 at 11:07:00 AM UTC-5, Louis LaBrunda wrote:

A little more about LibUSB context and our KscLibUsbContext>default and class variable Default. LibUSB wants to be initialized with the libusb_init function. You can call this function with a zero/null and be using what LibUSB calls their default context. If you call libusb_init with a pointer to some memory it will store a pointer to a new context. This is what we do and what we call out default context. They are two different contexts. When using most of the methods we will be creating, you won't care. Hopefully, we will be able to wrap LibUSB enough that you won't need to do anything with the context.

I just want to be clear that what LibUSB calls a "default context" in their documentation and what we call our default are both contexts but not the same one.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi All,

Sorry, no Friday LibUSB update this week. I was experimenting and left things in a bad way. Hopefully Seth and I will figure out what we want to do to fix things or revert back to the way things were before I messed them up. I expect that Seth will post a new and working (at least all the examples will work) late Sunday or early Monday.

There is a Microsoft program called USBView that we use to see all the USB devices connected to a computer. It displays a lot of the information that we can get with LibUSB and we use it to check what we have done. There was a little mystery in that USBView displayed some vendor/manufacturer for my X10 controller device that we couldn't get through LibUSB. I finally realized that USBView had a built in USB vendor database. The device wasn't suppling information that it should have. With some research I found an open source USB vendor database. I wrote some code to read the database and put it into a form that we can use in Smalltalk. Since the USB vendor database isn't LibUSB specific, we are going to keep it as a separate project (App) for the time being at least. I haven't posted it to VAST Goodies yet but I plan to.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi Guys,

As hoped, Seth has posted his latest changes to VAST Goodies. I haven't looked at it yet but I will soon. He has fixed what I broke and ran out of time playing with.

Some of the LibUSB functions require a handle that you obtain from LibUSB (with an open function call). Sometimes LibUSB can't return a handle. Seth created a method called #tryOpen: (patterned after the Ruby LibUSB interface) that would get a handle, pass it into the block that would use it as needed and then #tryOpen: would free the handle. If getting or using the handle failed, an exception is signaled. This lead to code that looked like this:

	self tryOpen: [:handle |
		^handle stringDescriptorAt: self deviceDescriptor iManufacturer].
	"If we do fail to get a handle, we return an empty string."
	^''

I didn't like the look of this too much so I tried to this:

	^self tryOpen: [:handle | handle stringDescriptorAt: self deviceDescriptor iManufacturer] onError: [''].

This broke this put things in a loop and I ran out of time before I could fix it. Seth realized that with the onError block we didn't need to call it tryOpen: because the method covers all cases of success and failure. So, we now have this:

	^self
		open: [:handle | handle stringDescriptorAt: self deviceDescriptor iManufacturer]
		onError: ['']

The reason LibUSB sometimes can't open a handle seems to do with drivers. USB devices have their own driver and can have more than one driver. Not just newer versions of a driver but different drivers. That is the case with my X10 Controller. The X10 Controller driver that Windows normally has some how doesn't let LibUSB answer a handle on an open function call. I found another driver that claims to be compatible with LibUSB, it seems to be as I can now get a handle. Things are better but not great as the device itself (or maybe a driver bug) doesn't answer the string that names the manufacturer.

This brings us to the USB vendor database. It seems that other interfaces to LibUSB like Ruby's include some form of USB vendor database. So, we will too. I will be working on that this week. In the code above where the error block returns an empty string, we will replace it with a call to get the information from the USB vendor database. We will try to have a version of the USB vendor database built in and also allow users of our LibUSB interface to optionally supply later versions of the USB vendor database that we will load a start up.

Well that's it for now, thanks for reading.

Lou

On Saturday, February 27, 2016 at 1:23:50 PM UTC-5, Louis LaBrunda wrote:

Hi All,

Sorry, no Friday LibUSB update this week. I was experimenting and left things in a bad way. Hopefully Seth and I will figure out what we want to do to fix things or revert back to the way things were before I messed them up. I expect that Seth will post a new and working (at least all the examples will work) late Sunday or early Monday.

There is a Microsoft program called USBView that we use to see all the USB devices connected to a computer. It displays a lot of the information that we can get with LibUSB and we use it to check what we have done. There was a little mystery in that USBView displayed some vendor/manufacturer for my X10 controller device that we couldn't get through LibUSB. I finally realized that USBView had a built in USB vendor database. The device wasn't suppling information that it should have. With some research I found an open source USB vendor database. I wrote some code to read the database and put it into a form that we can use in Smalltalk. Since the USB vendor database isn't LibUSB specific, we are going to keep it as a separate project (App) for the time being at least. I haven't posted it to VAST Goodies yet but I plan to.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi Guys,

I have been working on including a USB vendor database (http://www.linux-usb.org/usb-ids.html) in our LibUSB interface. The data is in a fairly simple flat file called usb.ids (the tabs are important). The latest version is built into our interface, so unless a new version becomes available and you need it, there is nothing to do. If you do need a later version, you can point to it from the ini file with an entry like this:

[USB Vendors]

UsbVendorsPath=c:\VA Smalltalk V8.6\images\KscTestLibUsb\usb.Zip

Notice the file can be zipped or unzipped and the name doesn't need to have a zip extent even if it is zipped. The code will find the file and figure that out and parse it into the form we need.

I'm trying to decide how much error handling I should include for the code that reads the file. I can trap errors (like the file wasn't where the ini file says it is and things like that) and use the default database. But I'm inclined to let the error cause a halt because you probably want to know about the error and fix it or remove the ini file entry. This is less work for me but I guess an argument could be made for a case where your program was distributed and working well and something on the user site changes and the program no longer works and the user doesn't know how to fix it.

So, what does everybody think?

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi All,

I uploaded a new version last night. I added the support for the vendor database previously mentioned. The latest available version of the vendor database is built into the interface. KscLibUsbDevice>manufacturer and KscLibUsbDevice>product ask the device for the manufacturer and product information respectively. If there is any problem obtaining the information, they turn to the vendor database.

You can supply a newer version of the vendor database by pointing to it in the Ini file like this:

[USB Vendors]

UsbVendorsPath=c:\VA Smalltalk V8.6\images\KscTestLibUsb\usb.Zip

[USB Vendors]

UsbVendorsPath=c:\MyProgramFolder\usb.ids

The file can be zipped or unzipped and the name can be anything and doesn't need to have a zip extent even if it is zipped. The code will find the file and figure that out and parse it into the form we need.

At this point errors cause the program to crash. I assume the error is of the kind (like a typo in the file path) that are caught and fixed in early testing. I'm open to adding more error recovery but I need convincing.

Lou

On Tuesday, March 1, 2016 at 3:46:51 PM UTC-5, Louis LaBrunda wrote:

Hi Guys,

I have been working on including a USB vendor database (<a href="http://www.linux-usb.org/usb-ids.html" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;">http://www.linux-usb.org/usb-ids.html) in our LibUSB interface. The data is in a fairly simple flat file called usb.ids (the tabs are important). The latest version is built into our interface, so unless a new version becomes available and you need it, there is nothing to do. If you do need a later version, you can point to it from the ini file with an entry like this:

[USB Vendors]
UsbVendorsPath=c:\VA Smalltalk V8.6\images\KscTestLibUsb\usb.Zip

Notice the file can be zipped or unzipped and the name doesn't need to have a zip extent even if it is zipped. The code will find the file and figure that out and parse it into the form we need.

I'm trying to decide how much error handling I should include for the code that reads the file. I can trap errors (like the file wasn't where the ini file says it is and things like that) and use the default database. But I'm inclined to let the error cause a halt because you probably want to know about the error and fix it or remove the ini file entry. This is less work for me but I guess an argument could be made for a case where your program was distributed and working well and something on the user site changes and the program no longer works and the user doesn't know how to fix it.

So, what does everybody think?

Lou

Richard Sargent

Re: LibUSB Interface

Administrator

On Saturday, March 5, 2016 at 8:20:45 AM UTC-8, Louis LaBrunda wrote:

Hi All,

I uploaded a new version last night. I added the support for the vendor database previously mentioned. The latest available version of the vendor database is built into the interface. KscLibUsbDevice>manufacturer and KscLibUsbDevice>product ask the device for the manufacturer and product information respectively. If there is any problem obtaining the information, they turn to the vendor database.

You can supply a newer version of the vendor database by pointing to it in the Ini file like this:

[USB Vendors]
UsbVendorsPath=c:\VA Smalltalk V8.6\images\KscTestLibUsb\usb.Zip

or

[USB Vendors]
UsbVendorsPath=c:\MyProgramFolder\usb.ids

The file can be zipped or unzipped and the name can be anything and doesn't need to have a zip extent even if it is zipped. The code will find the file and figure that out and parse it into the form we need.

At this point errors cause the program to crash. I assume the error is of the kind (like a typo in the file path) that are caught and fixed in early testing. I'm open to adding more error recovery but I need convincing.

As long as the error says something like "cannot read the file", it's sufficient to crash. (e.g. self error: 'cannot read vendor database file').

It's always a good idea to detect "expected" errors and report them in a meaningful way. And, you have to admit, getting a file name wrong is certainly the most expected error. :-)

Lou

On Tuesday, March 1, 2016 at 3:46:51 PM UTC-5, Louis LaBrunda wrote:
Hi Guys,

I have been working on including a USB vendor database (<a href="http://www.linux-usb.org/usb-ids.html" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;">http://www.linux-usb.org/usb-ids.html) in our LibUSB interface. The data is in a fairly simple flat file called usb.ids (the tabs are important). The latest version is built into our interface, so unless a new version becomes available and you need it, there is nothing to do. If you do need a later version, you can point to it from the ini file with an entry like this:

[USB Vendors]
UsbVendorsPath=c:\VA Smalltalk V8.6\images\KscTestLibUsb\usb.Zip

Notice the file can be zipped or unzipped and the name doesn't need to have a zip extent even if it is zipped. The code will find the file and figure that out and parse it into the form we need.

I'm trying to decide how much error handling I should include for the code that reads the file. I can trap errors (like the file wasn't where the ini file says it is and things like that) and use the default database. But I'm inclined to let the error cause a halt because you probably want to know about the error and fix it or remove the ini file entry. This is less work for me but I guess an argument could be made for a case where your program was distributed and working well and something on the user site changes and the program no longer works and the user doesn't know how to fix it.

So, what does everybody think?

Lou

Louis LaBrunda

Re: LibUSB Interface

In reply to this post by Louis LaBrunda

Hi LibUSB Followers,

I just posted the latest version to VAST Goodies. It includes the latest version of the Vendors database built in. It also now has the ability to load a newer version in GZip format (along with being able to load it as a flat text file or in regular Zip format). The vendor database is supplied as both a flat file and a GZip file here: http://www.linux-usb.org/usb-ids.html.

For some reason unzipping the GZip file is very slow. I haven't had time to figure out why. So, until I do, it is best to use the flat file or a regular Zip of the flat file. But since the internal Vendor database is up to date, there is no need for either.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi LibUSB Followers,

On Friday, March 11, 2016 at 4:30:41 PM UTC-5, Louis LaBrunda wrote:

Hi LibUSB Followers,

I just posted the latest version to VAST Goodies. It includes the latest version of the Vendors database built in. It also now has the ability to load a newer version in GZip format (along with being able to load it as a flat text file or in regular Zip format). The vendor database is supplied as both a flat file and a GZip file here: <a href="http://www.linux-usb.org/usb-ids.html" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.linux-usb.org%2Fusb-ids.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH3st7QANUBlGThegeM_DOHdv-p-g';return true;">http://www.linux-usb.org/usb-ids.html.

For some reason unzipping the GZip file is very slow. I haven't had time to figure out why. So, until I do, it is best to use the flat file or a regular Zip of the flat file. But since the internal Vendor database is up to date, there is no need for either.

Lou

I have solved the mystery as to why unzipping the GZip file is very slow. I was unzipping the entire file at once with GzipReadStream>contents, which is an acceptable thing to do. The #contents method calls #upToEnd, which is also fine. The trouble is in #upToEnd, which inflates (unzips) one byte at a time. That is very slow. I rewrote the method (see below and attached file) to inflate 16k bytes at a time, could probably be more but that seems like a good number. The result is at least 100 times faster.

Lou

upToEnd
	"Answer the unzipped contents of the input stream."
	| aByteArray outPutStream bytes |

	aByteArray := ByteArray new: (input size * 2).
	outPutStream := WriteStream on: aByteArray.

	[
		bytes := self next: 16384.
		self atEnd.
	] whileFalse: [outPutStream nextPutAll: bytes].

	^outPutStream contents.

upToEnd.st (370 bytes) Download Attachment

Louis LaBrunda

Re: LibUSB Interface

In reply to this post by Louis LaBrunda

Hello Everyone,

After a couple of weeks of little progress this last week has seen some success. Seth won't be able to work on LibUSB this weekend, so I won't post the current version unless someone asks for it. I will continue to work on it this coming week and post a new version late Friday or early Saturday.

I have been working on talking to my X10 CM19a USB transceiver (you can buy one here https://www.x10.com/x10-home-automation/interfaces/cm19a.html). If you look around that site you can see the home automation devices that the CM19a can control. The CM19a talks to a https://www.x10.com/pat02-16-channel-transceiver.html that passes the commands into your house electrical wiring. Then devices like https://www.x10.com/pam02-3-pin-grounded-appliance-module-with-ag.html control things like lights an such that you plug into it. There are also hand held remotes https://www.x10.com/x10-pro/controllers/phr03-wireless-rf-remote-control.html that perform a similar function as the CM19a.

As I said the X10 CM19a is a USB transceiver meaning it can both send and receive signals. I am now able to use our LibUSB interface to send commands to the CM19a that turn X10 devices on or off. I am also able to read data from the CM19a when you use the hand held remote to send commands to devices and with that data I can tell what 10 command was sent.

This process is actually easier than the time it took me to do would indicate. I used the synchronous functions of the LibUSB interface because they are simpler than the asynchronous functions and still meet my needs.

The trouble was with the X10 CM19a device, drivers and USB ports. The CM19a only claims to support USB 1 and 2 but I thought USB 3 would dumb down when a USB 1 or 2 device is connected. I don't know whose problem it is but the device didn't like being plugged into a USB 3 port. There are a few drivers that claim to work with the CM19a. They work to varying degrees. The one that works the best with LibUSB is the libusbK driver that you can use the Zadig USB driver installer to install. Between port problems and driver problems, it took me a while to try enough combinations to get thing working.

Now that I can talk to the X10 CM19a I am going to write a small GUI program to send commands to it. I think I will include a window where I will display the commands it sees from the hand held remote. I may eventually include a means to send commands at a given time. This program will server as a working program and an example on how to use the LibUSB interface.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hello Everyone,

This was a productive week. Mostly, I worked on a GUI program to control an X10 CM19a USB Transceiver. See my previous post for links and other information about the device. A good first pass at the program is done. It can send all the common commands like: On, Off, Bright, Dim, AllOn and AllOff. It can also send commands at a given time of day and reschedule them for another day. There is also a window for viewing commands sent by a hand held remote. You can download the VA Smalltalk apps from VAST Goodies.

I also made progress with the LibUSB interface. I implemented a method to send and receive data to and from the X10 CM19a USB Transceiver. I also implemented a few commands that are probably not needed because Smalltalk objects are much better than DLL functions and can hold onto information that these functions can retrieve again from LibUSB but I added them anyway for completeness.

I also fixed some potential bugs in our interface that better handle unexpected return values from the LibUSB DLL.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi Everyone,

It has been a while since we updated our LibUSB project. I just put the latest on VAST Goodies. The change log shows what's new, mostly some new methods that call LibUSB functions that didn't have any methods that called them.

I also posted a project that contains my class that puts and manages an icon in the Windows system tray. This class is used by another project I posted that controls an X10 CM19a USB Transceiver. This is a small GUI program that sends command to the X10 CM19a USB Transceiver to control (turn on and off) X10 devices. I post it as an example of how to use some of the LibUSB synchronous functions.

Lou

Louis LaBrunda

Re: LibUSB Interface

Hi All,

Still nothing new for our LibUSB project (Seth and I have been busy with other stuff). It is complete enough that I have been able to use it for my X10 CM19a USB Transceiver controller project. Most if not all (I have some code that I use to help with packaging that wouldn't outside of my environment) of the source is available on VAST Goodies. There is code in the program to send and receive data from the X10 CM19a USB Transceiver which serves as an example of how to use at least a part of our LibUSB interface.

You can view the help file for my controller program here: KscX10Controller Help. You can download the latest install file here: KscX10ControllerInstallV1_04.msi. Of course you need an X10 CM19a USB Transceiver for the program to be of any use. There is a link in the help file to the X10 web site if you are interested.

Hopefully Seth and I can get back to finishing the asynchronous functions of LibUSB soon.

Lou

On Friday, May 20, 2016 at 4:34:56 PM UTC-4, Louis LaBrunda wrote:

Hi Everyone,

It has been a while since we updated our LibUSB project. I just put the latest on VAST Goodies. The change log shows what's new, mostly some new methods that call LibUSB functions that didn't have any methods that called them.

I also posted a project that contains my class that puts and manages an icon in the Windows system tray. This class is used by another project I posted that controls an X10 CM19a USB Transceiver. This is a small GUI program that sends command to the X10 CM19a USB Transceiver to control (turn on and off) X10 devices. I post it as an example of how to use some of the LibUSB synchronous functions.

Lou

Louis LaBrunda

Re: LibUSB Interface

The program can send X10 commands at a given time. It keeps a log of the commands sent and when. You can view the help file for my controller program here: KscX10Controller Help.

You can download the latest install file here: KscX10ControllerInstallV1_05.msi. Of course you need an X10 CM19a USB Transceiver for the program to be of any use. There is a link in the help file to the X10 web site if you are interested.

Hopefully Seth and I can get back to finishing the asynchronous functions of LibUSB soon.

Lou

Louis LaBrunda

Re: LibUSB Interface

In reply to this post by Louis LaBrunda

Hi Everyone,

I'm back to working on our LibUSB project again. Seth and I have gotten it to the point where I can talk to the X10 controller that was my original reason for starting the project. I have written a small GUI program that uses the interface and talks to the X10 controller. It only uses the simpler sync controls of LibUSB but that is all I need.

I'm now trying to work on accessing a Logitech F310 Gamepad. Seth wants to access a PlayStation 3 game controller and I hope that if I can access the Logitech F310 Gamepad that I can get the remaining bugs fixed and that accessing any other game controller or USB device will be straight forward.

Unfortunately, the game controllers are more complicated then the X10 controller and will work best with the async functions of LibUSB. The problems I am encountering now require more C knowledge that I have, this is Seth's area. Seth, however, is very busy with v8.6.3 and the new VM and won't have any time to work on LibUSB for the foreseeable future.

Would anyone like to fill in for Seth and help finish this project? You will need some knowledge of C. We have all the function calls defined and many are tested. Some may need fixing. I am getting some addressing exceptions freeing memory, so some knowledge of this area will help. You will also need some kind of game controlled, a PS3 or XBox would be best as we have a C program to follow as an example.

Lou

Louis LaBrunda

Re: LibUSB Interface

In reply to this post by Louis LaBrunda

Hi Guys,

We are way overdue for and update on our LibUSB project. I have made a bunch of small changes. I think we have the GPF bug fixed. We had LibUSB freeing a transfer buffer and then we were freeing the buffer (testing a flag wrong) and boom.

I have added some example methods. Some for a Logitech WingMan Gamepad Controller. This is an old game-pad controller that I was able to get a driver to work with. Drivers seem to be one of the biggest problems. USB devices often have more than one driver available and there is no telling which driver will work with LibUSB. It is trial and error, mostly error. And not knowing what the data returned from a device will look like it is hard to tell when a device/driver is working. You often just get a byte array of zeros, with no idea why.

I created a fun little example with the WingMan Gamepad that uses the D-pad to move a bomb (icon) around the screen and blow the bomb up when you press a game pad button. The code to display the icon is a hack but it allows the icon to move quickly. The icon has a transparent area but the hack code doesn't honor the transparency. A background color is always displayed, usually black. I changed the color to white and that worked for a while and then changed back to black even though I am still setting it to white. Since this is hack code and I am abusing a popup object I can't complain much and it has nothing to do with LibUSB, so it isn't a big deal.

I have tried to setup this example code so that it can be shared by other example code for other game controllers. You would need to write a small method that interprets the data from the USB device (game controller) and call the code to move the bomb around the screen.

This code calls LibUSB transfers in a isochronous (or asynchronous) way and then waits for an event to simulate synchronous calls. I may play around with not waiting for events/data but let the events go directly to the game pad code that moves the bomb. There are also notes in the LibUSB docs that indicate that a call to LibUSB should be run in its own thread. This is a little beyond me for now but it would be nice to explore this later.

Lou