Perhaps I didn’t make it clear, but I won’t deny Raspberries Pis to be a high-value target and host platform. I just wanted to say that supporting Raspberry Pi as a host it self doesn’t involve embedded programming. The features you listed that makes Pi different don’t seem to be utilized by any part of the toolchain — so that’s what we need to support as a target instead of a host.
2 Likes
I understood that. My comment was meant to reflect that there is great value to doing the entire cycle on the Pi itself. For example running lldb with local copies of source directly on the the embedded device is something that most embedded programmers would love to do but they can't bc of the limitations of the embedded processor. The Pi can do that, and it can be done with the community-supported tool chains today. seems a shame not to continue to do so.
3 Likes
@rvsrvs I think the point is that Swift wants to have full support for all ARM64 hosts. One of the hosts that we should support fully is the Pi: the Swift project should aim to provide it as good an experience as any other host.
I think the point that @stevapple was making is that we probably don't need to consider the Pi as some kind of embedded target (despite its embedded-like capabilities) due to its relatively strong performance. Instead, it should be considered a fully-fledged ARM64 host, pretty much like any other.
The comment I actually wanted to make though is about @stevapple's last point regarding String:
From my understanding, this is a major reason why StringProtocol exists and why many stdlib algorithms are written against it rather than String proper. Swift could allow disabling String entirely as a build-time option for embedded targets and have AsciiString or something equivalently lightweight instead. String literals could result in AsciiStrings in that build mode, and they could be checked for ascii conformance at compile time in the same way UInt8(999) fails at compile time now.
I wouldn't want to have the semantics and capabilities of String pulled out from under me in embedded mode – this would be especially problematic in library code. On the other hand, algos written against StringProtocol should be expected to work on AsciiString too. What would be nice is to align on the requirements of that type for embedded targets and not have 5 different "low power" types, but hopefully just 1 or max 2.
1 Like
i think that misses the host/target distinction that @stevapple was making.
if i understand you correctly you are saying the Pi should be supported as host and target (which is the point i was making) @stevapple was saying the pi shd be only a target, ie the swift compiler toolchain shd not run itself on the pi, rather executables generated on toolchain hosts for the pi would be sufficient.
My point is to say that Pi developers for embedded systems like swift on the Pi precisely bc the entire toolchain can be run there.
Well, I believe I never had said that.
Yep, that’s what I meant to express:) Thanks @Geordie_J to bring it up more clearly.
@stevapple My apologies for misstating your position. I seem to have had it backwards.
Let me see if I can be more clear in what I'm saying though, because I'm still in disagreement with the last post above: the target/host distinction being drawn in this thread doesn't really work for folks developing on the Pi and is in a real sense a step backwards.
Most Pi developers would prefer to be a target like other embedded processors, provided the support were there. It is true that due to tireless efforts of a few people in the community, you can run the entire Swift compilation toolchain on the Pi. And it is true that you can't do that with other embedded devices - but that is not a good reason to classify the Pi as a "host" and not a "target" or not "embedded", it needs to be viewed as both.
Members of the community, myself included, went to the trouble of creating cross-compilation toolchains from the Mac to the Pi for a really good reason - we weren't productive using the Pi as a host, we wanted it as a target. And the reason we wanted it as a target is the same as the reason that Apple created x-compilation tools targeting the iPhone, even though the iPhone would be just as reasonable a host as the Pi: performance. It's just painfully slow to do all your development on the Pi, relative to being able to do it on the Mac. Just as it would be painfully slow to do all your compilation, debugging, and testing for your app directly on your phone. In fact, every argument that one could make about the Pi not being an embedded target and really being a host is true of the iPhone, bc the iPhone is actually far more powerful than even the Pi 4, not to mention the various flavors of 3 and Zero.
If I run the entire toolchain on the Pi for my projects, compilation build/deploy/test cycle times go up by easily an order of magnitude. And frequently the compiler runs out of memory and crashes. And test suites take forever to run. Cross-compilation and unit testing of code Pi code on the Mac is amazingly faster once you are able to perform the magic to make it work. The problem today is that working that magic is a very obscure skill.
There are certainly plenty of people in the Pi/Swift dev community who do do everything on the Pi. But everyone I know in that community would be ecstatic if Apple were to provide even a minimally similar experience to Pi development that they provide to iPhone development. Let me hook up my Pi to my Mac via a USB cable, do all compilation on the Mac, deploy to the pi with a button press and launch a debugger that worked perfectly across the wire and let me debug Pi GPIO programs from my Mac and I'd never want to run the swift toolchain on the Pi again. However, this seems an unlikely prospect. Now, do I expect to ever see Apple provide a Pi simulator like they do for all their own devices? Not in the least. But there are some very nice intermediate options available especially in the form of x-compilation.
Yes, the Pi can be a host for the compiler and that's nice... but not particularly useful. And if classification of the Pi as a "host" means we are excluded from the tools available to "targets", I for one am going to be really disappointed because it sort of seems to me to miss what the community really needs.
My point here and in the call has been that, for the Pi to have a good swift dev experience, we need cross-compilation, remote debugging, host-based testing tools and smooth deployment, just like other embedded devices. And we need those x-compilation tools much more than we need the on-device tools (except maybe for lldb and if that worked reliably over the wire, not even then). But for now, the best we can do in many cases is to use the Pi as its own host. But that's a second-best option IMHO.
3 Likes
Apologies for reviving an old thread but see Embedded Swift where a vision for a possible first class support for embedded programming is presented.
4 Likes
Did anything ever become of this? I'm interested in embedded (aka bare metal) operations only. Not interested in kit-boards with monolithic systems like Raspberry.
Not to offend the RPB crowd, great computers, but a full computer with an operating system, it's not an embedded system.
I believe that the challenge in this is that Swift needs a supporting p-code engine aka pre-existing Swift virtual machine to run upon which sort-of eliminates it from being useful as a language in embedded systems... or is there a effort out there to produce platform assembly code platform from actual compiled Swift code?
Think of this as how would you write the code for the processor in the Thunderbolt 4 cable PIC processor... that's real embedded work. Embedded code usually gets loaded when the processor powers up from a known named location, has a do-loop, and there is nothing short of hardware interrupts that can redirect the processors operation because the embedded code owns the processor.
What makes you think this?
Swift already compiles (and always has) to machine code for the target platform.
1 Like
I was reading that it required the ObjC runtime, does not have deterministic memory management and predictable execution times necessary for real-time code to guarantee response time intervals across execution cycles and other disqualifiers for embedded work. I recall reading that Swift's runtime environment requires a fairly large set of libraries which at the time sounded like a p-code engine.
Your note made me dig further, build a "var x : Int = 0xC0DE" 1 line of code app (SwiftMin) to see what it did. Part of what I see is what appears to be a fairly large library load:
FORCE_LOAD_$_swiftCoreFoundation.swift
FORCE_LOAD$_swiftDarwin.swift
FORCE_LOAD$_swiftDispatch.swift
FORCE_LOAD$_swiftFoundation.swift
FORCE_LOAD$_swiftIOKit.swift
FORCE_LOAD$_swiftObjectiveC.swift
FORCE_LOAD$_swiftXPC.___swift_reflection_version.swift
FORCE_LOAD$swiftFoundation$_SwiftMin.swift
FORCE_LOAD$swiftObjectiveC$_SwiftMin.swift
FORCE_LOAD$swiftDarwin$_SwiftMin.swift
FORCE_LOAD$swiftCoreFoundation$_SwiftMin.swift
FORCE_LOAD$swiftDispatch$_SwiftMin.swift
FORCE_LOAD$swiftXPC$_SwiftMin.swift
FORCE_LOAD$swiftIOKit$SwiftMin.$s8SwiftMin1xSivp
So I believe to your point, not a runtime engine; but given what I see I suspect somewhat larger runtime requirements than some runtime pseudocode interpreters. Am I reading this wrong?
None of these are required for the code that you wrote; they are presumably being pulled in as a result of how your "app" is built. You might be interested in @kubamracek's recent blog post which has some examples of Swift running in more constrained environments without dependencies.
3 Likes
Thanks, I'll check kubamracek's blog post.
I would like to be able to switch over to Swift (convert my years of code libraries) but it will take being able to use Swift directly within embedded code architectures. I was thrilled when I found this page by chance; especially talking about 2K / 32K microcontroller models and code for ECUs. But then saw the dates 
.
Thank you for the replies!