Move to tinyusb 0.9.0 #321
Conversation
…p for sdtio_usb for tinyusb API changes
|
Note right now, this requires a patched tinyusb 0.9.0 which is in the raspberry pi repo here https://github.com/raspberrypi/tinyusb/tree/pico-0.9.0-wip This fixes some bugs in the family implementation, and provides a somewhat sub-optimal workaround with some impedence mismatches with the tinyusb examples proper
Both of these probably require some rationalization |
| static bool resetd_control_request_cb(uint8_t __unused rhport, tusb_control_request_t const *request) { | ||
| static bool resetd_control_xfer_cb(uint8_t rhport, uint8_t stage, tusb_control_request_t const * request) { | ||
| // nothing to do with DATA & ACK stage | ||
| if (stage != CONTROL_STAGE_SETUP) return true; |
There was a problem hiding this comment.
Since you are reset mcu, it should be better to reset when stage == ACK (ACK is complete), this will prevent host OS to complain about the failure of control transfer. For example, touch1200 is common way for Arduino to do reset to DFU.
https://github.com/hathach/tinyusb/blob/master/src/class/cdc/cdc_device.c#L354
case CDC_REQUEST_SET_LINE_CODING:
if (stage == CONTROL_STAGE_SETUP)
{
TU_LOG2(" Set Line Coding\r\n");
tud_control_xfer(rhport, request, &p_cdc->line_coding, sizeof(cdc_line_coding_t));
}
else if ( stage == CONTROL_STAGE_ACK)
{
if ( tud_cdc_line_coding_cb ) tud_cdc_line_coding_cb(itf, &p_cdc->line_coding);
}
break;There was a problem hiding this comment.
ah; good point thanks
| @@ -101,6 +101,12 @@ static inline uint uart_get_index(uart_inst_t *uart) { | |||
| return uart == uart1 ? 1 : 0; | |||
| } | |||
|
|
|||
| static inline uart_inst_t *uart_get_instance(uint instance) { | |||
There was a problem hiding this comment.
Is this change needed by this PR, or was it just pulled in coincidentally?
| add_library(tinyusb_example_support INTERFACE) | ||
| target_compile_definitions(tinyusb_example_support INTERFACE | ||
| CFG_TUSB_OS=OPT_OS_PICO | ||
| BOARD=pants |
There was a problem hiding this comment.
oops - i was checking something by deliberately using an invalid board ;-) that ain't gonna compile
|
@hathach I wanted to have a discussion somewhere, and this is probably as good a place as any. It might be nice to unify the tinyusb and sdk notions of a board, and possible share CMakeLists.txt between the two. I don't have a good mental picture of what the intentions are in TinyUSB to help me decide how to proceed. Here's some random points/questions.
|
yeah, it would be nice to have tinyusb example to work out of the box with pico-sdk.
Yeah, I feel the pain as well, like all other mcus, the sdk/low level driver (clock, gpio ) are needed only for running tinyusb stock examples and mostly for me to develop and test out new feature (basically maintaining the repo). It is actually not needed when tinyusb is part of another project or in this case pico-sdk. I am not sure what is best to ease this out. Typically it shouldn't be an issue if user don't submodule init with
The
esp32s2 requires to run with FreeRTOS config, you would see it in the _freertos example https://github.com/hathach/tinyusb/blob/master/examples/device/cdc_msc_freertos/CMakeLists.txt#L13 . Actually, I don't use CMakeLists.txt as top level, I typically type Actually, I am not too familiar with CMake, and I only try enough to get it running with existing |
|
yup, for the initial SDK release we copied some of the examples into the sdk because we weren't sure about changing some settings (like This raspberrypi/pico-examples#99 PR in in pico-examples changes us to use a curated list of your examples, but by globbing the the source files using the cmake helper function in this PR. Given that you already have some support for saying which examples belong with which families, I am hoping that maybe long term we could just import a CMakeLists.txt from your example root into our pico-examples tree to add all your current examples so there is non manual work. This should be possible, but I wanted to understand the current usage of the CMakeLists.txt in tinyusb examples first because figuring out how best to refactor them. Note also there is also this https://github.com/raspberrypi/tinyusb/tree/pico-0.9.0-wip branch, which has a few tweaks, and allows for specifying a BOARD on the TinyUSB side which just uses the PICO_BOARD settings from the pico-sdk |
And there's also MicroPython which submodules both |
Ah yeah, naturally it is default no OS configuration previously. I made some changes when adding rp2040 support. There maybe a few left, feel free to make PR to fix those.
Yeah, ready to use CMakeLists.txt from tinyusb example for pico-sdk is what I really want as well. That will help people testing out examples easier. I will try to tackle the build system later on when having more time.
Thanks for the link, I will check it out next time I rework the cmake build for rp2040. |
Yeah, lots of project depends on each others. pico-sdk and tinyusb is kind of weird since they include each other, therefore submodule init with recursive flag shouldn't be run 😅 . Maybe I will drop the pico-sdk submodule in tinyusb, and have an instruction to tell people to install pico-sdk themself. After all, tinyusb is supposed to be included as submodules by others. Will do it later on. |
|
update I have removed pico-sdk as part of tinyusb submodules, it would be much better for rp2040 user. They definitely need to pico-sdk somewhere already. hathach/tinyusb#782 |
|
obsoleted by new #462 |
tinyusb: add cmake functions to add example from tinyusb itself; fixup for sdtio_usb for tinyusb API changes