What are some off the open source, popular choices for a C++ compatible RTOS (besides mbed)? I've heard that FreeRTOS doesn't provide official support for C++ compilation and it's a nightmare getting into work.
Asked
Active
Viewed 1,642 times
0
-
1Possible duplicate: https://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems Might as well keep the flame war in one place. – Jon May 29 '18 at 14:26
-
Just don't pay too much attention to all the nay-sayers and try this is you want -> http://distortos.org/ – Freddie Chopin Aug 27 '18 at 14:58
1 Answers
2
The short answer to your question is:
"Real" RTOS and "real" C++ are mutually exclusive. So, you can't.
Long story:
C++'s syntax allows resource allocation and deallocation during runtime. In fact, most C++ developers (and judging by your question, you belong to these) won't even notice when that happens. In fact, chances are high you want C++ exactly because it can do that (and you don't have to do your own memory management and/or preallocate everything). It's a language feature C++ has, but C hasn't.
That's an idea incompatible to an RTOS, because it's non-deterministic in complexity (depends on instantaneous memory fragmentation, which depends on what your system has been doing before).
You can use C++ in a manner that doesn't do any run-time allocations. That requires a very high degree of discipline during development; and you can't use any of the standard library things (especially no std::string, std::vector…) and ABSOLUTELY no exceptions (you can probably even disable exception handling in the compiler).
People who develop RTOSes for automotive applications do allow C++ in some kernels, but they replace all the standard library's allocators by one that allows object creation during "bootup", but then a switch is flipped and at runtime, they stop doing anything but just signal a fault to the OS when they're used at all, which then stops operation.
As you can imagine, that's a nightmare to write code for. The software doesn't look like C++ code much anymore.
I'll be blunt: C++ is not the language you want to use here, already because FreeRTOS often runs on systems where you wouldn't even want the C++ runtime memory overhead in the first place... So do yourself a favor, learn C99 and a bit of C11, and do things in C.
Marcus Müller
- 88,280
- 5
- 131
- 237
-
Well, the application I have in mind should be able to get by without dynamic memory allocation, so I'd like to at least give C++ a go. It would really be used as a nice way to compartmentalise my code. – 19172281 May 29 '18 at 13:26
-
-
Also: if you think that's the case, please try to write a small example snippet of the application you have in mind, and run it in a debugger, breaking whenever your C++ code calls `malloc` or `free` internally (or their equivalents, or, for example, the linux call `brk`; you can trace these calls using `strace`, even). I think that you didn't consider this to happen that often in very innocuous C++, honestly. I'm not talking about using `new`! – Marcus Müller May 29 '18 at 13:50
-
5AFAIK C++ never forces you to use dynamic memory allocation. Indeed in a an embedded application, you can and should avoid dynamic memory allocation. If you really need to use stuff requiring it, you practically always have the option to specify your own allocator for containers like std::string if you *really* feel like using them, allowing you to reserve N bytes statically for that custom allocator to use. – jms May 29 '18 at 13:55
-
-
-
@jms, jup, maintainer of a large open-source high-performance C++ signal processing project here ;) btw, even if you used a custom allocator with `std::string`, the underlying problem that you're *dynamically building strings* remains – C++ *is* at its core idea an initialization=allocation language, and it's really hard to write C++ around that fact. – Marcus Müller May 29 '18 at 13:58
-
1@jms, also, I'm not even sure why we're even arguing: I specifically said that yes, it's possible, there's people doing it, you need to use your own allocators. So, you're basically agreeing with me while attacking me? I haz a confusion. – Marcus Müller May 29 '18 at 13:59
-
@MarcusMüller, I presume that if I avoid new, etc, then no calls to malloc will be made? – 19172281 May 29 '18 at 14:00
-
-
-
Practically all STL containers are built to facilitate dynamic memory use, I grant you that. You don't have to use them. I'm not "attacking" you, I'm just arguing that C++ shouldn't be thought of as fundamentally unusable for embedded applications. C++ brings with it many improvements over C. – jms May 29 '18 at 14:01
-
@B4039 because it's wrong? What do you think happens when you do `std::vector
vector; for(int i = 0;i<10000;++i) vector.push_back(i);`? What when you do `std::string a("hello "); std::string b("world"); std::cout << (a+b);`? (These are rather trivial examples, and can actually be worked around easily by restructuring your code.) – Marcus Müller May 29 '18 at 14:03 -
@jms and I grant you that you can really stubbornly repeat your point *which I'm making myself in my answer*: I'm nowhere claiming you're *forced*. I'm really confused about what you disagree with me or if you just disagree for the sake of disagreement? – Marcus Müller May 29 '18 at 14:03
-
1If you agree that C++ doesn't force you to use dynamic memory allocation, then what are you disagreeing about? C++ isn't perfect, I have a love and hate relationship with it, but I do think it is quite well suited for embedded programming. The fact that you should avoid certain features (notably dynamic memory allocation and exceptions) and be careful with templates doesn't take away from all the other features. – jms May 29 '18 at 14:20
-
1I think we never disagreed, you know, and I've been saying that for a couple of comments now :) So, all set here. – Marcus Müller May 29 '18 at 14:40