We're going to be developing a composite USB device around a Kinetis K51 microcontroller. I'm getting familiar with the Freescale USB stack.
In usb_devapi.h, I find the following:
#if (defined(_MCF51JM128_H) ||defined(_MCF51MM256_H) || (defined _MCF51JE256_H))
#define USB_SERVICE_MAX_EP USB_SERVICE_EP15
#else
#ifdef DOUBLE_BUFFERING_USED
#define USB_SERVICE_MAX_EP USB_SERVICE_EP6
#else
#define USB_SERVICE_MAX_EP USB_SERVICE_EP4
#endif
#endif
This seems to suggest that the Coldfire processors can handle 16 endpoints, but the Kinetis processors can only handle 4 or 6 endpoints.
The manual for the part we're using states in so many words that the part can handle 16 endpoints.
Is this an error in usb_devapi.h? Or am I missing something obvious?
Solved! Go to Solution.
Hi John,
I just got the feedback from our AE team, please refer to the following comments on your question:
we set it to 8 just for the code footprint. Usually, 8 endpoints are enough for a device even a simple composite device. Of course, if needed, the customer can set it to 16, but as the consequence, it will take more RAM.
Hope that makes sense,
Have a great day,
Kan
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
John
The Kinetis indeed have 16 endpoints; I have used a composite configuration with USB-CDC to 5 UART connections using the uTasker USB device stack on K-devices.
Unfortunately I can't give details about the Freescale stack but either the said define is not used by Kinetis or else you should be able to set it to EP15 - USB in the Kinetis is virtually identical to the one in the Coldfire devices and the uTasker code runs on both (with just a few modifications for the clock config and the interrupt vectors).
Regards
Mark
The constant is used in usb_driver.c, in this routine:
/**************************************************************************//*!
*
* @name _usb_device_register_service
*
* @brief The function registers a callback function from the Application layer
*
* @param controller_ID : Controller ID
* @param type : event type or endpoint number
* @param service : callback function pointer
*
* @return status
* USB_OK : When Successfull
* USBERR_ALLOC_SERVICE : When invalid type or already registered
*
******************************************************************************
* This function registers a callback function from the application if it is
* called not already registered so that the registered callback function can
* be if the event of that type occurs
*****************************************************************************/
uint_8 _usb_device_register_service(
uint_8 controller_ID, /* [IN] Controller ID */
uint_8 type, /* [IN] type of event or endpoint
number to service */
USB_SERVICE_CALLBACK service /* [IN] pointer to callback
function */
)
{
UNUSED (controller_ID)
UNUSED (service)
#ifdef MULTIPLE_DEVICES
/* check if the type is valid and callback for the type
is not already registered */
if(((type <= USB_SERVICE_MAX_EP) ||
((type < USB_SERVICE_MAX) && (type >= USB_SERVICE_BUS_RESET))) &&
(g_usb_CB[type] == NULL))
{
/* register the callback function */
g_usb_CB[type] = service;
return USB_OK;
}
else
{
return USBERR_ALLOC_SERVICE;
}
#else
UNUSED(type);
return USB_OK;
#endif
}
The result appears to be that you can only register up to USB_SERVICE_MAX_EP endpoint callbacks.
I have not yet compiled the code and inspected the generated code to verify the limit. One of our other guys is currently fighting with the various toolsets, and he's sporting some arrows in his back at the moment.
I'm not real impressed with putting both the USB events and the endpoints in the same callback table. As written, with the registration limit, about half to 2/3 of the table lies fallow. I'm sure someone had a reason at some point.
In the real world, this will not be an issue unless someone starts registering a lot of endpoints.
Hi John,
What is the version for the usb stack you are referring to? So far the latest one is usb stack 5.0, and KSDK 1.0 also include that USB stack, with more support for RTOS like MQX,FreeRTOS, UcOS2/3. Would you please help to clarify? Thanks for your patience!
Have a great day,
Kan
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
We've got 4.1.1. I didn't know there'd been an update. I'm extracting it now and will take a look.
Looking at 5.0: Out of the box, it appears to support a maximum of 8 data endpoints (1 <= endpoint <= 15), not necessarily contiguous. The TOKEN_DONE processor for the USB interrupt searches the registered service handlers for the specified endpoint.
The controlling item is
#define MAX_DEVICE_SERVICE_NUMBER 8
in file usb_dev.h. That constant controls the size of the
service_struct_t services[MAX_DEVICE_SERVICE_NUMBER];
in the same file.
Hi John,
I just got the feedback from our AE team, please refer to the following comments on your question:
we set it to 8 just for the code footprint. Usually, 8 endpoints are enough for a device even a simple composite device. Of course, if needed, the customer can set it to 16, but as the consequence, it will take more RAM.
Hope that makes sense,
Have a great day,
Kan
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------