Call for interest (video call kickoff ) - using Swift for embedded / bare-metal / low resources programming

As I promised weeks ago, I'd like to set up a "call for interest" in discussing community investment using Swift for embedded / bare-metal / low resources programming. There was vocalized interest in creating a workgroup (or workgroups) that focused on these areas:

I want to host a video conference call where we can bring folks interested in these areas together to explore exciting directions! The call covers a wide range of potential investments, and in the end, if there is enough interest and activity, I can see the formation of multiple Swift workgroups.

To provide some more background context for the post, I'd like to shout out the excellent post by @andyliu, which covers a lot of relevant concepts and terminology:

Interested in participating in the video call?

I am looking to schedule the video call sometime during the weeks of May 9 or May 16, where those interested can gather together and explore opportunities for collaboration. There may be interest in participation from individuals spanning a wide range of timezones, so I'd like to survey what times work. It might not be possible to find a time that works for everyone, but we can see what we can do!

I've created a forum link to create a partially constructed direct message to me for those interested in attending the call. Please indicate the days and times that work for you (including being clear on the timezone). Once I figure out the timing, I'll follow up with details.

33 Likes

Hi, I tried to indicate an interest by creating a message on the forum link , but it is not possible for me to send you this direct message.

You might have disabled direct messages?

Hi Axel,

I've been receiving messages from others. At any rate, the forum link would have populated a message that looked like this:

During the dates of May 9-13 or 16-20, I am interested in participating in a video call for a "call for interest" for discussing community investment using Swift for embedded / bare-metal / low resources programming.

The following days and times (please include timezone) work for me:

If you can provide me a list of times (with timezones) as a response here, that would work for me!

Ted

Happy to jump on a call related to this ! Open both weeks with a few days warning .

It's weird, but I hope you received my message, as I also received an error on the reply I sent you. Probably because I use a different email in the forum than on my business email.

I'll repost it here:

During the dates of May 9-13 or 16-20, I am interested in participating in a video call for a "call for interest" for discussing community investment using Swift for embedded / bare-metal / low resources programming.

The following days and times (please include timezone) work for me:

Any workday, from 9:00 - 22:00 CEST (Amsterdam, NL), this translates I believe to
0 PM to 1 PM in American units PDT. (which is 13 hours :flushed:)

1 Like

Hi Ted,

Probably it is disallowed because I recently signed up for the swift forums. These are the error messages I get:

Ah, as this message was also bounced, but this time with a proper error message, it is probably because I signed up using my github email, which is not my normal email.

Let’s see if this flows after I added my normal email to the forums…

Nope: third time is a charmer?

1 Like

Update

Thank to everyone who responded! I have scheduled a call for May 19 at 9AM PST. If there is anyone else who is interested in attending, please reach out to me!

3 Likes

I'm having the same issue as others with sending a DM to you. If it's possible to still join the call tomorrow I would love to join. I've been working with @carlos42421, @axello, and others on Swift for microcontrollers.

Same as Axel and Paul, I will try to join, can't DM you.

I have sent DMs to everyone who responded on this thread saying they could not DM me.

1 Like

More meetings ahead ? We would like to participate :slight_smile:

It was a good call. I have some rough notes to stitch together that I'll post (hopefully soon). I'll also received some suggestions from various folks on what they'd like see come next. I hope to circle back with all that signal soon and suggest possible next steps. In the meantime, I encourage anyone to comment on this thread if they have thoughts and suggestions.

7 Likes

Thanks @tkremenek for arranging this discussion. I'll show some opinions from my side.

Many software engineers may be quite unfamiliar with the embedded field and feel confused. Low-performance and limited resources seem to be their first instinct, and there is not a really clear definition to clarify what embedded development really does. In fact, it can include the work related to a few cents worth of MCUs, or powerful computers with a general architecture. However, the different scenarios need different solutions on the Swift side. To facilitate our later discussion, I would like to show my understanding of embedded development as a hardware engineer:

  • Andriod/Linux: it is really the same as the standard Linux app development. The only demand is better support for the higher level cross-compile tooling.

  • High recourses MCUs: nowadays, the performance and resources of MCUs can even rival the mainstream computers in 2000, except that they cannot run the general OSes (non-MMU). I believe these MCUs can support the standard Swift development. In addition to the better cross-compile support, I still need to target a mainstream RTOS. In this way, the Swift language can reach its full potential, especially with its various advanced characteristics. This is what I am most interested in, and I will talk about it later in next comment.

  • Low recourses MCUs: this should be the first impression of most developers. Arduino, MicroPython, embedded rust, etc. all focus on this area and have gained a large market share. If Swift wants to have its place, the binary size absolutely matters (of course smaller binary size is welcomed anywhere). A significant optimization/modification of std/runtime/LTO may thus be required: minimize the std, disable some advanced characteristics (Lazy properties, Copy-on-Write feature, etc), place variables in stack instead of heap explicitly, etc.

  • Most restricted field: IMHO, the programming language itself doesn’t matter any longer in this case. It depends largely on the domain experience of those large suppliers. They provide specific tools for engineers to convert control models into safe code which conforms to the domain specifications. Honestly speaking, it’s hard for any general programming language (even C) to have an important role in this field. It all depends on the relevant committees who make the rules and standards, like BMW/Bosch.

The High recourses MCU systems have been developed rapidly in recent years and don’t have a widely adopted development model. But the other three categories already have their commonly used development model and procedure. Although these four categories require different demands, the most common one should be a turnkey solution for cross-compile tooling which has been discussed sometimes in this forum. Some guys also created tools for it and as I know, SSWG is also working on this currently. Something like rustup would really be helpful for the compilation for different hardware/OSes (ARM Linux/MCU/WASM), and what's more, remove the barrier for those who aren’t iOS/macOS developers. I hope the Swift team could discuss more in the forum about the related work, so developers with different platform backgrounds could share their opinions.

The turnkey cross-compile support is so important, but it relates more to higher-level tools (such as SwiftPM) and platform-related libraries/SDKs, not the compiler itself, so I wonder is it necessary to create a dedicated workgroup for better tooling support?

7 Likes

Standard Swift app in a concise hardware environment

So far, the Swift community has made several attempts, including server, AI, UI DSL, etc. and is still exploring the boundaries. Now Machine targeted field (such as IoT) is becoming a new era for the next decades. If we do want the Swift language to become a real system-level language, then this field cannot be neglected. And what I am trying to do is based on a natural idea: If Swift is targeting different platforms, then why not RTOS?

For some fields, Linux is too complicated, plus it requires complex hardware architecture. Fortunately, the Linux foundation introduced Zephyr for the fields where Linux is notably absent. I have confidence in this new combination: concise Swift-based software architecture + simple and reliable hardware architecture. It would open up a whole new field.

Swift is really suitable for building complicated app models. As for the hardware, you can see, in the image below, TI just published an 800MHz MCU with 4 cores, NXP introduced a 1GHz MCU. I cannot imagine how I develop applications for such powerful processors using only the C language.

What I have done to run Swift code with Zephyr

I’ve introduced my work in detail in my previous post, I’ll give a brief list here:

  1. :white_check_mark: Modify Swift compiler to support ARM-Cortex M arch
  2. :white_check_mark: Cross-ompile Swift std for ARM-Cortex M arch
  3. :ballot_box_with_check: Bind Swift runtime with Zephyr just as porting the runtime to other general OSes
  4. :o: Bind Swift concurrency implementation with Zephyr

What I’ve got: Standard Swift app can absolutely run on non-MMU CPU

  • Now, almost all pure Swift code (without Foundation and Concurrency) can run normally on the MCU board.
  • After all stuff (Zephyr, Swift std/runtime, app) is statically linked together, the binary size (raw binary, not ELF format) is around 2.5MB which can run perfectly on an 8MB ROM, and 1MB (Internal) RAM MCU board.

I’m full of expectations towards its future development.

What support I need to make this better

  • Swift runtime has been bound so tightly to the general OSes. And it mainly uses macros in multiple runtime C++ files to realize it. However, as I am not specialized in programming language/compiler, it’s not easy to clarify each part in runtime and its role. So I am wondering if it is possible to divide the part related to the OS interfaces into more organized layers to make the runtime more like a standard C++ library, thus it can be more convenient to get compatible with different OS interfaces. If this solution needs to involve a huge change, a brief guide about runtime framwork would be of great help.

  • Better ways for I/O bound operations and multicore task management are desperately needed in MCU world at present. The Swift concurrency feature opens up new possibilities. However, this now depends on a lot of external libraries. Does the Swift team have a plan to implement concurrency feature in the runtime-level library and exclude other external dependencies? Just as what you have done with libICU?

  • In the RTOS field, the mostly used compilers are still commercial ones, such as IAR, KEIL, and GCC is almost the only open source tool widely used. The current RTOS involves many toolchain-specific designs, which make it hard to be treated as a normal library. Our current development procedure is similar to that of the Embedded Linux app, but in a much more simplified way: the BSP (Board support package) and kernel (Zephyr) normally serve as a batch of binary libraries in ELF format, then you will still need some stuff provided by gcc toolchain during the linking time, such as libstdc++, libgcc, etc. In short term, I have to choose gcc ld as the final linker. Again, if Swift team could provide better tooling integration, that would be of great help!

12 Likes

Update: With the language workgroup / core team changes announcement now out, my hope is to circle back on this topic shortly. With WWDC and the stuff that was just announced, this all got severely delayed on my end.

8 Likes