Basic USB HID test failing...

[fpp]

Ah, got it. These are really well made docs !

It also explains the other line I didn't understand, as the value got squashed afterwards :

Code: Select all

buf[0] = 0x01   # Keyboard

If I understand correctly, the choice for the uPy API precludes using a pyboard as a mongrel HID device (kb + mouse + pad), which is allowed by the 9-bit C API ?

[dhylands]

Looking at the code, it looks like you might be able to call pyb.usb_mode each time you want to switch modes and pass in a new hid type.

[fpp]

The pyboard may be able to do that, but from my recent adventures I have doubts about the capability to reconfigure in real time on the Windows end...
Worth trying on a rainy day though

BTW, do you know how/whom to ask to get a new tutorial added to the docs ? The results of this thread could be a useful addition to the mouse code example...

[dhylands]

I'm not sure what the Windows issue would be.

Calling pyb.usb_mode only does actual USB configuration the first time its called. After that, it skips all of th eUSB initialization and just stashes away the hid= parameter which would in effect wind up changing the first byte when you sned the hid data.

The documentation is all stored in the doc tree of the micropython repository, so updating the documentation is done as a PR just like modifying the code.

The mouse tutorial is here:
https://github.com/micropython/micropyt ... _mouse.rst
and the file which links it into the documentation is here:
https://raw.githubusercontent.com/micro ... /index.rst

[fpp]

I'm not sure what the Windows issue would be.
Calling pyb.usb_mode only does actual USB configuration the first time its called. After that, it skips all of the USB initialization and just stashes away the hid= parameter which would in effect wind up changing the first byte when you send the hid data.

I was referring to my home PC, which had decided once and for all my pyboard was a mouse, despite dozens of pyb.usb_mode calls top the contrary, and was silently discarding the data I sent it because they were not mouse reports

The documentation is all stored in the doc tree of the micropython repository, so updating the documentation is done as a PR just like modifying the code.

Ouch... I don't do Github
I could probably write a tutorial in Markdown, but PR's are not in my ballpark.
Strange to place such hurdles against community contributions... whatever happened to good old Wikis ?

[deshipu]

Strange to place such hurdles against community contributions... whatever happened to good old Wikis ?

There is a good old wiki too. It's on github.

[fpp]

Ah, thanks for reminding me of that !

But it serves a very different purpose than the docs, doesn't it ?
More for the development and porting of uPy itself, than for end-user tutorials or sample code (which seems quite normal).

[deshipu]

Yes. You can always write your own tutorials somewhere. For instance, I put my workshop materials on readthedocs -- it's very easy to write them using sphinx, and I can make it update automatically from any repository, on bitbucket, github or hosted by myself. If it's bitbucket or github, they even add an "edit" button there, for making pull requests.

[pythoncoder]

There are two wikis, the dev one here https://github.com/micropython/micropython/wiki an one for users here http://wiki.micropython.org/Home.

[fpp]

Ah, thanks for that, by focusing on Github I had managed to completely overlook the traditional one on this site...

It does look a bit... redundant, semi-abandoned or at least under-promoted ?

It's the most accessible to me however, so I'll give it a spin...