3 ms·

I feel like half of what's here points to using rust or a rust like language as a good thing. Even I suppose C++ if you can use the pointer types to help yourse

by bfrog 6y ago

I feel like half of what's here points to using rust or a rust like language as a good thing. Even I suppose C++ if you can use the pointer types to help yourself.

nsajko 6y ago
> I feel like half of what's here points to using rust or a rust like language as a good thing. Which points exactly? Also, neither the Rust standard library, nor the C++ std::shared_ptr were designed with embedded in mind. Also, Rust is kind of experimental, not really a good choice for a system that is difficult to update. Not to mention only Intel and AMD64 platforms have Rust Tier 1 support.
- elwes5 6y ago
  One thing to keep in mind with embedded is size. Some projects you do not get to have std lib. It just does not fit. This is less and less of an issue as time goes on. But a few years ago 2k total memory (flash and RAM) was a real issue you had to conform against. Even that could seem huge for some platforms. Depending on the platform Rust or C++ may not be the first one I reached for. C is pretty compact if you strip the libs out. But usually at that point you may have to goto ASM just to make it fit. Had one project which had to be in python (platform dictated by customer). Did all the right style guide things. Classes, the works. Had to toss all of that out. As just by making classes subjected it to a 300 byte overhead per object. I had hundreds of the things. Half my memory was being used by object management. I needed that space for data. Out goes all the cool by the book things that seem right to do. Borderline a total re-write. I took those lessons to the C version. Right up until the new guy decided everything needed to be C++ and use std:lib and would not listen to me. Suddenly it did not even fit in flash and RAM even if you use both by about 5x much less any data needed. He had to spend weeks backing the changes out again. Even after re-stripping it even then the code size dictated we just could not use some platforms. Another thing to keep in mind is compiler maturity. C++ in the past 10 years has come a long way. But in these embedded platforms you may be working with a C++ tool-chain from the late 1990s (if you are lucky). Some of the toolchains shipped with these chips are in poor shape. They will never change unless you spend a lot of time bringing it up to something semi current. Getting a Rust tool chain on it? Maybe if you spent months messing around with it. Months where you could spend shipping product.
  - rcxdude 6y ago
    C++ can be written in a compact way: in fact some of it's features are useful in that regard. But you will probably want to turn off exceptions and RTTI (two features which are unfortunately not 'zero-cost').
    - elwes5 6y ago
      Like you say it can be done in a compact way. There are some gotchas with memory though. Like you point out RTTI and exceptions. Another one people forget about is the object overhead themselves. That is not zero cost on many compilers. There usually is an abstract struct that holds the vtable or something like one. That is so you can do those cool C++ things like inheritance and mutability. Most of the time when people say 'c++' I have found they do not mean the language which is decently compact. They mean the C++ std lib. It is a distinction many do not make unfortunately. It is becoming less and less of an issue as the more powerful SoC items have come down in price and have more memory/flash. The newer ones also usually come with a somewhat modern compiler stack. Also if you follow some of the MISRA standards in some projects it can even more radically change what you can and can not do.
      - bfrog 6y ago
        Rust avoids a lot of the C++ pitfalls out of the gate with a split core vs std library set. Panic handling and message formatting are something that however is a known drawback in debug builds. In release builds this gets optimized away in most cases.
- est31 6y ago
  > only Intel and AMD64 platforms have Rust Tier 1 support. Btw one of the main reasons for this is missing CI support. https://github.com/rust-lang/rfcs/issues/1795#issuecomment-308966293 https://github.com/rust-lang/rfcs/issues/1795#issuecomment-3... But of course there's always a way if you want it enough.
- rcxdude 6y ago
  Rust actually has a better standard library story than C++ here, since it actually has a segmentation between the 'core' and 'std' libraries, where 'core' contains stuff which doesn't require heap allocation. Makes it a bit easier to know what will be supported. (and tbh, the standard library is low on the list of reasons to use C++, especially in embedded) I think Rust has a lot of potential in the embedded space. I'm especially interested in if the async stuff will have power in making small and safe state machine writing easier: I think this could be extremely good at combining the power of stackfull tasks (which are wasteful on memory and less predictable) and state machines (which can be a pain to write, especially long sequential ones). If it lets you ship a product sooner with less bugs on a cheaper micro, I think it may be a strong proposition. Unfortunately given the industry is often unwilling to even consider C++ (and not for good reason: the reasons given for not using it or not even considering it are often based of off misconceptions or just outright falsehoods).

by bfrog 6y ago

I feel like half of what's here points to using rust or a rust like language as a good thing. Even I suppose C++ if you can use the pointer types to help yourself.

nsajko 6y ago

> I feel like half of what's here points to using rust or a rust like language as a good thing. Which points exactly? Also, neither the Rust standard library, nor the C++ std::shared_ptr were designed with embedded in mind. Also, Rust is kind of experimental, not really a good choice for a system that is difficult to update. Not to mention only Intel and AMD64 platforms have Rust Tier 1 support.

elwes5 6y ago
One thing to keep in mind with embedded is size. Some projects you do not get to have std lib. It just does not fit. This is less and less of an issue as time goes on. But a few years ago 2k total memory (flash and RAM) was a real issue you had to conform against. Even that could seem huge for some platforms. Depending on the platform Rust or C++ may not be the first one I reached for. C is pretty compact if you strip the libs out. But usually at that point you may have to goto ASM just to make it fit. Had one project which had to be in python (platform dictated by customer). Did all the right style guide things. Classes, the works. Had to toss all of that out. As just by making classes subjected it to a 300 byte overhead per object. I had hundreds of the things. Half my memory was being used by object management. I needed that space for data. Out goes all the cool by the book things that seem right to do. Borderline a total re-write. I took those lessons to the C version. Right up until the new guy decided everything needed to be C++ and use std:lib and would not listen to me. Suddenly it did not even fit in flash and RAM even if you use both by about 5x much less any data needed. He had to spend weeks backing the changes out again. Even after re-stripping it even then the code size dictated we just could not use some platforms. Another thing to keep in mind is compiler maturity. C++ in the past 10 years has come a long way. But in these embedded platforms you may be working with a C++ tool-chain from the late 1990s (if you are lucky). Some of the toolchains shipped with these chips are in poor shape. They will never change unless you spend a lot of time bringing it up to something semi current. Getting a Rust tool chain on it? Maybe if you spent months messing around with it. Months where you could spend shipping product.
- rcxdude 6y ago
  C++ can be written in a compact way: in fact some of it's features are useful in that regard. But you will probably want to turn off exceptions and RTTI (two features which are unfortunately not 'zero-cost').
  - elwes5 6y ago
    Like you say it can be done in a compact way. There are some gotchas with memory though. Like you point out RTTI and exceptions. Another one people forget about is the object overhead themselves. That is not zero cost on many compilers. There usually is an abstract struct that holds the vtable or something like one. That is so you can do those cool C++ things like inheritance and mutability. Most of the time when people say 'c++' I have found they do not mean the language which is decently compact. They mean the C++ std lib. It is a distinction many do not make unfortunately. It is becoming less and less of an issue as the more powerful SoC items have come down in price and have more memory/flash. The newer ones also usually come with a somewhat modern compiler stack. Also if you follow some of the MISRA standards in some projects it can even more radically change what you can and can not do.
    - bfrog 6y ago
      Rust avoids a lot of the C++ pitfalls out of the gate with a split core vs std library set. Panic handling and message formatting are something that however is a known drawback in debug builds. In release builds this gets optimized away in most cases.
est31 6y ago
> only Intel and AMD64 platforms have Rust Tier 1 support. Btw one of the main reasons for this is missing CI support. https://github.com/rust-lang/rfcs/issues/1795#issuecomment-308966293 https://github.com/rust-lang/rfcs/issues/1795#issuecomment-3... But of course there's always a way if you want it enough.
rcxdude 6y ago
Rust actually has a better standard library story than C++ here, since it actually has a segmentation between the 'core' and 'std' libraries, where 'core' contains stuff which doesn't require heap allocation. Makes it a bit easier to know what will be supported. (and tbh, the standard library is low on the list of reasons to use C++, especially in embedded) I think Rust has a lot of potential in the embedded space. I'm especially interested in if the async stuff will have power in making small and safe state machine writing easier: I think this could be extremely good at combining the power of stackfull tasks (which are wasteful on memory and less predictable) and state machines (which can be a pain to write, especially long sequential ones). If it lets you ship a product sooner with less bugs on a cheaper micro, I think it may be a strong proposition. Unfortunately given the industry is often unwilling to even consider C++ (and not for good reason: the reasons given for not using it or not even considering it are often based of off misconceptions or just outright falsehoods).