Embedded Swift Example Projects for ARM and RISC-V Microcontrollers

That was a great link! I've added to my "good links to recommend" cache.

A learning embedded for Swift Developers and a learning Swift for embedded developers wiki/repo/shared annotated bibliography would be awesome. I am working on my own greatest hits page, but then, by definition, that only has resources that I know about.

For example anyone have a "Biggest gotchas in switching to Clang/CMake for people who know GCC/Make" talk they like? I'm using them because of Swift actually, but I have a lot to learn.

For those who like books the second edtion of the below is hot of the press

The author is one of the hosts of https://embedded.fm which interviews a lot of people in the biz. I haven't read it but they do have a 2016 series based on the ti MSP430 that on initial review looks pretty comprehensive and well beyond the teach a 6th grader to blink an LED level without requiring calculous - Embedded Software Engineering 101 — Embedded

In case anyone is interested, I transformed the stm32-blink example to compile on Linux. It works with the nightly-jammy Docker image, and the only additional required package is binutils-arm-none-eabi.

I'm still getting familiar with this stuff, so it may not be perfect, but my LED is blinking!

6 Likes

Excellent! I love how the changes are really minimal, and looking at them, most are pretty self-explanatory (e.g. you needed to add a linker script to produce a correctly laid out ELF file instead of a Mach-O file). I think we should be able to eliminate the need for these stubs:

void posix_memalign(void) {
    while (1) {}
}

void __stack_chk_fail(void) {
    while (1) {}
}

void __stack_chk_guard(void) {
    while (1) {}
}

void free(void *ptr) {
    while (1) {}
}

(1) If you disable stack protectors (-disable-stack-protector swiftc flag), I'd expect __stack_chk_fail and __stack_chk_guard to not be needed anymore. See https://github.com/apple/swift/blob/main/docs/EmbeddedSwift/UserManual.md#external-dependencies. But of course, stack protectors are generally useful.
(2) I think that asking the compiler to place functions into separate sections (-Xfrontend -function-sections, the equivalent of Clang's/GCC's -ffunction-sections) should enable dead-code stripping, and then the posix_memalign and free dependencies will go away because you don't use any allocations in the example. I am actually trying to pursue enabling this behavior by default on ELF, see https://github.com/apple/swift/pull/70788.

6 Likes

Thanks! I was indeed wondering how we could get rid of these stubs. As it turns out, using -function-sections is enough to get rid of all of them in this case. I pushed an update for that.

One strange thing I found is that I had to 'clean' the build (removing blink.o is enough). Otherwise, for some reason it doesn't have any effect when enabling (or disabling) -function-sections, even though everything is recompiled.

I pushed similar changes for the stm32-lcd-logo example, so that one can be compiled on Linux as well now.

1 Like

Experimenting with stm32-uart-echo with Swift 6 toolchain

No luck:

% export TOOLCHAINS='Swift Development Snapshot'
admin@mbam1 stm32-uart-echo % make
fatal: not a git repository (or any of the parent directories): .git
compiling...
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-04-22-a.xctoolchain/usr/bin/swift-build
--configuration release
--verbose
--triple armv7em-apple-none-macho
-Xcc -D__APPLE__ -Xcc -D__MACH__
-Xswiftc -Xfrontend -Xswiftc -disable-stack-protector
Planning build
Building for production...

... here starting for long long time when compiling SwiftSyntax stuff...
... then stop here:

....
-o /Users/admin/Documents/atwork/swift-embedded-examples-main/stm32-uart-echo/.build/armv7em-apple-none-macho/release/Application.build/USART1.swift.o
make: *** [build] Error 1

Any idea?
Must we use a specific toolchain to experiment with Swift embedded?

Can you post the entire log? I think the error message is cut off.

Actually, I was able to reproduce the failure, and I think I've been able to fix it with: Fix calling convention on putchar (silgen_name -> cdecl) by kubamracek · Pull Request #10 · apple/swift-embedded-examples · GitHub

Can you try it now?

Success with your patch and latest toolchain.
Thanks !