Make sure CFG_TUSB_OS is defined #3157

Open
peterharperuk wants to merge 1 commit from peterharperuk/tusb_os_fix into develop
peterharperuk commented 2026-08-24 07:42:52 -05:00 (Migrated from github.com)

When building the USB examples with a newer version of tinyusb it's possible for CFG_TUSB_OS to be set wrongly.

When building the USB examples with a newer version of tinyusb it's possible for CFG_TUSB_OS to be set wrongly.
kilograham (Migrated from github.com) reviewed 2026-08-24 07:42:52 -05:00
kilograham commented 2026-09-01 16:41:37 -05:00 (Migrated from github.com)

i somewhat dislike this as it works around a slightly dubious change in TinyUSB (which makes a global change in an example scoped configuration).

That said, in my testing i haven't needed this at least with #3163 (can you try again with that and my latest PR from pico-examples - https://github.com/raspberrypi/pico-examples/pull/787)

i somewhat dislike this as it works around a slightly dubious change in TinyUSB (which makes a global change in an example scoped configuration). That said, in my testing i haven't needed this at least with #3163 (can you try again with that and my latest PR from pico-examples - https://github.com/raspberrypi/pico-examples/pull/787)
kilograham commented 2026-09-01 17:33:27 -05:00 (Migrated from github.com)

That said, it seems like it ought to be necessary, given that the configuration of a freertos example should then remove this flag, so it may just be luck (or rather that the order of pico-example building has no stdio_usb examples after the tinyusb freertos examples)... so i'm leaning back towards merging this (without the hand-wavey speculation in the comments)

Note i did say dubious above, but it has always been slightly dubious that SDK tinyusb_base or whatever sets this unequivocally. I'm still a bit in the dark as to what it means to use TinyUSB w/FreeRTOS on Pico (I assume setting the RTOS away from OS_PICO is fine and likely required in this case, in which case we should keep this change, but also look for a better, more configurable way to apply the default of OS_PICO for the common SDK tinyusb case - doing it via CMake might be vestigial, and could be potentially fixed by an upstream TinyUSB change. failing that we should do it in such away that it can be overriden per TARGET at least)

Side note, it'd be helpful to have a version number define coming from TinyUSB in CMake

cc @hathach for my musings

That said, it seems like it ought to be necessary, given that the configuration of a freertos example should then remove this flag, so it may just be luck (or rather that the order of pico-example building has no stdio_usb examples after the tinyusb freertos examples)... so i'm leaning back towards merging this (without the hand-wavey speculation in the comments) Note i did say dubious above, but it has always been slightly dubious that SDK tinyusb_base or whatever sets this unequivocally. I'm still a bit in the dark as to what it means to use TinyUSB w/FreeRTOS on Pico (I assume setting the RTOS away from OS_PICO is fine and likely required in this case, in which case we _should_ keep **this** change, but also look for a better, more configurable way to apply the default of OS_PICO for the common SDK tinyusb case - doing it via CMake might be vestigial, and could be potentially fixed by an upstream TinyUSB change. failing that we should do it in such away that it can be overriden per TARGET at least) Side note, it'd be helpful to have a version number define coming from TinyUSB in CMake cc @hathach for my musings
kilograham commented 2026-09-02 13:56:51 -05:00 (Migrated from github.com)

moved this back into 2.3.2 since

  1. it seems like the change ought to be within the existing guard for whether TinyUSB is being used directly
  2. i'm a bit surprised that we always add our own tusb_config.h to the include path here. this likely predates pico_stdio_usb being used in conjunction with user use of TinyUSB. I guess we just happen to be fiurther down the include path!?
moved this back into 2.3.2 since 1. it seems like the change ought to be within the existing guard for whether TinyUSB is being used directly 2. i'm a bit surprised that we always add our own `tusb_config.h` to the include path here. this likely predates `pico_stdio_usb` being used in conjunction with user use of TinyUSB. I guess we just happen to be fiurther down the include path!?
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin 'peterharperuk/tusb_os_fix:peterharperuk/tusb_os_fix'
git switch 'peterharperuk/tusb_os_fix'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'develop'
git merge --no-ff 'peterharperuk/tusb_os_fix'
git switch 'peterharperuk/tusb_os_fix'
git rebase 'develop'
git switch 'develop'
git merge --ff-only 'peterharperuk/tusb_os_fix'
git switch 'peterharperuk/tusb_os_fix'
git rebase 'develop'
git switch 'develop'
git merge --no-ff 'peterharperuk/tusb_os_fix'
git switch 'develop'
git merge --squash 'peterharperuk/tusb_os_fix'
git switch 'develop'
git merge --ff-only 'peterharperuk/tusb_os_fix'
git switch 'develop'
git merge 'peterharperuk/tusb_os_fix'
git push origin 'develop'
Sign in to join this conversation.
No reviewers
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk!3157
No description provided.