I have not worked on this part of the USB Code at all, only some on the USB Host code for T3.6 and T4, so take this with a grain of salt...
There is some information up in the PDF associated with the LC in Chapter 35. Also there is lots more information up in the official USB documents...
There are lots of things going that go on behind the scenes with USB stuff.
First off the usb_joystick_send does NOT wait for the send to complete. That is the code does:
Code:
int usb_joystick_send(void)
{
uint32_t wait_count=0;
usb_packet_t *tx_packet;
//serial_print("send");
//serial_print("\n");
while (1) {
if (!usb_configuration) {
//serial_print("error1\n");
return -1;
}
if (usb_tx_packet_count(JOYSTICK_ENDPOINT) < TX_PACKET_LIMIT) {
tx_packet = usb_malloc();
if (tx_packet) break;
}
if (++wait_count > TX_TIMEOUT || transmit_previous_timeout) {
transmit_previous_timeout = 1;
//serial_print("error2\n");
return -1;
}
yield();
}
transmit_previous_timeout = 0;
memcpy(tx_packet->buf, usb_joystick_data, JOYSTICK_SIZE);
tx_packet->len = JOYSTICK_SIZE;
usb_tx(JOYSTICK_ENDPOINT, tx_packet);
//serial_print("ok\n");
return 0;
}
The wait here is not for this send to complete, but if necessary it will wait to allocate a logical tx_packet out of a pool of packets. The code is setup to not allow more than a maximum number of Joystick messages to be pending. In this case I believe TX_PACKET_LIMIT is 3... So only 3 outstanding joystick messages will be pending in thte output queue.
The USB hardware when it is polled for the next packet to output, it will retrieve the next packet from the list to send. If the USB system properly sends out that packet, it will release that sent packet from the list, which if it was associated with our end point will decrement the count of pending messages, which should then allow this usb_joystick_send, to allocate a new tx_buffer, and exit the loop, and then copy the data in and call usb_tx to queue it up...
Again there is a lot more going on.