I’m starting up a new embedded project and out of curiosity, would Swift for Embedded be able to run on the STM32C011F6? This chip is limited to 6KB of SRAM and 32KB of flash.
Is Swift tiny/light enough to run on this? I’ve recently been interested in trying out memory safe languages on embedded and Swift is my first choice.
Embedded Swift should be totally appropriate for the STM32C011F6. Given the resource constraints, I would suggest avoid language features requiring a heap (class and closures), similar to how you would avoid malloc when writing C/C++ for this sort of chip.
Sweet! I’d imagine anything heap would be a costly thing with 6KB of SRAM. I’m glad to hear that Swift is light enough since I haven’t worked with Swift for Embedded yet.
Do you also happen to know if anyone has tried to use the CMSIS and HAL the STM32Cube SDKs? Or am I better off just implementing everything myself in Swift instead?
I don't know anyone personally thats used the STM32Cube SDK, but swift-mmio has in progress support for generating a register interface from an svd file, see: SVD2Swift. I'm currently using SVD2Swift to build a new example for the swift-embedded-examples project.
(shameless plug: I'd love help improving these tools)
Sounds like a match made in heaven! I was just looking at Rust earlier and they have crates that have the SVD files converted to Rust with svd2rust. So having something similar for Swift is definitely nice.
I am excited to get started with this! I’m waiting on having an EVK but for now it seems more than possible to use Swift for this project. Anything I find out that can be improved in svd2swift I’ll be sure to contribute back for the good of the whole community. Thanks for the info!
I am now looking into using swift-mmio. However, I'm curious about how to get started with svd2swift? Is there some sort of information that would help with that?
Yes! swift-mmio Documentation – Swift Package Index
I recommend using main
Cool, I am grabbing main now! However, I'm having a weird issue trying to compile for my target using the --triple argument to swift build. I'll create a new post to hopefully get some help with that...
Oh actually, you'll likely need to use the "embedded examples" branch which has some long running diffs due to SwiftPM bugs/missing features. That might also resolve some issues you're hitting.
pico2-neopixel is a good example to follow
Okay so switching to that branch works better, but it still seems like swift build is trying to compile for x86_64-unknown-linux-gnu despite me using this command:
swift build \
--configuration release \
--verbose \
--triple armv6m-none-none-eabi \
-Xcc -mcpu=cortex-m0plus -Xcc -mthumb -Xcc -mfloat-abi=soft -Xcc -fshort-enums \
-Xswiftc -Xfrontend -Xswiftc -disable-stack-protector
I'm building on a Ubuntu 22.04 machine with the latest main-snapshot installed (9/13). Is there something wrong or missing in the toolchain?
Here's the error I get:
<unknown>:0: error: unsupported option '-mcpu=' for target 'x86_64-unknown-linux-gnu'
<unknown>:0: error: unsupported option '-mfloat-abi=' for target 'x86_64-unknown-linux-gnu'
<unknown>:0: error: unsupported option '-mcpu=' for target 'x86_64-unknown-linux-gnu'
<unknown>:0: error: unsupported option '-mfloat-abi=' for target 'x86_64-unknown-linux-gnu'
make: *** [Makefile:16: build] Error 1
Ugh this issue is deeply frustrating, the issue is that building requires both compiling tools for the host machine x86_64-unknown-linux-gnu and libraries for the target armv6m-none-none-eabi but -Xcc applies to both the host and the target.
@xedin had a pitch to improve this situation: Re-examining meaning of global options in cross-compilation contexts
I'm not sure where this went and I think its a no-brainer.
cc @dschaefer2
Well shoot! I might not be able to use swift-mmio at all if I don't have a way to pass the cpu and float-abi flags...well I'll give it a shot. I see that the pico examples are for a cortex-m0plus so maybe I can use some of the flags they are using there.
In the past I tried to just use the target triple and not pass these flags (when using swiftc directly) and that resulted in a binary that didn't appear to work. But, I shall have another look...
You might be able to put those flags into a "swift sdk" and use that to only target the "target" build. You can try to compose one using the SE proposal as reference?
Okay yeah, I do have experience with the Swift SDKs so maybe I can try that!!! I just won't have a sysroot to point to so that'll be interesting.
Yep, turns out if I don't pass the -mcpu=cortex-m0plus flag to Swift build somehow, then I can't link it due to the compiled code expecting things that aren't available on the Cortex M0+. The fact that I can't pass this flag is unique to using swift-mmio and all these libraries it seems.
So I'll have to figure out if I can create a cross compilation toolchain instead that lets me provide all the flags that are needed, and hopefully not have to provide a full SDK and sysroot. That will be my next investigation...
If I can't get this working, is there any way to just include some swift-mmio classes directly in my project and remove every dependency that requires building for the host? Maybe that could be a solution?
I don't think you need a "full" Swift SDK, I think you can probably make one that just has the json files + swiftc flags you need.
Maybe @Max_Desiatov has other ideas.
Unfortunately, no. While you can manually run svd2swift and avoid using the Swift Package Plugin, but swift-mmio itself uses Swift Macros which are always built for the host.
Alright, good to know. So this will be my last shot at getting mmio included. I’m hoping it works!!
In the world of cross compilation, I'm not sure the -Xcc swift build arguments and friends make as much sense now. At least the host tools should be pretty controlled environments that the user doesn't need to see or have much control over except maybe for extreme cases where something is pretty broken.
Could you raise a Github Issue for this if there isn't one already. We have some new people coming to help out. This might be a good starter task.
I wonder what's the Int and pointer sizes on such a platform?