Since a few months I would like to start with embedded Swift on microcontrollers, but I got a bit overwhelmed by it so I never started.
Can someone recommend me an easy microcontroller to start with and where is the best store to buy any components, preferably one in Europe?
Since I develop also apps for Apple platforms I would like to build an app that communicates with the microcontroller to maybe read out some data of sensors etc. Would gRPC work for this or does the microcontroller need WIFI? Or is there a better protocol for the communication?
Currently I have a microcontroller from MadMachine (MakerKit, Photo below), would this work or do I need something else?
The MadMachine board will work for embedded Swift development, but you would need to start with the MadMachine SDK to use it for running Embedded Swift.
If I could offer a suggestion, use the simplest communication protocols possible at the start of your project, and then switch to a different protocol once you have the primary functionality of your project working. This way, you don't have to troubleshoot multiple things at once.
A UART serial connection from your microcontroller to your computer is probably the easiest protocol to set up when you are first starting out.
What you have will work for what you want. If you want to use a different vendor's hardware, the original Raspberry Pi Pico with headers and a Pico Debug Probe would also work for what you want, you can buy both for about €17.50 not including shipping. The bottom of the Pico page has a web form that lets you select the country you are in, so you can see who sells Raspberry Pi hardware in your country.
You can use the VSCode "Serial Monitor" extension with the Pico Debug Probe as a cross-platform way to quickly set up your host computer to view UART serial data coming from the Pico board
The debug headers on the Pico "H" board will make it easier to connect to the Pico Debug Probe, the Debug Probe includes a special "JST-SH" cable just for this purpose.
There are lots of Pico C and Swift examples on the web, including in the swift-embedded-examples repo, that way you can see how others have solved problems similar to ones you may encounter.
I forgot to mention, some of the examples in the swift-embedded-examples repo have Wokwi configurations, so you can run those examples inside of the Wokwi embedded device simulator, either on the web or on your computer (requires a subscription to run on your computer).
Here's the summary of my possibly wrong understanding.
wasm32-unknown-unknown doesn't have libc, filesystem, sockets, or OS.
wasm32-wasip1 / wasm32-wasip2 use wasi's implementation of libc, usually musl-based.
wasm32-unknown-emscripten has a fairly complete libc and POSIX emulation.
The browser js environment also does not provide libc.
At its base, wasm is just a virtual CPU. It does not guarantee anything like malloc, printf, open, read, time, or (originally) threads.
The new -threads variant is nice but it'll only work in a browser session if certain headers are sent to enable multithreading on that page, thanks to safety features (not specific to wasm) put in place after spectre/meltdown.
Embedded Swift for wasm wants to avoid depending on libc, so I usually roll my own everything to keep it clean. I don't use Foundation either if size is an issue. For example that has allowed the upcoming Embedded Wasm SwiftXState to compile under 500kb while having JSON in/out support and the full SwiftXState base library.
libc availability is independent of the triple, unknown literally means that platform is unknown (unspecified). While it isn't common to build wasi-libc for this triple, in theory you could with some additional effort, and then you'd get some or all of these features.
This sounds correct to me.
Yes, wasi-libc is based on musl. It is also fairly complete and does provide "emulation" for some POSIX-ish APIs where possible. I don't think it's technically correct to emphasis completeness for Emscripten libc, somehow implying that wasi-libc is incomplete. Emscripten focuses on supporting legacy code, while wasi-libc like WASI itself is forward looking and more willing to introduce breaking changes. That doesn't mean that one of them is more complete than the other.
That's correct, but seems quite obvious that JavaScript environment (like any other non-C environment, e.g. Python or Java) would never have a goal provide a libc in the first place?
Correct, but also obvious, neither ARM nor RISC-V provide these features, as they're platform/OS features and not CPU features.
It will also work in a non-browser wasip1-threads-compatible runtime, e.g. in WasmKit after the corresponding PR is merged.
I don't think it's useful to anthropomorphise a mode of the Swift compiler and to say that it can "want" or "need" anything. Embedded Swift targeting WASI does depend on wasi-libc, but users only pay for what they use. If your code compiled with Embedded Swift SDK for WASI doesn't use some WASI features, those can be stripped away by the build process.
That's nice, because dragging forty years of Unix compatibility along just to get basic runtime services can feel absurd. I hope for a future where libc is gone and replaced by a libc-ABI-compatible module written entirely in Swift :D
