Add PICO_MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED (defaults to 1) to allow mutlicore_lockout to work before core 1 is started#3019
Conversation
…low mutlicore_lockout to work before core 1 is started
|
it slightly irks me that this adds code to multicore_launch_core1 even if multicore_lockout functions aren't called (this was true before actually, its just now two places) |
|
oops, converting to draft, as I need to add a "multicore_lockout_can_be_called()" or whatever |
|
It still asserts in default_enter_safe_zone_timeout_ms. configNUMBER_OF_CORES=1, running freertos on core 0 which calls flash_safe_execute_core_init. Core 1 not started. Is that right? I've been using this example to reproduce the issue raspberrypi/pico-examples#762 |
yeah - as per draft comment, it is missing a bit to make it work; i'll try the example... i'm going back and forth as to whether i want this, or to force people to call a method to setup core 1! |
… off new support to save the extra bit of code needed
CRT0_FAR_CALLS and MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED hadn't been implemented correctly (so were always excluded), and THREAD_LOCAL was missing from docs
| # | ||
| # \param\ INCLUDE The items to include | ||
| # \param\ EXCLUDE The items to exclude | ||
| function(pico_minimize_runtime TARGET) |
There was a problem hiding this comment.
I pushed a commit to fix this, as both CRT0_FAR_CALLS and MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED weren't implemented correctly, so were always excluded
will-v-pi
left a comment
There was a problem hiding this comment.
LGTM - tested it works with the flash_progam example. If you link pico_multicore, without this PR it panics, and with this PR it now works fine.
| #endif | ||
|
|
||
| // PICO_CONFIG: PICO_MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED, Allow multicore_lockout functions called from core 0 to succeed if core1 has not been started, default=1, group=pico_multicore | ||
| #ifndef PICO_MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED |
There was a problem hiding this comment.
I guess this could be PICO_SUPPORT_MULTICORE_LOCKOUT_BEFORE_CORE1_STARTED but perhaps that's a bit long 😉
Co-authored-by: Andrew Scheller <lurch@durge.org>
fixes #2639