Basic USB HID test failing...

[fpp]

Sorry for the late report, but after entertaining high hopes all day long, yesterday evening I had some *very* mixed results...
So I decided to bring the pyboard to the office this morning, and try it on other machines to compare on a larger sample.

Here is how things stand right now :

Last night I replaced main.py with the exact code from Dave's post above and tried it on my home PC (W7).
Result : negative.
I get the prints (Sending T) in the REPL, but nothing in the active window,
and no "Rcvd: 0x54 'T'" when the REPL has focus.
Tried swapping USB ports and cables, no dice...

As Dave's code was obviously not tried in Windows, I dug out an old Chromebook (which also runs Ubuntu in a chroot) and plugged in the pyboard, and... of course it worked right away, in both environments, as described in his post.

Wondering if it was really a platform problem, I then remembered I still had an old working Netbook (a Samsung NC10 from 2088, still running XP ).
And what do you know, on this one the code also works, albeit with one big caveat :
it tends to auto-repeat... after printing the first 'T' in the active window, it pauses briefly, then starts printing more Ts continuously, until I reset the board.

So this morning I tried it on two more Windows PCs at the office : the W7 corporate workstation (which would be the target usage when it works right) and my own W10 laptop I keep there on the side.
Both exhibited the same behaviour : works, but with autorepeat.

So we have three different cases here :

* Linux/ChromeOS : works as expected

* Windows XP/7/10 : works but incorrectly

* My home W7 machine : doesn't work at all
The only possible reasons I can think of right now are USB drivers :
this one has the pyboard driver installed, and also the Arduino IDE with its own driver(s).

So thanks to Dave we have working code, but thanks to Windows the hair-pulling is not over

Edit: forgot to mention that the W10 laptop also has a Mint Linux double-boot.
Under Linux the pyboard also works fine, so definitely an OS problem...

[dhylands]

I suspect that what needs to happen now is to actually do a USB trace on the Windows machine and see what HID messages are actually sent from a real keyboard.

I know under linux, WireShark can sniff USB messages. Under Windows, I've used http://www.usblyzer.com (in a VirtualBox under linux). You can run it free for 30 days.

The code as I presented sends the LEFT_SHIFT and T at the same time and has them released at the same time. Of course, in real life with a real person, the Shift key tends to get pressed first, then the T, then the T released and then the shift released.

[fpp]

Thanks once more Dave for the useful hint, I'm downloading that, let's pray for a rainy weekend

[pythoncoder]

Real keyboards do auto-repeat after a short delay. Is this done by the keyboard hardware or by the device driver?

[fpp]

I don't really know in general, but in this specific case it's clear that the signals sent by the hardware are interpreted differently by the host OS : various Windows versions autorepeat, various Linux platforms don't...

[fpp]

A tidbit of good news for a change

I brought the W10 laptop home to experiment on, as my home W7 PC still doesn't collaborate...

It seems that the Windows-specific autorepeat can be solved easily after all :

From the start I've been suspecting the two "tight" whille loops, and/or the rapid-fire USB sends in succession.

So I just added very short (1 and 2) delays inside the loops, and a longer one (20, as 10 looked almost-but-not-quite enough) between the two sends.

And lo, seems to work just fine... after all, we all know Windows is a bit on the slow side
The order in which the keys are sent does not seems to actually matter...

Maybe all three delays are not necessary, but I can't be bothered to find out right now.
I still need to try and understand why my other PC doesn't receive anything, using the USB sniffer... *phew*

[fpp]

@Dave :

Another thing that puzzles me is, where and how did you get the idea for bytearray(9) ?

The (admittedly few) examples I found, like the one I linked to earlier, all use 8...
And your code seems to work just as well with 8 too

[fpp]

Curiouser and curiouser... what was supposed to a "quick experiment" is tuning into a saga, and spiralling down into Vodoo-land...

USBlyzer is a nifty tool indeed, probably difficult to master but easy enough to see what's going in on.
It just told me "how come" (but not "why" ) the pyboard doesn't work as an HID keyboard on my home PC :
somehow it's recognized as an HID mouse

When I capture the traffic on that port I see it receives the right data from the board : it just doesn't know what to do with it, or thinks it's wrong...

Of course I installed USBlyszer on the laptop, and there the pyboard appears as a keyboard and everything works fine.

Now how do I explain the meaning of Life to that crazy machine ?...

PS: Oh, and, Dave... USBlyszer also shows my real USB keyboard sending 8-byte arrays

[fpp]

Now how do I explain the meaning of Life to that crazy machine ?...

Well this one turned out to be simpler to fix than I expected :
finding the impostor mouse in device manager, and manually updating the driver to HID keyboard,
did the trick (and seems to survive plug/unplug cycles so far).

So maybe now we can move on to make something useful out of this...

When I first played with Arduinos, USB and buttons, I found a ready-made lib that took an array of strings that it sent to the host PC depending of which button was pressed on a keypad. I just had to customize the string values and the keypad rows/cols, which even I can do in C

I guess we're still a long ways from that, right ?

[dhylands]

@Dave :

Another thing that puzzles me is, where and how did you get the idea for bytearray(9) ?

The (admittedly few) examples I found, like the one I linked to earlier, all use 8...
And your code seems to work just as well with 8 too

I should be using 8. I was using 9 because I was looking at the packet layouts here:
http://stm32f4-discovery.net/2014/09/li ... id-device/
which include the "type" byte (i.e. keyboard versus mouse, etc), and along the way I realized that in MicroPython the send command only wants bytes 1-8, not 0-8), but I forgot to change the bytearray size back.