KSDK 2.0 USB API questions and suggestions

[laszlomonda]

Dear NXP USB developers,

First of all, let me just say that I'm very happy with the new KSDK 2.0 USB examples that you included. The compound keyboard + mouse example is exactly what I've been looking for. That being said, there are still a couple of issues that could be improved from the perspective of an application developer. Please let me highlight some that I noticed.

* A fair number of USB examples has a lite and non-lite (regular?) version. What is supposed to be the difference between the two? When should one be picked over the other? Is one planned to be obsoleted?

* I think the most error prone data structure is g_UsbDeviceConfigurationDescriptor by far. It's super long, weakly typed (uint8[]), and contains a multitude of different descriptors. Modifying it is like walking on a minefield. It'd be great to decompose it to multiple smaller (typed) data structures.

* I think that the API could be significantly nicer and easier to use. LUFA exposes the most beautiful USB API I've ever seen and it's a joy to work with.

* Regarding the usb_device_ch9.[ch] files, what ch9 is supposed to mean?

* "Device" is often mispelled as "Devcie" across the codebase.

That's pretty much all I wanted to share for now. I do understand that implementing a great API takes time and you're probably pushed to churn out features. Thank you for your hard work and keep it up!

- Laci

[Jmart · Accepted solution]

Laci,

Thanks for the kind words and feedback. See my answers below.

László Monda wrote:

Dear NXP USB developers,

First of all, let me just say that I'm very happy with the new KSDK 2.0 USB examples that you included. The compound keyboard + mouse example is exactly what I've been looking for. That being said, there are still a couple of issues that could be improved from the perspective of an application developer. Please let me highlight some that I noticed.

* A fair number of USB examples has a lite and non-lite (regular?) version. What is supposed to be the difference between the two? When should one be picked over the other? Is one planned to be obsoleted? [JM] The lite version of the class examples illustrates an implementation that doesn't require the overhead of the full class implementation. It's a way to achieve specific functionality using less resources.

* I think the most error prone data structure is g_UsbDeviceConfigurationDescriptor by far. It's super long, weakly typed (uint8[]), and contains a multitude of different descriptors. Modifying it is like walking on a minefield. It'd be great to decompose it to multiple smaller (typed) data structures. [JM] I'll share this feedback with the development team.

* I think that the API could be significantly nicer and easier to use. LUFA exposes the most beautiful USB API I've ever seen and it's a joy to work with.

* Regarding the usb_device_ch9.[ch] files, what ch9 is supposed to mean? [JM] CH9 is chapter 9 of the USB specification, the USB device framework.

* "Device" is often mispelled as "Devcie" across the codebase. [JM] I'll get this added to the future improvements.

That's pretty much all I wanted to share for now. I do understand that implementing a great API takes time and you're probably pushed to churn out features. Thank you for your hard work and keep it up!

- Laci

Regards

[laszlomonda]

Thanks for the quick reply, Jason!

Please also mention LUFA to the development team. I think it should be the de-facto API for USB-capable microcontrollers given its stellar usability. Probably a lot can be learned from it.

Cheers!