#embeddedswift — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #embeddedswift, aggregated by home.social.
-
📰 It's time for July Wasm updates: https://forums.swift.org/t/swift-for-wasm-july-2026-updates/88673
Emscripten-hosted toolchain support, async typed throws fixes; WasmKit implemented Relaxed SIMD, extended-const, and shared linear memory, and now supports ESP32-C6; new JavaScriptKit and @elementarycodes releases, and more!
#WebAssembly #Wasm #WASI #EmbeddedSwift #SwiftLang #JavaScript
-
📰 It's time for July Wasm updates: https://forums.swift.org/t/swift-for-wasm-july-2026-updates/88673
Emscripten-hosted toolchain support, async typed throws fixes; WasmKit implemented Relaxed SIMD, extended-const, and shared linear memory, and now supports ESP32-C6; new JavaScriptKit and @elementarycodes releases, and more!
#WebAssembly #Wasm #WASI #EmbeddedSwift #SwiftLang #JavaScript
-
Someone built an entire operating system in Swift — and it's not a toy. TCP/IP stack, HTTP server, and an AI inference server, all running on Embedded Swift.
The "Swift can't do systems programming" argument just lost a lot of ground. Experimental, but it proves Swift lives at the metal.
🔗: https://swiftos.tech by Andrey Sapunov
-
The GameBoy cart PCBs arrived earlier this week and they look so nice. The RP2040 portion all appears to work perfectly, was able to load the binary with no issues, which is a relief. Now I need to go through and update the EEPROM flashing code to match the final pin out and hope my address decoder circuit actually works correctly. Fingers crossed
-
The GameBoy cart PCBs arrived earlier this week and they look so nice. The RP2040 portion all appears to work perfectly, was able to load the binary with no issues, which is a relief. Now I need to go through and update the EEPROM flashing code to match the final pin out and hope my address decoder circuit actually works correctly. Fingers crossed
-
Believe it or not this is wireless!
-
Believe it or not this is wireless!
-
Not working quite yet, but the Pico Debug Probe is so much easier than manually wiring up a second Pico. The backtrace seems to suggest there's a crash when the WiFi stack tries to use an async context, but I’m just following the examples, so I'm not sure what the issue is.
Seems unlikely that calling the C methods from Swift would be causing a problem, but I really don't know how the Pico async stuff works
-
Not working quite yet, but the Pico Debug Probe is so much easier than manually wiring up a second Pico. The backtrace seems to suggest there's a crash when the WiFi stack tries to use an async context, but I’m just following the examples, so I'm not sure what the issue is.
Seems unlikely that calling the C methods from Swift would be causing a problem, but I really don't know how the Pico async stuff works
-
Just one more debugging probe, then it’ll work…
-
Just one more debugging probe, then it’ll work…
-
Added a nice little EEPROM page debug view to the app. Now after writing it shows a table of all the pages and the CRC16 checksum for each. The device returns a locally calculated checksum after writing a page
-
Added a nice little EEPROM page debug view to the app. Now after writing it shows a table of all the pages and the CRC16 checksum for each. The device returns a locally calculated checksum after writing a page
-
Added a simple CRC check to the data I was writing and immediately found the problem. Wasn't even on the embedded side. When grabbing a range of bytes to send over USB I was using a normal range `start..<end` except that `end` was calculated to be a valid address (so 0x40 bytes would have an end address 0x3F) so I never wrote the last byte. Changing to a closed range did the trick and my CRCs started passing.
Writing the full ROM again. It's kind of slow
-
Added a simple CRC check to the data I was writing and immediately found the problem. Wasn't even on the embedded side. When grabbing a range of bytes to send over USB I was using a normal range `start..<end` except that `end` was calculated to be a valid address (so 0x40 bytes would have an end address 0x3F) so I never wrote the last byte. Changing to a closed range did the trick and my CRCs started passing.
Writing the full ROM again. It's kind of slow
-
Noticed a strange bug with reading or writing to the EEPROM. Values up to 0x7F work just fine, but 0x80 and over seem to be losing the top bit. I'm shifting the byte to and from the data pins the same way, using .trailingZeroBitCount on the mask, and in a playground that shifting works just fine.
I guess an embedded project hasn't really started until you break out the logic analyzer
-
Noticed a strange bug with reading or writing to the EEPROM. Values up to 0x7F work just fine, but 0x80 and over seem to be losing the top bit. I'm shifting the byte to and from the data pins the same way, using .trailingZeroBitCount on the mask, and in a playground that shifting works just fine.
I guess an embedded project hasn't really started until you break out the logic analyzer
-
With this project I'm trying something new in terms of mixing SPM and CMake. The two are still wholly incompatible, but I'm architecting everything in normal targets and making extensive use of `#if hasFeature(Embedded)` so as much as possible can compile normally and the embedded compilation is really just a variant of the main code, not some special version.
It takes care of most of the duplicate code, with the exception of SPM dependencies
-
With this project I'm trying something new in terms of mixing SPM and CMake. The two are still wholly incompatible, but I'm architecting everything in normal targets and making extensive use of `#if hasFeature(Embedded)` so as much as possible can compile normally and the embedded compilation is really just a variant of the main code, not some special version.
It takes care of most of the duplicate code, with the exception of SPM dependencies
-
Well how about that? The EEPROM is working!
-
Well how about that? The EEPROM is working!
-
Huh, I did not expect the first time I'd use typed throws in Swift to be because embedded Swift can't throw a generic `any Error`
-
Huh, I did not expect the first time I'd use typed throws in Swift to be because embedded Swift can't throw a generic `any Error`
-
Been working on writing an EEPROM flasher in Swift for the RP2040 and I really wish I could compile the project in Xcode to get in-line warnings and errors.
Also, while I’m wishing for things: an RP2040 simulator. Nothing fancy, would really just need a visual representation of the GPIO
-
Been working on writing an EEPROM flasher in Swift for the RP2040 and I really wish I could compile the project in Xcode to get in-line warnings and errors.
Also, while I’m wishing for things: an RP2040 simulator. Nothing fancy, would really just need a visual representation of the GPIO
-
PlaydateKit now includes an xkcd reader example, thanks to @paul!
It’s a great demo of the Playdate networking APIs and shows how you can integrate C libraries for things like QR code generation and PNG decoding with Swift’s C interop.https://github.com/finnvoor/PlaydateKit/tree/main/Examples/Xkpd
also available on itch:
-
PlaydateKit now includes an xkcd reader example, thanks to @paul!
It’s a great demo of the Playdate networking APIs and shows how you can integrate C libraries for things like QR code generation and PNG decoding with Swift’s C interop.https://github.com/finnvoor/PlaydateKit/tree/main/Examples/Xkpd
also available on itch:
-
⚙️ I've just merged a big change to the PlaydateKit build system. It now uses the SwiftPM build system for almost all of the build as opposed to a bunch of fragile individual commands and flags. This means:
- 1.5x faster clean builds
- 9x faster incremental builds
- Much more stable linux builds
- Possibly Windows support soon?The embedded Swift team has been making tons of improvements, it's easier than ever to get started with #EmbeddedSwift on #Playdate!
https://finnvoor.github.io/PlaydateKit/documentation/playdatekit/
-
⚙️ I've just merged a big change to the PlaydateKit build system. It now uses the SwiftPM build system for almost all of the build as opposed to a bunch of fragile individual commands and flags. This means:
- 1.5x faster clean builds
- 9x faster incremental builds
- Much more stable linux builds
- Possibly Windows support soon?The embedded Swift team has been making tons of improvements, it's easier than ever to get started with #EmbeddedSwift on #Playdate!
https://finnvoor.github.io/PlaydateKit/documentation/playdatekit/
-
I'd like something to keep tempo with while playing guitar, so let's design a drum sequencer using #EmbeddedSwift and the very limited set of parts I have laying around.
-
I'd like something to keep tempo with while playing guitar, so let's design a drum sequencer using #EmbeddedSwift and the very limited set of parts I have laying around.
-
Oh neat, I guess at some point I upgraded my CMake install to 4.0 which I guess drops compatibility with CMake 3.5 which the 1.5 branch of the RP2040 SDK uses. I can't update to the 2.0 branch because of some incompatibility when building Swift 😖
-
Oh neat, I guess at some point I upgraded my CMake install to 4.0 which I guess drops compatibility with CMake 3.5 which the 1.5 branch of the RP2040 SDK uses. I can't update to the 2.0 branch because of some incompatibility when building Swift 😖
-
So it seems like the same symbols are being produced by both my test library and test executable. I kind of figured that's what whole module optimization was for. Or maybe I need to find the right command for the linker?
-
So it seems like the same symbols are being produced by both my test library and test executable. I kind of figured that's what whole module optimization was for. Or maybe I need to find the right command for the linker?
-
Also, as cool as I think it would be to figure this all out on my own, if someone else has already done it please tell me.
On the other hand maybe I get a good conference talk about of the project. "So at first I was confused, and then I swore at the compiler for a while, and then it worked!”
-
Also, as cool as I think it would be to figure this all out on my own, if someone else has already done it please tell me.
On the other hand maybe I get a good conference talk about of the project. "So at first I was confused, and then I swore at the compiler for a while, and then it worked!”
-
Exciting progress? on building my RP2040 test project with Swift. I think I got the right toolchain installed because now instead of “No such file" errors I'm getting so many duplicate symbol errors the compiler gave up! No idea where to go from here
-
All of the parts for my button project finally came together. I redesigned the enclosure to make the PCB and button easier to install and added an ARRI anti-twist mounting system to the bottom.
I also borrowed a little bushing press and printed a jig to add the threaded inserts. -
Still working on the specifics, but I think something like this might work well. It makes it easy to show controls and information for a device that all updates automatically from the store of known devices and separates out a default state for when the device is disconnected.
`DeviceView` is generic soup, but there might be a way to clean some of that up
-
Did some reorganization and put the shared models in their own target that can be conveniently referenced via SPM on the client side and, less conveniently, from the CMakeLists file for building the Pico binary. But at least if I make changes I'm no longer copying and pasting for each platform.
Would still love some kind of SPM support for building embedded binaries, but even this is a nice step forward
-
I’m fairly pleased with this. All of the features are controlled from the UI, which matches the data sent back from the Pico. Now to find a use for it