4 ms·
The main problem with embedded software is that it usually lacks many facilities commonly found in desktops or servers. For instance, dynamic memory allocation
by Ecco 2y ago
The main problem with embedded software is that it usually lacks many facilities commonly found in desktops or servers. For instance, dynamic memory allocation or access to a filesystem.
This potentially results in a big fragmentation of the ecosystem. For instance, even though “embedded C” as a language is really just C, the vast majority of C libraries cannot be used on embedded systems because they’ll use the occasional malloc, mmap or fopen call.
Rust is particularly good at this, with its [no_std] directive that is well documented and used in a wide variety of libraries.
I wonder how Swift plans to address this.
- tomcam 2y ago> The main problem with embedded software is that it usually lacks many facilities commonly found in desktops or servers. For instance, dynamic memory allocation or access to a filesystem. Very often dynamic memory allocation and file system access are explicitly forbidden from an embedded project. They can both cause security problems and unpredictable behavior.
- tomcam 2y agoInterested in understanding why the downvotes?
- SV_BubbleTime 2y agoYou are thinking about a level higher than embedded.
- bilkow 2y agoCare to elaborate? As I see it, the only restriction on embedded systems the parent has added is that it usually lacks filesystem access or dynamic memory allocation.
- SV_BubbleTime 2y agoTime, posix, threads, core, a lot of times MPU, an OS beyond a scheduler, file system, basically almost all abstractions you get on the levels above embedded.
- bilkow 2y agoYeah, I generally agree with you, but I don't see how the parent comment implies any of that
- flyingcircus3 2y ago"it usually lacks many facilities commonly found in desktops or servers." This is where they implied that operating system level functionalities are not found on computers without operating systems. The fragmentation that exists in embedded is due to the nature of embedded systems, not programming languages. PCs, laptops, and smartphones are general purpose computers. Just about everything else is an embedded device, hardware custom designed for a specific purpose, given just enough resources to accomplish its intended task. Writing software for a general purpose computer on top of a full OS can largely be done without caring about the underlying hardware. Writing embedded firmware without an OS is only possible through understanding the specific hardware you are targeting.
- therein 2y agoRust does it well with [no_std] but then seems to be dropping the ball with [restricted_std]. I recently set up an embedded-hal project for cortex-m and after some struggle, I was happy to get dynamic memory allocation and std working but the platform had a tier 2.5 support so I had to put [restricted_std] if I wanted to use it. But that means none of your dependencies can use std unless they also declare [restricted_std]. So now I have the stdlib but none of my dependencies can use it.
- sureglymop 2y agoInteresting. I never went as far as trying to make dynamic memory allocation work. But I really did have a good experience with rust. So many helper crates to make things just work (hal, pac, cortex-m, embedded-graphics, etc). And not to forget things like heapless which work quite well. Now I never did embedded development in any other language but in rust it was definitely nice for a beginner with everything already there and easily installable.
- w10-1 2y ago> I wonder how Swift plans to address this. Swift subsets the language and libraries (which the compiler inlines). No complicated strings or runtime metadata for generic existentials. And new features for ownership. Seamless C interop. There's a lot to it!