analogdevicesinc
feat(ThirdParty): Add TinyUSB library to MSDK
Add TinyUSB support into MSDK.
TinyUSB was ported to the MAX32 devices and the PR is currently under review at the TinyUSB Repo (PR 2708). This PR is to bring the implementation back into the MSDK for use within MSDK specific applications.
The current strategy is: Library
- Add TinyUSB as a library into MSDK similar to MAXUSB, FreeRTOS, etc
- Rather than a Git submodule, bring in only the necessary files for device mode operation with the MAX32
- Files are not modified (clang-format, cpplint, etc)
- Do not incorporate the TinyUSB BSP system as it will conflict with the MSDK BSP
- Examples will be included verbatim to be used as reference until all/most examples are port to MSDK projects
Examples
- Create examples in the MSDK/Examples folder similar to other MSDK example projects
- Use the TinyUSB examples verbatim, adding wrappers to bridge the MSDK BSP with the TinyUSB expected BSP calls
- Examples a clang-formatted and cpp-linted to comply with standards
- Add a simple README to the TinyUSB/Examples folder to instruct user's how to port other examples which have not yet been added.
@Jake-Carter , @EricB-ADI . This is incomplete, still a lot of work to be done on the examples and documentation side of things. Before going too far, I wanted to kick off a discussion/review of the approach for both the library and example projects. Once you are happy with how things will get integrated, creating all the examples will be cookie-cutter. Just rather it be right with the first two, before going all in.
Also, I'm sure we'll need to engage someone to approve and confirm compatibility with Apache and MIT licensing.
I think at this point, everything is pushed for review. Once the PR at the TinyUSB repo is merged, I'll re-grab the library code to make sure our inclusion is in sync with the official repo.
I added examples for all the supported parts and updated the documentation best I could see where. I assume the OSPO will auto generate an update to NOTICE when the time comes.
Feel free to start a review now, or wait until I update the TUSB code and take this out of draft.
@Jake-Carter I rebased against main to resolve the merge conflicts. Looked like it was just a minor Makefile update causing the issue. Probably worth checking once over to make sure I didn't goof something up...I have by Git noob moments sometimes.
@BrentK-ADI looks like there are some linker errors in hid_composite now - can you check?
@Jake-Carter I think the issue here is building a TinyUSB library for re-use versus compiling the source directly into the project. The contents of TUSB library is dependent on the tusb_config.h file. The Makefile trys to compensate for this with the ${TINYUSB_CONFIG_DIR}/tusb_config.h dependency, but the path pointed to by TINYUSB_CONFIG_DIR will change from example to example, so I don't think the dependency will ever catch.
Do we do anything with FreeRTOS that compensates for this? I would imagine it has the same issue with FreeRTOSConfig.h sitting in the project folder, but a library is being built.
@Jake-Carter I think the issue here is building a TinyUSB library for re-use versus compiling the source directly into the project. The contents of TUSB library is dependent on the tusb_config.h file. The Makefile trys to compensate for this with the
${TINYUSB_CONFIG_DIR}/tusb_config.hdependency, but the path pointed to by TINYUSB_CONFIG_DIR will change from example to example, so I don't think the dependency will ever catch.Do we do anything with FreeRTOS that compensates for this? I would imagine it has the same issue with FreeRTOSConfig.h sitting in the project folder, but a library is being built.
Agreed. This is now a common issue across Cordio, FreeRTOS, and now TinyUSB.
Looking into a solution for tracking the path and contents of the config file as a dependency. One interesting option is here.
I implemented it and it works for tracking changes to options inside a project. It will need some more work to track changes across projects and for the library files.
Once tinyusb.a exists, there's no other way to trigger a rebuild unless we did something like $HASH/tinyusb.a or tinyusb-$HASH.a + another recipe to copy or symlink back to tinyusb.a. Not a huge fan of the external tool dependencies or renaming the files but so far this is the most promising solution to this problem I've come across.
Does it still make sense to retain these libraries as libraries in the linking sense? Thinking about FreeRTOS and TinyUSB especially, since what gets compiled into these projects is so dependent on the project settings itself, does it make more sense to just have the respective .mk files just append to SRCS, I_PATH, PROJ_CFLAGS, etc when including those libraries and have it built with the project and the dependencies tracked for changes as normal?
Yes, that's definitely a reasonable approach. We do it for MiscDrivers and a couple other libraries.
Just updated to go that route (https://github.com/analogdevicesinc/msdk/pull/1101/commits/3d408d4984c4ce1c5a96a9a7a4a86e4de6557e21).
I like the modularity of building each library as a static file, but this is simpler to get this working across config changes.
Looks like the relocation of the MAXUSB examples cause a linting failure with header guards. I'll go ahead and fix those today.
Is there a good way to run all the automated checks locally before committing? I've been running cpplint and clang-format somewhat manually to check the files. My mistake on these examples not realizing the path contribution to the #ifdefs, but generally speaking didn't see a one-shot command in the contribution guide.
Thanks!
You can run the linter/formatter locally on files/folders (https://analogdevicesinc.github.io/msdk//CONTRIBUTING/#running-the-linter-formatter) but there's not a great way to run the entire check locally, since most of it is written in the Github workflow file.
It would be nice in the future to consolidate it to a local script like I did with the build test Python script.