@Pavel_A said:
The host (PC) does not expose endpoints to device, it is the other way. HID devices often expose one IN interrupt endpoint to indicate their data (aka input reports). The host of course has to poll the device endpoints, as Mr. Roberts has reminded.
Correct, and that’s how I had understood things … but things change so much in the ecosystem that what once was A is now B (for instance, apparently with Thunderbolt3 you can have hot swappable PCIe bus devices [and there’s a CVE tool called ThunderSpy that takes advantage of that] … it used to be you needed a specialized BladeServer to do that and so a PCIe hot swap event was a black swan for folks, now apparently anyone with a $250 StarLink 3T chassis and a Thunderbolt3 MB can hot swap PCIe cards during runtime … That’s great for my Xilinx PCIe FPGA development so I don’t need a disconnect board anymore and don’t have to reboot when I’m developing but also means I have to test my bus drivers against a potential PCIe rebalance event when a TB3 connect/ disconnect happens … )
But the host controller does it in hardware, invisible to the host software.
The host can send a message to device anytime, via EP0, as OUT report or vendor specific request. EP0 is bidirectional.
Correct also, and that’s a design pattern I like to use for USB traffic … the business logic is in the various EP’s, the host/ firmware control logic is in the EP0 communications … EP0 is designed for that, is required by spec and is always there …
IMHO the main decision is between HID style API and “raw” winusb, it depends on how much data the device needs to move, how often (i.e. are bulk endpoints needed? Power management needed?)
There’s actually more to it than that … quite a few of my clients are small medical device companies or groups inside of larger corporations that want to make a POC to show to higher ups for funding … in both cases they don’t have the time and resources to get certified for a signature, and putting the machine in test mode isn’t an option so what I will try to do if at all possible is leverage the WinUSB functionality (with WCID descriptors) to talk to the firmware and lib-usb to handle things in usermode; it’s clean, doesn’t require a driver and works. If I can’t get that to work then I’ll write a UMDF v2 driver to talk to the firmware, it’s only for high security USB applications that I will have to write a KMDF USB driver and they know what they are signing up for already … but again, I will really try to handle stuff using WinUSB and lib-usb.
For a HID device it’s actually a bit annoying, normally you send the report request on the other side of the INT endpoint but in the MS USB HID driver MS will use the other side of the INT endpoint for a report request but will also use the EP0 EP in a WriteFile() command to send a report request to the INT endpoint, which goofs up my bidirectional EP0 control pattern … unless I can use WinUSB as the OS driver. That forces me to use WCID to make a composite device for WInUSB to recognize the device, and I think the firmware fellow got annoyed by that and just wanted to only make a pure HID device in firmware, not monitor EP0 (the base firmware hides the EP0 control/ setup stuff) and wanted a bidirectional HID device as an overloaded C&C interface [which I also really avoid, because I don’t like to write sporks] … which as I mentioned I had never heard of before, but before I opened my mouth and proved that I didn’t know what I was talking about I wanted to ask some of the erudite experts here )
The HID library wraps some details of communication but has some more overhead (creation of HID device entities on top on USB functions, reading and parsing report descriptors).
The lib-usb library is definitely good but you have to be careful about what lower driver is being loaded by MS for the device; that’s one really nice thing about WCID, I can specify exactly what driver I want the OS to load …
Your firmware developer should be able to explain how it works to you, and suggest how to debug and test the communication.
The most important communication occurs among humans and it should work well ))
Yep, and the inter-human communication is usually the one that has the most errors … Thanks for your comments and thoughts!