Boy, as someone who’s worked a moderate amount in embedded, this talk packs a _lot_ of highly advanced information (especially in the second half of the talk), from higher-level implementation structure to lower-level programming techniques and engineering tools. Gonna have to re-watch it a few times to grasp all of these ideas. Certification is a somewhat mysterious topic to me, but I feel like this could help wrap my head around what it entails in a little bit more detail.
When a catalog retailer knows more about the baseline requirments of aircraft programing than Boeing. (Some ashat tried to use Java for landing gear control... the they had to figure out an intermittant critical bug that was finally diagnosed as the garbage collector engaging at the same moment that the activation signal came in. The JVM has its advantages, but critical embedded machine control is not even close to one of them.)
15:58 Can somebody give me a hint about the possible signature of the GetTaskList function in the slide? Task is an abstract class so I cannot declare an array of it. But if I declare an array of pointers to Task then the implementation of TaskManager::RunAllTasks() won't be the same. It still works though, but I really want to know how to do it the way the slide shows. Thank you.
I was hoping you would go into more detail as to why you would choose a superloop over an RTOS-based design. I find the "scheduling" aspect of superloops, i.e. manually limiting task run times (essentially cooperative multitasking), to be frustrating when compared to preemptive priority based scheduling in an RTOS.
I commented too soon. At minute 43 you do give some reasoning. My understanding is that the superloop was chosen due to the overall simplicity of the things the microcontroller was responsible for. I'd be curious what the flight controller of the Prime Air drone was using for an OS.
I can appreciate that when they started development Rust was not up to the task at the time. However I'm amazed he gave the usual C/C++ developers take on Rust, that Rust requires "unsafe" to access hardware, their programs live on the hardware, therefore the safety guarantees of Rust are not worth it. This makes no sense to me. When Rust sits on embedded systems all hardware is accessed through a "Hardware Abstraction Layer" which of course contains "unsafe", but that is still only a small part of your code, Rust's type system and memory safety are still in the bulk of your code. This is a far better situation than having your entire code base unsafe. Those "unsafe" blocks in Rust clearly delineate code that needs extra care. Amazed he said that whilst at the same time saying he liked the correctness the type system of C++ offers. It's a contradiction.
So heart wrenching to see best minds in an industry working on such pointless projects like delivering people their treats in an ever-shortening timespan.
![The Imperatives Must Go! [Functional Programming in Modern C++] - Victor Ciura - CppCon 2022](http://i.ytimg.com/vi/M5HuOZ4sgJE/mqdefault.jpg)
![The Imperatives Must Go! [Functional Programming in Modern C++] - Victor Ciura - CppCon 2022](/img/tr.png)
Boy, as someone who’s worked a moderate amount in embedded, this talk packs a _lot_ of highly advanced information (especially in the second half of the talk), from higher-level implementation structure to lower-level programming techniques and engineering tools. Gonna have to re-watch it a few times to grasp all of these ideas. Certification is a somewhat mysterious topic to me, but I feel like this could help wrap my head around what it entails in a little bit more detail.
Very interesting talk. Thanks!
Very pleased to hear that you found this presentation informative.
I liked the idea of Heap withdrawal. This is something that should be teached in Embedded Systems courses.
When a catalog retailer knows more about the baseline requirments of aircraft programing than Boeing.
(Some ashat tried to use Java for landing gear control... the they had to figure out an intermittant critical bug that was finally diagnosed as the garbage collector engaging at the same moment that the activation signal came in. The JVM has its advantages, but critical embedded machine control is not even close to one of them.)
Great talk, a lot of practical points
15:58
Can somebody give me a hint about the possible signature of the GetTaskList function in the slide? Task is an abstract class so I cannot declare an array of it.
But if I declare an array of pointers to Task then the implementation of TaskManager::RunAllTasks() won't be the same.
It still works though, but I really want to know how to do it the way the slide shows. Thank you.
It could return a reference to a statically allocated array or std::array of Task references.
great summary, thank you
Very informative and well presented talk! What font is used for the slides? Really like it 🙂.
I was hoping you would go into more detail as to why you would choose a superloop over an RTOS-based design. I find the "scheduling" aspect of superloops, i.e. manually limiting task run times (essentially cooperative multitasking), to be frustrating when compared to preemptive priority based scheduling in an RTOS.
I commented too soon. At minute 43 you do give some reasoning. My understanding is that the superloop was chosen due to the overall simplicity of the things the microcontroller was responsible for. I'd be curious what the flight controller of the Prime Air drone was using for an OS.
I can appreciate that when they started development Rust was not up to the task at the time. However I'm amazed he gave the usual C/C++ developers take on Rust, that Rust requires "unsafe" to access hardware, their programs live on the hardware, therefore the safety guarantees of Rust are not worth it. This makes no sense to me. When Rust sits on embedded systems all hardware is accessed through a "Hardware Abstraction Layer" which of course contains "unsafe", but that is still only a small part of your code, Rust's type system and memory safety are still in the bulk of your code. This is a far better situation than having your entire code base unsafe. Those "unsafe" blocks in Rust clearly delineate code that needs extra care. Amazed he said that whilst at the same time saying he liked the correctness the type system of C++ offers. It's a contradiction.
So heart wrenching to see best minds in an industry working on such pointless projects like delivering people their treats in an ever-shortening timespan.
Please God Dave us from having 100's of drones buzzing around our neighbourhoods delivering junk to people.