4 ms·
> you just need to start from this point if you know your environment is really constrained and exceptions are too much of a cost - which is usually not the cas
by mrkline 10y ago
> you just need to start from this point if you know your environment is really constrained and exceptions are too much of a cost - which is usually not the case in modern embedded ARM systems.
ARM systems really run the gamut these days - while many are quite powerful (see: my phone), many also fall on the more traditional microcontroller side, with very little in terms of flash and RAM. In case it wasn't clear, this article focused on the latter.
- pjmlp 10y agoAn ARM Cortex-M4 is already powerful enough to run a Java runtime. http://www.microej.com/products/device-software-development/microej-os/ http://www.microej.com/products/device-software-development/...
- mrkline 10y agoGreat! But when you have hard timing requirements measured in microseconds, you generally need some fine-grained control over the instructions the CPU ends up running. All the knobs and levers C and C++ offer you are quite useful here.
- pjmlp 10y agoTrue, but those embedded Java runtimes also have such kind of knobs and levers, they just look different from what C and C++ devs are used to.
- leovonl 10y agoIndeed, in the later case, exceptions are really an unnecessary cost. In fact, another argument which could be made against the use of exceptions is that the abstraction per se is not a really good mechanism for abstracting error handling. Explicitly handling errors - including try!() à la Rust and/or monadic composition of functions - usually leads to a better error coverage, as safety is enforced by the type system itself.
- mrkline 10y agoI would _love_ to write our firmware in Rust, but that's a much bigger sell than moving from C to C++.