Provide compilation option not to inline `dcd_*` callback functions

[rajivr]

Is your feature request related to a problem? Please describe.

Currently dcd_* callback functions are inlined. This causes the corresponding linker symbols not to be generated.

This means we cannot call them from Rust.

Describe the solution you'd like

It would be good if we can get a compilation option so the callback functions are not inlined.

Describe alternatives you've considered

I am currently using this patch as a workaround.

[hathach]

besides dcd_ inline helper, there is also class inline helper as well. Does Rust need all inline API to be non-inline as well ? I try to see what the best way to address this.

[rajivr]

I've not yet gotten to USB class functions, so I am not sure if it would be needed. Right now I am working on calling tinyusb callback functions from our Rust based USB interrupt handler.

[hathach]

TinyUSB has many static inline API for convenience, most of them are just helper to clean up arguments eg to pass 0 for multiple cdc instance since most application will only 1 CDC port..
https://github.com/hathach/tinyusb/blob/master/src/class/cdc/cdc_device.h#L74

It is possible to just move these inline dcd to normal function as your patch, but It is a bit troublesome if we have to make them all from static inline to normal function. I don't understand Rust, Is it possible if you would just skip the helper and use the main function API eg dcd_event_handler() directly ?

[rajivr]

It is possible to just move these inline dcd to normal function as your patch, but It is a bit troublesome if we have to make them all from static inline to normal function.

I agree. I don't think we'll need to change the signature for all functions.

The only ones I am suspecting we might want to provide a compilation option for would be for the dcd_* APIs and Application APIs (tud_cdc_*) (BTW, I've not gotten to CDC APIs yet).

The reason for not using dcd_event_handler(...) directly is because I wanted to easily compare our implementation with existing interrupt handlers for other chips.

Rust + TinyUSB might not be a common implementation scenario for TinyUSB. In the unlikely event supporting Rust turns out be more challenging, I can always maintain our Rust changes out-of-tree and share those to other TinyUSB Rust users as and when they need it.

@cr1901 has also started tinyusb-sys crate. Maybe we can maintain the patch there as well.

Also thank you for TinyUSB. :-)

[hathach]

It is possible to just move these inline dcd to normal function as your patch, but It is a bit troublesome if we have to make them all from static inline to normal function.

I agree. I don't think we'll need to change the signature for all functions.

The only ones I am suspecting we might want to provide a compilation option for would be for the dcd_* APIs and Application APIs (tud_cdc_*) (BTW, I've not gotten to CDC APIs yet).

all classes API cdc/midi/hid are inline, since they are all supported multiple instances (e.g dual cdc, dual hid etc ...), but that is easy enough, you could just support multiple instances and just their API

The reason for not using dcd_event_handler(...) directly is because I wanted to easily compare our implementation with existing interrupt handlers for other chips.

Rust + TinyUSB might not be a common implementation scenario for TinyUSB. In the unlikely event supporting Rust turns out be more challenging, I can always maintain our Rust changes out-of-tree and share those to other TinyUSB Rust users as and when they need it.

@cr1901 has also started tinyusb-sys crate. Maybe we can maintain the patch there as well.

I will move those inline into usbd.c for now, we will see how thing will turn out when you porting the class API. These dcd_event API are mostly called in ISR context, but I guess another function call wouldn't hurt much.

Also thank you for TinyUSB. :-)

No problems at all, I am glad that you find this project useful. It would be great if you could give me some reference and a bit of instructions on how to compile/build the stack with your Rust project. I haven't used Rust, but maybe this is chance to get started with a new language. And I am kind of curious how the stack work there.