previosuly users of TinyUSB (e.g. pico-examples) would have to decide this for themselves. This function couples
the check closer with the actual version of Pico-PIO-USB used (since TinyUSB picks)
Don't mark IN buffers as available during the last 200us of a full-speed
frame. This avoids a situation seen with the USB2.0 hub on a Raspberry
Pi 4 where a late IN token before the next full-speed SOF can cause port
babble and a corrupt ACK packet. The nature of the data corruption has a
chance to cause device lockup.
Use the next SOF to mark delayed buffers as available. This reduces
available Bulk IN bandwidth by approximately 20%, and requires that the
SOF interrupt is enabled while these transfers are ongoing.
Inherit the top-level enable from the corresponding Pico-SDK flag.
Applications that will not use the device in a situation where it could
be plugged into a Pi 4 or Pi 400 (for example, when directly connected
to a commodity hub or other host) can turn off the flag in the SDK.
v2: use a field in hw_endpoint to mark pending.
v3: Partial rewrite following review comments
- Stub functions out if the workaround is not required
- Only force-enable SOF while any vulnerable endpoints are active
- Respect dcd_sof_enable() functionality
- Get rid of all but necessary ifdef hackery
- Fix a bug where the "endpoint lock" was used with an uninitialised pointer.
- remove "-Wno-stringop-overflow -Wno-array-bounds"
- skip -Wconversion for gcc 9 and prior
- suppress_tinyusb_warnings only when building with gcc 9 and below
* gcc 9.2.1 has some spurious -Wconversion warnings
* cmake 3.18 and above require set_target_properties to be added from the target directory (so added it to all examples)
* fixed a few warnings in a couple of examples
* Removed some compiler warnings, and cleaned out unnecessary warning suppression from CMake suppress_tinyusb_warnings()
* Made explicit family_configure_dual_usb_example() for DUAL mode examples as family_configure_target() may not generally be called multiple times for the same target
* Renamed library pico_pio_usb to tinyusb_picio_pio_usb to be clearer and avoid conflict if someone already has a pico_pio_usb in their project
* Added family_add_pico_pio_usb() method for adding Pico-PIO_SUB support to an existing example
* Allowed tinyusb_pico_pio_usb to be added to regular apps using the Pico SDK
- 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
- added back pre-existing board directories which now just select PICO_BOARD
- added boards/pico_sdk which just uses the pre-existing PICO_BOARD setting
- fixed rp2040/family.cmake to include the magic string "CFG_TUSB_MCU=OPT_MCU_RP2040" expected by build_family.py
- Examples should be CMake buildable from their own subdirectory; such a build will error out based on
matching .skip.MCU_xxx or a mismatched .only.MCU_
- It should be possible to build from a higher level and use .skip.MCU_ and .only.MCU_ to filter which
examples get built
- The intention is for the CMakeLists.txts in the examples to be non family specific and without MCU based IFs. I have
started this work, but am not really sure the state of the esp32 stuff; in any case the plan is to have
everything encapsulated in the FAMILY/family.cmake
- pico_examples now just includes examples/device/CMakeLists.txt and examples/host/CMakeLists.txt directly, as they
also build correctly when included from there.
Note that .skip.MCU_ for esp32 in the directories it wasn't previously avaiable has not been added, as the .skip is common to the regular Makefile builds also. It isn't clear whether these examples should build for esp32, but if not .skip should be added.
graham sanderson