Ports and Interfaces => USB => Topic started by: jcddcjjcd on August 06, 2010, 02:43:02 am

Title: generichid_cs works well in Windows7 64bit
Post by: jcddcjjcd on August 06, 2010, 02:43:02 am
I have just finished changing all my c# HID applications over to the code presented in generichid_cs having earlier used a previous version that was ported from the original vb version. I could not get that earlier version working correctly in W7 64bit.
The only thing I got caught out on with the new code was when changing devices on the fly and nulling the previous interface before instatiating a new one and not having closed all the SafeHandles.

I would like to thank Jan and the others that helped write generichid_cs. It is a tremendous effort to write something like this and I haven't seen any other implementations working in 64bit like this one does.

Many thanks.
Title: Re: generichid_cs works well in Windows7 64bit
Post by: Jan Axelson on August 06, 2010, 10:14:10 am
I'm glad to hear it's working well at 64-bits as well as 32!

Title: Re: generichid_cs works well in Windows7 64bit
Post by: jdunne on November 10, 2010, 10:29:58 am

I am guessing you are John Dekker from the Microchip forum who posted the following:  (If not, I'm sorry.. ignore the following)

I have been using your modified version of the eegeek.net C# bootloader application, which I got the source for here:

I see you've updated your application to use the newer generic_hid_cs version instead of the original C# port from Gordon Vance.  I too am in the process of doing the same.  It seems you ran into the same problems I am.  I attempted to integrate the changes in the latest generic_hid_cs version into my application (which is based on your application), and as far as I can tell, all references to the windows API have been corrected, but I keep running into problems.  After integrating everything as close as I could tell, I was getting an InvalidOverlappedtoPinvoke.  This was strange because I don't get this on the generic_hid_cs application, so I'm definitely missing something.

I tried changing ReadFile to use a NativeOverlapped structure instead of the nonManagedOverlapped one.  This change fixed the exception, but ReadFile still isn't returning anything.

Anyway, you said you had issues with "changing devices on the fly" and "nulling the previous interface."  I'm guessing this is my issue as well.  Could you please post an updated version of your C# bootloader application?  If that is not feasible, perhaps you could just post parts of it?  I've been beating my head against the wall for about a day now, and I'm about to refactor the whole application to work with the generic_hid_cs library instead of the original one (which I am not looking forward to).

By the way, your bootloader application and firmware are exceptional.  I've modified it quite a bit, but it made for a great starting point.  I have never found a bootloader setup that was this well put together on both the PC and firmware side.

Joe Dunne
Title: Re: generichid_cs works well in Windows7 64bit
Post by: jcddcjjcd on November 13, 2010, 02:35:03 am
Thanks for the compliments you have paid me. I have since refined the whole solution further such that it is now a serial RS232 bootloader and a HID bootloader in one application.

It also has a feature that will convert the hex into a string that you paste into the rom of the firmware you are developing. That way it is always in every build of the firmware without you having to go through all the usual trouble of having two apps in one.

Compressed it is 964K.
I don't think I can upload it here. Suggest where I should make it available or email me at jdekker@xtra.co.nz and I will send it to you.

Title: Re: generichid_cs works well in Windows7 64bit
Post by: jdunne on November 13, 2010, 11:31:41 am

Funny, my version has all the same features (RS232, and the hex string output).  Another trick I put in was to create a segment in the hex file (at an address not physically allocated on the chip) that provides information about the device to be progammed (start and end programming address, several other things needed for supporting various devices).  I can't upload what I have now as has some other vendor specific stuff in it.  I'll try and clean it up and put it together next week.

Anyway, the best way to reduce the file size is to delete the files in the obj and bin folders of the project before zipping.

By the way, I did come up with a solution to the issue I was hoping you had solved.  http://www.lvr.com/forum/index.php?topic=177.0

It unfortunately requires the application to be compiled with the unsafe option enabled.  I'm thinking about a different solution that wouldn't need that, but haven't tried it yet.