Full access to TinyUSB as a library?

[timonsku]

Something I'm missing in CPY atm is more low level access to TinyUSB.
I can understand that one might not want to expose the whole C API to the Python side but would it be possible to write a library in C that can interact with TinyUSB and only expose a higher abstraction of my desired functionality to Python?

I have no idea how linking works for python modules with native code, can I just call any part of the core or would I need to build my code together with the core?
Also would I run into issues with CPY managing USB stuff and messing with it?

[dhalbert]

Something I'm missing in CPY atm is more low level access to TinyUSB.
I can understand that one might not want to expose the whole C API to the Python side but would it be possible to write a library in C that can interact with TinyUSB and only expose a higher abstraction of my desired functionality to Python?

We could add functionality that seems like it would be generally useful. What are your use cases?

I have no idea how linking works for python modules with native code, can I just call any part of the core or would I need to build my code together with the core?
Also would I run into issues with CPY managing USB stuff and messing with it?

It would not make sense to be able to call TinyUSB in general; you could easily conflict with what we need for CircuitPython.

[timonsku]

It would not make sense to be able to call TinyUSB in general; you could easily conflict with what we need for CircuitPython.

Thats what I feared

My use case right now would be to add support for HID generic transfers.
Would also be nice to provide your own descriptor for that and define multiple endpoints, set report size and stuff like that .

Access to certain events and functions would also be of interest. f.e. setting the PID VID in user code and events for usb mounted/unmounted.

[dhalbert]

There is already some latent support for raw HID, but we haven't written the corresponding Python part of the library yet. User-defined descriptors are a pending issue: #1015. PID/VID would come along with that. Feel free to open issues for specific features. I'll close this one for now, since it's more about how rather than what.

[timonsku]

Sounds good to me, that seems to implement most things I wanted :)
I only looked at issues with the USB tag, guess I missed it.
If there is point to start with the raw hid, I might take a look. Been meaning to learn a bit about cpy core development.

[dhalbert]

See PR #2116, which optionally provides a RAW HID device, enabled by compiling with `USB_HID_DEVICES = "RAW". This is not included by default. Since RAW cannot have a report id, you can't include other devices in the same endpoint. But it could be additional USB device. We don't currently have a mechanism for a second separate-endpoint HID device.

We were contemplating using RAW to have CircuitPython communicate as a special-purpose device that wouldn't need drivers installed on Windows, because RAW HID is already available. But that project is not high prioirity right now.

You opened this issue a long time ago: adafruit/Adafruit_CircuitPython_HID#25 :)

[timonsku]

Yes I have not forgotten about it :D
But since TinyUSB came a long its great to also profit from the increased flexibility and control that come with it.
I would also have thought to have it as a separate endpoint, I think its also solved in the Arduino core like that, didn't try raw in combination with a different hid device yet.
So what might be nice to have then is a way to create and manage multiple endpoints and assign each the device type the user wants?
Existing classes like keyboard and mouse could just do this in the background and reuse the same endpoint.

[tannewt]

I only looked at issues with the USB tag, guess I missed it.

I added the usb label to the linked issue. Thanks!

[dhalbert]

#7806 fixes a problem that gets in the way of raw HID, and should now allow this. There are some test programs there.