Embedded Swift is honestly very cool. I never really used Swift itself before, but I think it's a good niche since embedded dev could stand for another tool and the language is pretty nice. It also doesn't really suffer from most of the issues people have historically brought up with Swift (cross platform, slow compiles) etc as it is so small, at least to me. :)
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
Eh, most device interactions are mostly "build a command list and shared memory buffers" rather than the classic touch a a bunch of registers to perform the data plane work. UARTs are one of the last bastion of the old style, mostly because of how you want them so early in the boot process for debug out, it's nice to not have a shared memory/command list access pattern.
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
In fact, that's how i/o worked before DMA on many systems. Good times!
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
“Hack the Planet!”? “Mess with the best die like the rest”? WTF?