USB Client in NETMF 4.2, anyone implemented yet?

Has anyone implemented a USB Client in 4.2 yet? I am very interested in implementing an HID client, much like in this (http://www.tinyclr.com/codeshare/entry/420) codeshare.

It should work. Have you tried it?

Is there a USBC_Device for 4.2? I’m using the Cerb libs (Discovery board).

The open source libraries do not support the use of USB Client.

Correct but HID can be done with built in support. We are planning on adding a tutorial around this but searching the web should get you couple results.

I thought the standard answer regarding HID on Cerberus was it wouldn’t work without switching the deploy/debug to serial (which isn’t an easy option in the GHI firmware per those questions). For example from this thread where someone asked basically the same thing and was told it wouldn’t work:

[Solved]FEZ Cerbuino USB Client and Debugger.

Has this changed in 4.2? Can a device appear as a HID client while stil supporting USB deploy/debug? If so any pointers?

HID + debugging on same USB cable, no NETMF device support this. We had this feature and was dropped it due to many issues related to USB drivers and windows.

Why not use USB-serial module?

Would this be simpler using the new WinUSB drivers instead of SpotUSB?

@ Gus: Is the tutorial planned any time soon? I’ve given it a fairly thorough search and haven’t found any examples. Anyone else find an example of USB Client in .NETMF 4.2 w/o the GHI Premium offers?

For which device? The problem is in switching debugging to serial to free USB.

I believe they are referencing your earlier post in this thread indicating it should work natively on an open source device:

“Correct but HID can be done with built in support. We are planning on adding a tutorial around this but searching the web should get you couple results.”

I also have looked for examples but never found anything that would work on Cerberus - if you could clarify whether a Cerberus can do it with the native firmware it would be helpful as that seems a confusing topic. (Once officially answered it would be nice if that information was also added under USB client in the wiki entry. I believe many equate USB client with a device presenting itself as a HID Client)

I must have forgotten that in order for that to work, you need to switch debugging to serial to free up USB. You can do this today by recompiling the firmware but this requires some knowledge with porting and RVDS compiler. The simplest way to communicate with a PC would be using serial port or USB-serial port.

What are you trying to achieve at the end and is this a commercial project?

@ Gus - I’m using the Cerb40. Does it have the second USB exposed for connection on PB14, PB15, or is that the debugging line?

I am creating a “Phidget Killer.” I want to replace the functionality of the Phidget 0/16/16 and 8/8/8 interface boards in a less expensive, programmable and extensible package, even replacing the Phidget 2/2/2 at a lower cost with more I/Os. We use these in our machines for button input and indicator light output, as well as sell them to our distributors for the same purpose, so it could be considered a commercial project, but in such small quantities as to be insignificant on GHI’s scale (<100/yr).

It would be nice to have a driverless USB solution, such as HID. I would be incorporating the functionality into this project: http://www.tinyclr.com/codeshare/entry/589

USB serial chips are only about $3 or less. That is not an option?

I like your project idea.

@ Gus - Thanks! USB Serial certainly is an option, as that what I am using now in cable form (Pl2303HX USB to COM/UART/TTL Integrated Programmer Cables (Replaced by PL2303TA) - ElectroDragon). USB HID would just simplify things a bit more: less chips, less drivers, more elegance, and a faster data pipe. I’ll finish out this first prototype using serial and share the details and some pictures.

Still have the problem of not reading data on COM2 after a device reboot, though. Was hoping a pure USB solution would avoid that.

Actually HID is very slow compared to FTDI chips.

Another option is USBizi chips.