28 ms·
I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on. Where can someone (i.e., in my case a softw
by giu 7y ago
I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on.
Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems?
I'm asking for one because I'm curious by nature and additionally because I simply take the garbage collector for granted nowadays.
Thanks in advance for any pointers (no pun intended)!
- saagarjha 7y agoSearching for things like "MISRA C" and "real-time computing" will help you get started.
- jakeinspace 7y agoMy older co-workers have some great alternative definitions of that initialism.
- giu 7y agoThanks a lot for the keywords; these are very good starting points to look for further stuff on the topic! Didn't know that there was a term (i.e., real-time computing) for this kind of systems / constraints.
- monocasa 7y agoI'd also look a the Joint Strike Fighter C++ Coding Standard. Stroustrup himself hosts it as an example of how C++ is a multi paradigm language that you can use a subset of to meet your engineering needs. http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf
- 0xffff2 7y agoThe embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use a lot of modern C++ features, but the compiler for our flight hardware platform is GCC 4.1 (upgrading to GCC 4.3 soon if we're lucky).
- rowanG077 7y agoI find it interesting that such critical code is written in C. Why not use something with a lot more (easily)statically provable properties. Like Rust or Agda?
- MiroF 7y agoBecause safety critical fields are also slow-moving.
- retrac 7y agoI think the answer was right there in their comment. "The compiler for our flight hardware platform is GCC 4.1 (upgrading to GCC 4.3 soon if we're lucky)". Often, the only high-level language available for an embedded platform is a standard C compiler. If you're lucky.
- NobodyNada 7y agoUsing a newer language carries a lot of risks and challenges for embedded programs: - There’s a high risk of bugs in the compiler/standard library in languages with lots of features - Usually, the manufacturer of an embedded platform provides a C compiler. Porting a new compiler can be a LOT of work, and the resulting port can often be very buggy - Even if you can get a compiler to work, many newer languages rely on a complicated runtime/standard library, which is a deal-breaker when your complete program has to fit in a few kilobytes of ROM
- amw-zero 7y agoYou’ll find that for very serious, industrial applications, a conservative mindset prevails. C may not be trendy at the moment, but it powers the computing world. Its shortcomings are also extremely well known and also statically analyzable. Also, think about when flight software started being written. Was Rust an option? And once it came out, do you expect that programmers who are responsible for millions of people’s lives to drop their decades of tested code and development practices to make what is a bet on what is still a new language? What I find interesting is this mindset. My conservativeness on a project is directly proportional to its importance / criticality, and I can’t think of anything more important or critical than software that runs on a commercial airplane. C is a small, very well understood language. Of course it gives you nothing in terms of automatic memory safety, but that is one tradeoff in the list of hundreds of other dimensions. When building “important” things it’s important to think about tradeoffs, identify your biases, and make a choice that’s best for the project and the people that the choice will affect. If you told me that the moment anyone dies as a result of my software I would have to be killed, I would make sure to use the most tried-and-true tools available to me.
- enriquto 7y ago> Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems? The JPL coding guidelines for C [1] are an amusing, first-hand read about this stuff. Not sure if you would qualify them as "modern approaches". [1] https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
- ibrault 7y agoI can testify first-hand that the "functions in a single page" and "avoid the pre-processor" rules are not followed very closely haha
- Cyph0n 7y ago> A minimum of two runtime assertions per function. I am guessing the idea is to catch runtime errors in the test phase, and assertions are disabled for the production build.
- amelius 7y agoJust read docs that were written in the 70s, before the advent of garbage collection.
- p_l 7y agoGarbage Collection is from 1959, though - and Unix & C's original model pretty much matches "bump allocate then die" with sbrk/brk and lack of support for moving. Fully static allocation is the norm though for most "small" embedded work.
- diego 7y agoIf you want a "toy" example of this type of code, look at flight control software for drones such as Betaflight. You can modify this code and test it in real life. I did this, as I contributed the GPS Rescue feature. I have a blooper reel of failures during testing. https://github.com/betaflight/betaflight/ https://github.com/betaflight/betaflight/