TUSB_CLASS_SMART_CARD support

[revk]

Related area

I am trying to make a CCID reader device

Hardware specification

ESP32S3

Is your feature request related to a problem?

Firstly, please, let me know if there is any way to make a "generic" device with simple bulk in and out.

If so, that would suit me for now. But so far I have not found one - perhaps this could itself be a feature to allow for a variety of classes of devices that are not yet covered by TinyUSB. I tried VENDOR, but had not realised that it specific to class 0xFF, and if with that check commented out, looks like it only does bulk in (am I right?).

A generic driver for any class would be ideal.

Describe the solution you'd like

What I am looking for is device class for Smart Card (0x0B), and in my case I am happy just to have the CCID messages built of from the 64 byte packets (is that how it works), a callback with a request and returning a reply as a transfer.

Now, looking at the code, it is probably possible for me to actually do this change, bodging one of the existing classes. Is that helpful?

But as I say, if there is any way to do a generic bulk in/out class that would also suit me.

Perhaps the VENDOR class could avoid checking the class is 0xFF and add bulk in and out?

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[HiFiPhile]

You can slightly modify the vendor class and register it as a custom driver. check https://github.com/kkitayam/akiprobe as example.

Just declare the interface then use usbd_app_driver_get_cb()

usbd_class_driver_t const cmsis_dap = {
#if CFG_TUSB_DEBUG >= 2
  .name = "CMSIS-DAP",
#endif
  .init             = cmsis_dapd_init,
  .reset            = cmsis_dapd_reset,
  .open             = cmsis_dapd_open,
  .control_xfer_cb  = tud_vendor_control_xfer_cb,
  .xfer_cb          = cmsis_dapd_xfer_cb,
  .sof              = NULL
};

usbd_class_driver_t const* usbd_app_driver_get_cb(uint8_t* driver_count)
{
  *driver_count = 1;
  return &cmsis_dap;
}

[revk]

I had not found "app" driver, thanks. Is that essentially a generic driver (does not check class) that has bulk in and out?

Assuming this works, this becomes a very much non urgent "would be nice to have a smart card / CCID driver" that does the CCID packets at least.

An am struggling to work this out - the managed components from ESP IDF component registry may be out of date, but what CFG_TUD_ do I define?

[HiFiPhile]

Is that essentially a generic driver (does not check class) that has bulk in and out?

Yep, just modify the class code check to meet your need.

Perhaps the VENDOR class could avoid checking the class is 0xFF and add bulk in and out?

This check is needed for each class to avoid messing around with other class drivers, on device init the configuration descriptor passes into all classes, the class driver should process only the one it concerns.

what CFG_TUD_ do I define?

Do what ever you want, it's only used at the file start as a compilation switch

tinyusb/src/class/vendor/vendor_device.c

Line 29 in 5ef55bf

#if (CFG_TUD_ENABLED && CFG_TUD_VENDOR)

[revk]

OK, a generic class could have a #define for what class code to check even. And even #defines to say which interfaces to expect with a simple BULK IN/OUT default perhaps.

But it seems I will have to change some tinyusb code to make anything work for me, bodging VENDOR or some such. I can do that, but makes it a maintenance headache as I can never update the managed components from ESP IDF without zapping my changes.

A feature request (apart from smart card specific) would be a way to allow, by #defines, me to have a class code of my choosing with simple read/write functions for bulk data. There must be many possible classes tinyusb does not natively handle, and may never handle if too niche, which could be accommodated by such a mechanism, including smart cards.

A CFG_TUD_GENERIC and TUD_CFG_GENERIC_CLASS and so one would be great.

[HiFiPhile]

I can do that, but makes it a maintenance headache as I can never update the managed components from ESP IDF without zapping my changes.

You don't need to poke around managed components, I wasn't clear that I means was copy vendor class driver and modify it in your project (thus app driver), not in-place modification.

OK, a generic class could have a #define for what class code to check even. And even #defines to say which interfaces to expect with a simple BULK IN/OUT default perhaps.

Vendor class code (0xFF) is defined by USB-IF. Everyone has their own special needs that driver can't all handle, like the CMSIS probe example I've linked have some custom data buffer handling.

Take your card reader as example, you can strip off all the fifo stuff like CFG_TUD_VENDOR_RX_BUFSIZE and CFG_TUD_VENDOR_TX_BUFSIZE are 0.

[revk]

OK, can I just copy vendor class and change. Literally copy the C code to my main and that will work?

I am a make person and never got to grips with cmake, so sorry if that is a dumb question.

If so, that will be a good way forward, thank you.

If I have missed the point, some clues would be appreciated.

[HiFiPhile]

OK, can I just copy vendor class and change. Literally copy the C code to my main and that will work?

Yep, copy the code and modify the name to avoid collision, to something like ccid_open, ccid_reset, ccid_xfer_cb etc.

Then add driver registration:

usbd_class_driver_t const ccid_driver = {
#if CFG_TUSB_DEBUG >= 2
  .name = "CCID driver",
#endif
  .init             = ccid_init,
  .reset            = ccid_reset,
  .open             = ccid_open,
  .control_xfer_cb  = ccid_control_xfer_cb,
  .xfer_cb          = ccid_xfer_cb,
  .sof              = NULL
};

usbd_class_driver_t const* usbd_app_driver_get_cb(uint8_t* driver_count)
{
  *driver_count = 1;
  return &ccid_driver;
}

[revk]

I'll try that - thanks for you help.

I think I understand now, and had not appreciated the usbd_app_driver_get_cb option. That makes more sense now.

Of course once I have code this and got it working, I'm happy to donate it to the tinyusb project if you like.