Open mcknly opened 3 weeks ago
Also need a way to automate downloading the PicoSDK if it does not already exist, and move this functionality into the hardware-specific CMake file - potentially could use ExternalProject module for this purpose. Top level README should not refer to $PICO_SDK_PATH
. This auto-cloning script could also be used for the FreeRTOS kernel.
Why not just use git submodules for this? They need dealing with anyway, for microshell and git_version.
I don't think submodules are the way to go for board-specific stuff, otherwise running a git clone --recurse-submodules
or a simple git submodule update --init --recursive
will pull down WAAAAAYYYYY too much crap once we support multiple boards.
We could always use the CMake FetchContent
module to allow each HAL layer to automagically clone the necessary pieces. Or we can take a page from the VSCode Pico extension and do the whole bloody toolchain into <$HOME|%USERHOME%>/.pico
.
@Kintar agreed, I think the ability for CMake to pull in modules for FreeRTOS/relevant SDKs based on PLATFORM
setting in project.cmake
would be the way to go, but optionally if the user had the appropriate env variables set (as in FREERTOS_KERNEL_PATH
and PICO_SDK PATH
today), it would take no action to download those pieces.
Finish the work that began in PR #6 - decouple project top-level from MCU platform and remove any references to RP2040/Pico, move all HW-related things to the
hardware/
subdirectory.Work on hw-decouple branch.
Still to-do:
CMakeLists.txt
still hasinclude($ENV{FREERTOS_KERNEL_PATH}/portable/ThirdParty/GCC/RP2040/FreeRTOS_Kernel_import.cmake)
target_link_libraries
in rootCMakeLists.txt
to thehw_libs
variable inhardware/rp2040/prebuild.cmake
cli/node_proc.c