Embedded Swift Example Projects for ARM and RISC-V Microcontrollers

orobio · 2024-04-04T16:25:45.152Z

I’m not sure I understand. Doesn’t Xtensa apply to esp32, instead of stm32? Or are you saying that in general some choices were made, due to the lack of Xtensa support, that we need to use macho for stm32 as well?

kubamracek · 2024-04-04T16:33:13.582Z

The note about Xtensa support in LLVM and Clang was a reply to a previous post (Embedded Swift Example Projects for ARM and RISC-V Microcontrollers - #8 by mickeyl).

Using Mach-O files for firmware really is unusual. Other examples in the repo use ELF. It would be a great idea to also provide ELF versions of these Mach-O only examples, yes.

But we wanted to show what it would look like to use Mach-O too, it's much simpler to link, and until very recently we didn't have an ELF linker in the macOS Swift toolchains (as of the latest 'main' toolchain, it now has lld). Also, at the end of the day, a linked binary still needs post-processing and conversion into a raw firmware, so both Mach-O or ELF headers and structure ends up being removed anyway.

orobio · 2024-04-04T16:43:27.366Z

kubamracek:

The note about Xtensa support in LLVM and Clang was a reply to a previous post

Ah, that makes sense!

kubamracek:

It would be a great idea to also provide ELF versions of these Mach-O only examples, yes.

But we wanted to show what it would look like to use Mach-O too

Clear. Perhaps I’ll have a look at it when I find some time. Thanks!

fumoboy007 · 2024-04-05T01:37:59.867Z

Thanks for the detailed answers!

kubamracek:

This is a fair request, but at this point the example code is trying to avoid building abstractions, it's instead trying to "show all that's involved" because that serves the educational/demonstration goals of these examples projects.

Absolutely, I agree with that! I was just thinking about whether we had any longer-term plans to make all this easier for n00bs like me.

kubamracek:

The bits that need to be flashed onto the device need to be raw bytes written to a particular memory address. This means that executable file formats like Mach-O or ELF are not suitable -- there is no support for Mach-O or ELF in the hardware. So instead this step extracts the raw code and data segments/sections, with specific well-known addresses where we expect to load them. Application.bin is the raw representation of the firmware suitable for direct flashing onto the device. There is quite a bit more complexity in this, and sadly it is again device/vendor/chip specific and doesn't generalize easily.

I see! Could a linker script be used to encapsulate the device/vendor/chip-specific details of the firmware layout? Then, perhaps the firmware extraction step could be eliminated because the linker could output the firmware directly:

@echo "linking..."
clang ... \
  -fuse-ld=lld \
  -Wl,--oformat,binary \
  -Wl,-T,"$PATH_TO_LINKER_SCRIPT"

Imagine if manufacturers published linker scripts for their devices and developers could just pass the linker script to the linker without having to worry about the details of the firmware layout!

kubamracek:

Linking an embedded firmware binary is a very different step from linking a userspace dynamic executable -- the author of this example (@rauhul) probably split it out of SwiftPM for two reasons (1) it's such an important step that needs to get a lot of configuration exactly right that it's better to highlight what exact command is used for that, (2) in any more real-world situation, you are likely to also have some C/C++ code as part of your build, and vendor-provided libraries, etc. and you will probably want to still control your link step separately.

Hmm I guess what I found strange was that a library product had a main function. If the above linker script approach works, I wonder if we could introduce a new product type (perhaps named .firmware) that accepted a linker script as one of its parameters and outputted the firmware directly:

products: [
  .firmware(
    name: "Application",
    linkerScriptPath: "STM32F746G-DISCO.ld",
    targets: [
      "Application"
    ]
  )
]

Similar to a .executable product, swift build would output the Application.bin firmware directly, eliminating the linker step for applications that use only SwiftPM.

carlynorama · 2024-04-05T19:32:57.080Z

This is not how I'd personally recommend people blink their first LED (YET!), but for the committed it might be easier to look at how things go from Assembly to C first on small chips (better documented path). Here are some Assembly and C using the GNU tool chain on STM32 chips:

REALLY DETAILED 7 part Playlist. Very good explanations about compilers assemblers and linkers (for embedded). 100% gnu tool chain. Shows writing a chip start up script in C. Appears to be part of a course on UDEMY.
Mostly gnu tool chain, starts from the Assembly - “Bare Metal” STM32 Programming (Part 1): Hello, ARM! – Vivonomicon's Blog

Something to keep in mind, the Arm assembly for many of the smaller chips is the 16 bit "thumb" width. It's a different instruction set.

And just for fun - one of my favorite SAMD21 resources (Core M0) It's comments on a manufacturer provided linker script - so that is a thing. For the SAMD chips search github for "brief Linker script for running in internal FLASH on the $YOURPARTNUMBER" finds lots of things.

The most thoroughly commented linker script (probably) - Stargirl (Thea) Flowers

gnuoyd · 2024-04-06T02:02:42.000Z

Just wanted to chime in to say, I like the way you are thinking.

David

fumoboy007 · 2024-04-06T23:07:58.767Z

Thanks for the resources! Here’s another one that I just finished reading: Everything You Never Wanted To Know About Linker Script · mcyoung.

carlynorama · 2024-04-07T12:58:23.779Z

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

O’Reilly Online Learning

Making Embedded Systems, 2nd Edition

Interested in developing embedded systems? Since they don't tolerate inefficiency, these systems require a disciplined approach to programming. This easy-to-read guide helps you cultivate good development practices based on classic … - Selection...

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

orobio · 2024-04-07T18:56:23.640Z

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.

GitHub

Comparing main...linux · orobio/swift-embedded-examples

A collection of example projects using Embedded Swift - Comparing main...linux · orobio/swift-embedded-examples

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

kubamracek · 2024-04-07T20:09:45.563Z

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.

orobio · 2024-04-08T18:58:19.567Z

kubamracek:

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.

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.

Datagram · 2024-04-25T21:16:28.333Z

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?

kubamracek · 2024-05-08T20:24:12.183Z

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

kubamracek · 2024-05-08T22:55:16.858Z

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?

Datagram · 2024-05-15T19:01:05.799Z

Success with your patch and latest toolchain.
Thanks !

dom · 2024-06-13T21:36:44.201Z

Do you happen to know if Clang support for Xtensa is in progress? Any active issues/PRs that I can follow along with?

kubamracek · 2024-06-13T23:53:15.722Z

See discussion in this thread: Is there support for Xtensa LX7 cores?

willswire · 2024-06-19T14:32:32.754Z

I'm trying to get some basic network functionality working, and running into trouble. I've built the wifi modules in pico-examples for pico_w to verify my dev setup, but when pulling over some of that code into Swift, I'm having trouble.

I suspect the issue is with the CMakeLists.txtfile, although I'm not sure.

I've modified the necessary target link libraryentry to properly set CYW43_LWIP, but now I'm getting other errors:

In file included from /Users/willwalker/Developer/pico-swift/pico-sdk/lib/lwip/src/core/mem.c:59:
/Users/willwalker/Developer/pico-swift/pico-sdk/lib/lwip/src/include/lwip/sys.h:95:10: fatal error: arch/sys_arch.h: No such file or directory
   95 | #include "arch/sys_arch.h"
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
[84/180] Building C object CMakeFiles/swift-pico.dir/pico-sdk/lib/tinyusb/src/common/tusb_fifo.c.obj
ninja: build stopped: subcommand failed.

Here is my full project: GitHub - willswire/pico-swift at implement-networking

kubamracek · 2024-06-19T15:51:59.959Z

Your lwipopts.h file is empty, if you want to actually use lwip, you have to use that file to "configure it". See e.g. this example config from the official Pico Examples repo: pico-examples/pico_w/wifi/lwipopts_examples_common.h at master · raspberrypi/pico-examples · GitHub

willswire · 2024-06-19T17:16:44.711Z

Oh duh!! That was it. Thanks so much!!

For posterity's sake, I just brought over all of those definitions and interpolated them into my lwipopts.h file and it's working great now.