This question is similar to a previously unanswered one in a different thread at https://forum.pjrc.com/threads/59685-Teensyduino-1-51-Released?p=234544&viewfull=1#post234544.
I'm trying to understand the differences between the USB stacks of the teensy3 and teensy4 cores in order to port some existing teensy3 code with custom USB descriptors to run on teensy4. I've noticed that ENDPOINT1_CONFIG no longer exists, and it seems to me that that many usb devices had two separate unidirectional endpoint configurations combined into a single bidirectional one (commonly SEREMU_TX_ENDPOINT and SEREMU_RX_ENDPOINT). That seems to also be reflected in the descriptors that USB hosts will see, in that the lowest endpoint number on interfaces will now be 2 rather than 1.
When attempting to re-add support for ENDPOINT1_CONFIG in teensy4/usb.c using the provided USB1_ENDPTCTRL1 define, I've been able to create the same descriptors as I could previously with the teensy3 core with interface endpoint numbers starting at 1, but then observed my device misbehaving: in the particular example of a custom hid joystick-type input, i'd no longer receive the expected report values on the host side.
Is there some kind of problem that prevents endpoint #1 from being used on teensy4? How come ENDPOINT1_CONFIG is not a part of the teensy4 core? If there's no fundamental issue, what work would be required to allow teensy4 usb devices to behave identical to teensy3 ones from the perspective of a usb host?
Thanks!
I'm trying to understand the differences between the USB stacks of the teensy3 and teensy4 cores in order to port some existing teensy3 code with custom USB descriptors to run on teensy4. I've noticed that ENDPOINT1_CONFIG no longer exists, and it seems to me that that many usb devices had two separate unidirectional endpoint configurations combined into a single bidirectional one (commonly SEREMU_TX_ENDPOINT and SEREMU_RX_ENDPOINT). That seems to also be reflected in the descriptors that USB hosts will see, in that the lowest endpoint number on interfaces will now be 2 rather than 1.
When attempting to re-add support for ENDPOINT1_CONFIG in teensy4/usb.c using the provided USB1_ENDPTCTRL1 define, I've been able to create the same descriptors as I could previously with the teensy3 core with interface endpoint numbers starting at 1, but then observed my device misbehaving: in the particular example of a custom hid joystick-type input, i'd no longer receive the expected report values on the host side.
Is there some kind of problem that prevents endpoint #1 from being used on teensy4? How come ENDPOINT1_CONFIG is not a part of the teensy4 core? If there's no fundamental issue, what work would be required to allow teensy4 usb devices to behave identical to teensy3 ones from the perspective of a usb host?
Thanks!
