Bluetooth's specification defines IAD for primary controller.
While it seems that Windows and Linux can leave without this,
there is no reason TinyUSB should not provide it.
- physically suppress warnings in TinyUSB headers using pragmas so they don't break -Werror compilation of external files that include them
- fix compiler warnings in rp2040 port
- add cmake method to rp2040 port to allow an external project to suppress warnings in TinyUSB itself
Add FT90X and FT93X to the list of devices in tusb_option.h. 1700 for FT90x and 1701 for FT93x.
Set endpoint attributes for FT90x and FT93x in dcd_attr.h.
Add FT90x routines for USB device in src/portable/bridgetek/ft90x/dcd_ft90x.c
The location for hardware header files and libraries is hw/mcu/bridgetek/ft90x/hardware. There are no files in the repository, but files will be linked as a submodule in the future. The required files can be copied from or linked to the location "C:/Program Files(x86)/Bridgetek/FT9xx Toolchain/Toolchain/hardware" once the toolchain is installed.
Makefile for the MM900EV1B board for developing with an FT900 device is present. Use "BOARD=mm900ev1b".
Windows and Linux host during enumeration requests device
descriptor with request size set to 64 bytes when device
was in default state (no address).
Those systems do not want 64 bytes though since usb descriptors is
only 18 bytes long so they silently expect that only one packet
will be received possibly 18 bytes for EPS > 16 or 8 or 16 bytes
for smaller EP0.
For devices with CFG_TUD_ENDPOINT0_SIZE size 8 or 16 there was
workaround that reduced request size to CFG_TUD_ENDPOINT0_SIZE
and that was enough to satisfy Windows and Linux hosts.
However USBCV testing application also requests device descriptor
but with size set to 18 bytes. Workaround for Window/Linux
prevented USBVC to tests devices with 8 bytes EP0 size since it
send only 8 bytes while application did wanted 18 bytes.
Solution that satisfies both cases it to check if in default state device
descriptor request wants more bytes than descriptor size (18).
If so host is expecting to receive less bytes then requested
and workaround would be applied since Linux/Windows only try
to read one packet.
If 18 bytes was requested as is the case for USBCV, core returns
descriptor in 2 or 3 packets as application expects.
example implement tud_descriptor_device_qualifier_cb() and
tud_descriptor_other_speed_configuration_cb() on high speed device to
fully compliant to usbcv
