Hi everyone,
I've been experimenting with swift-embedded and went through the vision document, but I’m still a bit unclear on how the project aims to address some fundamental tasks, especially when it comes to Networking (URLSession or low-level equivalents), Filesystem operations, or sys-features and calls like dynamic library loading (utterly important in memory & power constraint environments).
For now, I’ve started to wrap esp-idf, FreeRTOS and Zephyr APIs along with other c/c++ libraries. However, I’m beginning to feel that this approach introduces a considerable amount of work and introduces unsafe and inconvenient code.
What makes this especially challenging is that I frequently find myself having to jump across different OS abstraction layers to clean up incomplete or inconsistent interfaces. These layers often blur the line between hardware and OS specifics, making things tedious and prone to mistakes.
I’m wondering if the Swift-Embedded working group has a strategy or vision for handling this common pain point. Specifically:
- Will swift-embedded include abstractions for core functionality, similar to
SwiftIO(or even build on / merge withSwiftIO)? - Are there plans to build on a specific (default) real-time OS e.g.,
Zephyr? - Is there an abstraction approach that handles everything above the
HALand lets us implement drivers where needed?
Right now, I feel that Zephyr has the most thought-through ecosystem compared to its competitors, but I’m not yet deep enough in the embedded space to fully understand all the potential pitfalls of using it as a core dependency.
I’d appreciate any advice on whether continuing to wrap Zephyr APIs is a solid long-term strategy or if I should consider alternatives, and on whats the vision/strategy for swift-embedded on a Foundation for embedded.
Thanks in advance!