-
Notifications
You must be signed in to change notification settings - Fork 2
usbd: Add basic HID keypad (with status LED detection), basic mass storage #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feature/usbd_python
Are you sure you want to change the base?
usbd: Add basic HID keypad (with status LED detection), basic mass storage #1
Conversation
Rely on support implemented in the machine.USBD() object on the MicroPython side, providing a thin wrapper around TinyUSB "application" device class driver.
Taken from https://github.com/paulhamsh/Micropython-Midi-Device as of commit 2678d13.
- Add micropython-lib 'usbd' package (provisional). - Update midi implementation a bit. - Rearrange code to work with package structure - Convert docstrings to regular comments to save flash.
… add more documentation to msc.py
Impressive effort getting this going, looks great! With the mass storage, have you had it running against a "real" flash filesystem on the device? Does it need / work with a Block device eg one that's formatted as FAT? |
Thanks! I've realised that "filesystem" is really a bit of a misnomer, since it doesn't know or care about the filesystem, it just needs something it can operate on. Currently it needs something that works like a bytestring, but I imagine it wouldn't be too hard to extend it to do a type check on whatever it is you give it and access it appropriately. I would say it would probably be possible to create an object to pass in to it that would work transparently, but micropython doesn't support the |
You've successfully got me into "just quickly adding" the ability to use (This chain of bugs brought to you by Linux asking for 30 4096-byte blocks in one command, which I hadn't seen before due to my filesystem entirely fitting in RAM.) |
Nice one! Yeah my biggest issue with MSC is that it just exposes the underlying block device and filesystem - which for me is always littlefs so not easily supported on computer. I'm actually keen to use this new USB support to add MTP as used on cameras and Android phones - this operates at the file level so should be good on any filesystem. |
I've now added support for AbstractBlockDev-based devices, plus the required bug fixes. I'm not sure it's done in the neatest way, but it does seem to reliably work |
Hi @turmoni, This looks really great, thanks!
Good catch on this, I'm not sure how I got this far without noticing I had them backwards! I'm keen to bring quite a bit of this into the main micropython-lib PR. When you get a minute, do you mind going back to pop some Copyright & License notices on the new files? Feel free to add yourself to the ones you fixed/modified, as well. |
c8ad6ca
to
53f9558
Compare
Rely on support implemented in the machine.USBD() object on the MicroPython side, providing a thin wrapper around TinyUSB "application" device class driver.
Based on https://github.com/paulhamsh/Micropython-Midi-Device as of commit 2678d13. With additions/edits by me.
53f9558
to
581a662
Compare
… but wasn't removed in the merge)
Thanks! I've added those to the files I created now (and got rid of my own EP constants and some other bits to adjust to the changes you've made), I'm happy to make any changes here (or in a new branch) to make it easier if needed. |
@turmoni Thanks dave, that should be heaps for now. I still need to figure out exactly how best to structure the PRs into micropython-lib (to not add too much in one PR, and to correctly group things like examples or modules for particular functionality). So I'm happy to pick and choose from your branch as needed at the moment. If you did have time, I'd be very curious if your MSC class still needs the extra workaround of |
I cleaned that bit up on seeing the changes you'd made and it seems like it works fine without it now - my fork doesn't have it any more. At least, I currently have it connected up with the |
Implement by overriding USBInterface.handle_open or handle_reset.
Necessary for MSC device class, possibly other purposes.
As contributed in projectgus#1 commit 5c51a9e This version of the hidkeypad module depends on some other code changes from the linked PR that aren't included here, so it won't work here yet.
- Use SET_REPORT via control transfer. - Merge the keycodes module into hid_keypad. - Remove LEDs other than NumLock to make the report handler even simpler.
Right, I think I have added decent usage of the new stall options - unfortunately I think my code ended up getting robust enough and my memory of how to do this stuff has degraded enough that I'm not entirely sure how to test it properly, so I'm by no means guaranteeing that this will appropriately behave in response to a reset or an invalid/non-meaningful CBW. |
40d1674
to
d6da573
Compare
91b762f
to
ab7c3d5
Compare
ceb74e2
to
20fc109
Compare
As contributed in #1 commit 5c51a9e This version of the hidkeypad module depends on some other code changes from the linked PR that aren't included here, so it won't work here yet. Signed-off-by: Angus Gratton <[email protected]>
20fc109
to
a2c3195
Compare
9cf4a60
to
4f2220d
Compare
As contributed in #1 commit 5c51a9e This version of the hidkeypad module depends on some other code changes from the linked PR that aren't included here, so it won't work here yet. Signed-off-by: Angus Gratton <[email protected]>
4f2220d
to
c88c4e1
Compare
40a430d
to
744f8c4
Compare
90ce5f2
to
81962f1
Compare
97aac4a
to
583bc0d
Compare
Creating as a draft pull request because I don't think this is really ready to be merged as-is, since I was mostly working on just getting it working for me and I imagine the structure could do with being improved, especially when it comes to where to put constants and the like. Points of note:
hid.py
where I've swapped them around._retry_xfer_cb
indevice.py
andtry_to_prepare_cbw
inmsc.py
for examples)I also know that I'm not following micropython-lib's conventions for submitting a PR, but since I'm submitting this to you and I'm not necessarily expecting it to be directly merged I hope that's less important. At least, I made my commit messages and pushed them up before reading that.