I didn't really mean by way of compiler flags or language pragmas. I can try -fno-rtti or -fno-exceptions with g++ today, it doesn't do me much good to spend a week getting half a dozen dependency libraries built with the obscure proprietary embedded board compiler only to find the very last thing I need won't work. The type of control I do is pretty sophisticated - optimization-based, nonlinear, large-scale MIMO systems, incorporating a prediction model of the system and satisfying state and input constraints - takes a bunch of libraries to do properly, not the kind of thing that's easy to throw together from scratch in C. It would be nice to get guarantees by construction that my controller and all the code it uses would be deployable to an embedded environment from the very beginning.
Luckily microcontrollers are getting much more powerful these days and the line is starting to blur between embedded RTOS and lightly tweaked Linux. You can fit lots more code and do more interesting things with the same power/thermal footprint, getting lots more flops and IO in soft-but-pretty-damn-good realtime at the same or better speeds. Though what this thread was originally about was tools for doing offline control design, where Matlab/Simulink absolutely dominate. You don't want to do simulation, analysis, testing, and tuning in the exact same low-level restricted language that the realtime controller gets deployed to, the requirements are completely different. On Monday, September 15, 2014 3:13:32 AM UTC-7, Andrew Wagner wrote: > > Another quick note, Tony: > > There are plenty of embedded environments where if you're allowed to use >>> C++ at all, it's only a limited subset, anything involving exceptions or >>> RTTI is often not supported. It's tough to audit 3rd-party libraries for >>> these kinds of restrictions, and achieve any kind of code reuse or >>> non-trivial complexity. >>> >> > At least the "auditing for restrictions" part of that problem ~seems like > it should be easy in a well designed language. I want to just declare an > environment and have the compiler throw errors if anything inside it > violates the restrictions I care about for whatever my personal definition > of what a "realtime" or "typesafe" or "pure functional" language subset is. > > > Something along the lines of: "#[deny(managed_heap_memory)]": > > https://github.com/rust-lang/rust/issues/9984 > > Of course as you point out there is the other part of the problem > "achieving code reuse and complexity", which is much harder. >
