Pico SDK - Fix Compiler Definitions & RISC-V RP2350 support

[iCMDdev]

This is a PR for fixing the issues outlined in #59.

[iCMDdev]

As I previously mentioned, this PR addresses #59.

The Pico SDK examples resulted in build errors with the new 2.0.0 SDK due to the required compiler flags not being passed to swiftc. The proposed solution recursively gathers compile definitions for each target, quite similar to this example from the Raspberry Pi pico-playground repo.

This PR also addresses issues when building for RP2350's RISC-V mode, though it's currently pending an SDK update. With Pico SDK version 2.0.1, issues (raspberrypi/pico-sdk#1922) will be fixed. One can pre-test the new version by switching to the SDK develop branch.

[rauhul]

I dont know enough cmake to really comment on this approach, @etcwilde do you mind providing some feedback?

[iCMDdev]

To be honest, I didn't know that much CMake either - I learned while writing this. Feedback is definitely welcome 😅👍

[etcwilde]

Some minor comments.

You might be able to get the gather_compile_definitions_recursive down to a single generator expression. I don't love that part because it's something that CMake will already do for you if we weren't using a custom command.

(Probably for someone else, but it might be worth looking into switching the custom command in favor of a normal add_library invocation instead and linking things normally)

[iCMDdev]

if we weren't using a custom command.

I was wondering why this was used, and I found this here:

Finally, we need to define the application's build rules in CMake that will be using CMake logic from the Pico SDK. The following content of CMakeLists.txt shows how to manually call swiftc, the Swift compiler instead of using the recently added CMake native support for Swift, so that we can see the full Swift compilation command.

Regarding a native CMake implementation:

a normal add_library invocation instead and linking things normally

We should be able to replace the special swiftc arguments (such as -enable-experimental-feature Embedded, -target armv6m-none-none-eabi etc.) with target_compile_options calls, right? Is there a limiting factor here? Or, perhaps the idea is to provide an under-the-hood view of the Swift compilation command?

[rauhul]

We should be able to replace the special swiftc arguments (such as -enable-experimental-feature Embedded, -target armv6m-none-none-eabi etc.) with target_compile_options calls, right? Is there a limiting factor here? Or, perhaps the idea is to provide an under-the-hood view of the Swift compilation command?

No, if you can make this work with CMake's native Swift support, that would be amazing

[iCMDdev]

I've looked into this a bit this weekend, and I was able to successfully compile this simple test program (I know it doesn't change the architecture based on the environment variable yet, this is just a starting point):

cmake_minimum_required(VERSION 3.13)
# Include and initialize the Pico SDK
set(CMAKE_Swift_COMPILER_WORKS TRUE) # ignore the "ld: library 'System' not found" simple test program error
include(/Users/cmd/pico/pico-sdk/external/pico_sdk_import.cmake)

# Set the project name and specify Swift as the language
project(swift-blinky LANGUAGES Swift C CXX ASM)
pico_sdk_init()

# Specify Swift compiler flags
set(CMAKE_Swift_FLAGS "-target armv6m-none-none-eabi -Xcc -mfloat-abi=soft -Xcc -fshort-enums -Xfrontend -function-sections -enable-experimental-feature Embedded -wmo -parse-as-library -c")

# Add the Swift source file
add_executable(swift-blinky
    Main.swift
)

So compiling embedded Swift works perfectly fine, but now, the challenging part comes: integrating with the Pico SDK. I ran into some issues likely caused by using Swift (and clang) with the ARM GNU GCC toolchain used by the SDK (since I'm seeing arguments specific to GCC in the swiftc command):

When I add target_link_libraries(swift-blinky pico_stdlib hardware_uart hardware_gpio) and build, I get error: unknown argument: '--specs=nosys.specs' when the build reaches the swiftc step. And even if I'd somehow fix that, it's expected to create an elf file (swift-blinky.elf) using swiftc, but I'm pretty sure it will build a Mach-O binary on Mac.

So I guess what's left is to customize that last linking step and make it work properly. If anyone has some tips on this, I'd be happy to hear them! 😃

[fabianfett]

I ran into this trying to get the pico-w blinky example running. It worked perfectly for me. My two cents here: Perfect might be the enemy of good here.

[iCMDdev]

Perfect might be the enemy of good here.

Right, using the CMake native support turned out to be a bit harder than expected. Might still be possible, though.

Perhaps we can and try to address all issues (if there are any remianing ones) with the current apporach, so people can use the new Pico SDK without issues, and work on the CMake native Swift approach in another issue / PR?

On the other hand, people having issues will probably find #59 when searching for fixes / known issues, which is also linked to this PR. Just like you did, I suppose 😆

[rauhul]

Perhaps we can and try to address all issues (if there are any remianing ones) with the current apporach, so people can use the new Pico SDK without issues, and work on the CMake native Swift approach in another issue / PR?

I think this looks good to merge with hopes of adopting the swift cmake support later.

I'd like to get @kubamracek to review this before merging though.

[kubamracek]

Agree with all that's being said, and I'll throw in that we do have a couple of existence proofs of using the CMake native Swift support, e.g. here https://github.com/apple/swift-embedded-examples/blob/main/esp32-led-blink-sdk/main/CMakeLists.txt. But yes, let's merge this PR now as is.

[iCMDdev]

Agree with all that's being said, and I'll throw in that we do have a couple of existence proofs of using the CMake native Swift support, e.g. here https://github.com/apple/swift-embedded-examples/blob/main/esp32-led-blink-sdk/main/CMakeLists.txt. But yes, let's merge this PR now as is.

I'll look into that 👍

[iCMDdev]

I closed this by mistake, sorry. I deleted my patch-1 branch by mistake.

[mpapple-swift]

@rauhul Please review changes completed and approve. Support for RISC-V on the 2350 for an embedded Swift example would be awesome!

[iCMDdev]

Small reminder that this still requires a Pico SDK update in order to run on the RISC-V cores (the patch is in the development branch, should release with 2.0.1).

So if you want to try this yourself, you currently need to use the development (nightly) branch of the Pico SDK.

Maybe I should add this info in the example's README and update it when the new SDK version comes out.

[mpapple-swift]

Small reminder that this still requires a Pico SDK update in order to run on the RISC-V cores (the patch is in the development branch, should release with 2.0.1).

So if you want to try this yourself, you currently need to use the development (nightly) branch of the Pico SDK.

Maybe I should add this info in the example's README and update it when the new SDK version comes out.

@iCMDdev agreed - this would save developers some headaches. Any idea when the Pico SDK 2.0.1 will be released?

[iCMDdev]

Any idea when the Pico SDK 2.0.1 will be released?

I'm not sure...

agreed - this would save developers some headaches

Done, what do you think?

[mpapple-swift]

LGTM - thanks

[iCMDdev]

Thanks for merging! 🎉