KSDK 2.0 USB API questions and suggestions

cancel
Showing results for 
Search instead for 
Did you mean: 

KSDK 2.0 USB API questions and suggestions

Jump to solution
308 Views
laszlomonda
Contributor IV

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

Labels (1)
1 Solution
60 Views
Jmart
NXP Employee
NXP Employee

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

View solution in original post

2 Replies
61 Views
Jmart
NXP Employee
NXP Employee

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

View solution in original post

60 Views
laszlomonda
Contributor IV

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!