XHC WHB04B development?

I was just thinking that I was able to work with the pendant for hours, despite disconnects.
You are of course right, it's not correct. The component seems to try to adapt to the situation
and succeeds to 99.5%.

Tried your code. Had to replace libusb_init_context with libusb_init, after that it ran.
You have some skills there for sure.
Yeah, it kept the pendant busy. There were no disconnects while running.
The polling stopped, or maybe the output stopped, for some ten seconds
after turning the wheel, then it started again. I guess that was intentional.

What's your idea with the code? Just for test or should it replace the usb code
in the whb04b component or ?

I should be able to downgrade my usb to usb 2.0 on wednesday.

 

Yes, the output stops for some 10 seconds after operating the pendant (I think any action, not only the wheel). If you press a button during that time, it still comes through. But the regular updates resumes only after about 10 seconds.

At first I thought this 10 second delay was because I somehow polled the dongle in a wrong way. But I later tried it with the Mach3 driver, and found it to exhibit the same behavior. So I would say this is again pointing to not so high quality dongle firmware.

The idea was the program was partly to investigate the issue, partly to maybe create a new driver for LinuxCNC. Like I have mentioned, I'm not fully happy with xhc-whb04b-6 component functionality nor with how its coded (too many layers of abstraction for my liking/understanding). And the "blocking calls" are basically a fundamental issue with it. But don't get me wrong. I do appreciate and praise all the work done by the guys/gals who has made and updated the component. Evidently it works fine in many situations, just not (all the time) for me.

you might try to read the firmware by glitching the voltage, I did that with an STM32F0 part in the past (but another application), I was even able to re-flash the image. I don't know if it also works with the G0, but you might try. Most importantly is to remove the capacitors.

sec-consult.com/blog/detail/secglitcher-...32-microcontrollers/

I will take a photo of the wired USB version later this week since my pendants are in the shop

Found usbhid-dump  github.com/DIGImend/usbhid-dump/tree/master
which already is in the linuxcnc system also keeps the xhc from disconnecting.
What's the difference vs the component?
The whb04b component uses async transfers, but more?

FWIW, I put the usb dongle in my windows 11 computer. Disconnects/reconnects there also.

Regarding the firmware for the pendant, I thought about trying to read it out with glitching or some other technique. But I have not seen the need for it so far. I did read out the firmware from the dongle, but also that was quite much work for what in theory should be simple:
github.com/finngineering/ch55x_firmware_extractor
The reverse engineering I have done for that is with Ghidra. But the dongle is based on the CH554 microprocessor, which is a "8051" type. And the support for that processor is not the best in Ghidra.

I'm not sure what differences you are asking about for the usbhid-dump Hakan. I haven't really checked the source, but I guess it's just polling the interrupt endpoint more or less the same as my test program and the xhc-whb04b-6 component. What would be interesting to know is if there are disconnects with all these program if left running long enough. Say, 1 day or so. Or if that happens only with the xhc-whb04b-6 component (and maybe only while LinuxCNC is running)... I could maybe leave it running overnight myself to check.

I mean, what do your program and usbhid-dump do that stop the disconnect/reconnects?
And why doesn't the whb04b component do the same?
Rhetorical question.

I looked briefly at the codes, but this is a big hurdle..