3 ms·

Hey Steve, thanks for commenting here. As a person who is trying to get into embedded development but who knows very little, can you explain the challenges of h

Hey Steve, thanks for commenting here. As a person who is trying to get into embedded development but who knows very little, can you explain the challenges of having a language support most/all embedded platforms? I’m guessing you would need to support old versions of gcc that or something like this? Or be able to compile things with each platform special flags? It seems like even C projects have a hard time being portable. People even avoid cmake because of the large dependency and the fact that it is cross platform until it isn’t.

pjmlp 8y ago
Not Steve, but do know or or two things about embedded and portable C code. First of all, most embedded development makes use of bare metal, where the libraries take the role of an OS, or they use a specialized OS from the hardware vendor. Just using pure ANSI C isn't possible, because the standard does not expose the hardware features from the underlying platform, so the alternatives are to use Assembly, or language extensions. Naturally language extensions are more convenient to use, so that is what most developers end up doing. Also there are many types of embedded platforms, you can be targeting anything between a tiny PIC with 8KB FLASH RAM to a powerful multi-core ARMv8-A with 8GB. So the toolchain must allow for customization of what actually gets linked into the final binary, and the runtime must be as thin as possible. Then there this the drivers story, each vendor gives you their own SDK, which most of the time is the only way to access their devices. It is typical for open source projects to reverse engineer some of those SDKs to get the necessary information for linker maps, compiler flags and driver information. Regarding Rust, there is an ongoing effort to create a embedded library for hardware drivers, as means to write portable code. https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust
steveklabnik 8y ago
The first issue is to have a compiler backend for that target. Someone has to write that. gcc supports more targets than LLVM. Then, you have to make sure that it doesn't break; this means running on that target in CI, somehow. Given that you're already talking about devices that may not even have an OS... emulation can work sometimes? Then, there's ecosystem stuff. You probably want some sort of HAL and support for not just one platform, but all of the platforms you're deploying to. So that's more work... Finally, some platforms are proprietary and basically give you their own fork of gcc and so C is pretty much your only option anyway.

pjmlp 8y ago

Not Steve, but do know or or two things about embedded and portable C code. First of all, most embedded development makes use of bare metal, where the libraries take the role of an OS, or they use a specialized OS from the hardware vendor. Just using pure ANSI C isn't possible, because the standard does not expose the hardware features from the underlying platform, so the alternatives are to use Assembly, or language extensions. Naturally language extensions are more convenient to use, so that is what most developers end up doing. Also there are many types of embedded platforms, you can be targeting anything between a tiny PIC with 8KB FLASH RAM to a powerful multi-core ARMv8-A with 8GB. So the toolchain must allow for customization of what actually gets linked into the final binary, and the runtime must be as thin as possible. Then there this the drivers story, each vendor gives you their own SDK, which most of the time is the only way to access their devices. It is typical for open source projects to reverse engineer some of those SDKs to get the necessary information for linker maps, compiler flags and driver information. Regarding Rust, there is an ongoing effort to create a embedded library for hardware drivers, as means to write portable code. https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust

steveklabnik 8y ago

The first issue is to have a compiler backend for that target. Someone has to write that. gcc supports more targets than LLVM. Then, you have to make sure that it doesn't break; this means running on that target in CI, somehow. Given that you're already talking about devices that may not even have an OS... emulation can work sometimes? Then, there's ecosystem stuff. You probably want some sort of HAL and support for not just one platform, but all of the platforms you're deploying to. So that's more work... Finally, some platforms are proprietary and basically give you their own fork of gcc and so C is pretty much your only option anyway.