3 ms·
I would guess that even when you're targeting embedded environments you can still use runtime checks to help find problems during any part of the development li
by mumblemumble 3y ago
I would guess that even when you're targeting embedded environments you can still use runtime checks to help find problems during any part of the development lifecycle where the code isn't running on the target hardware?
That's roughly what I do for certain non-embedded work with high performance needs. There's a lot of contract checking and assertions that are too heavyweight for production, so they aren't included in deployment builds. But I certainly wouldn't want to not test at all just because I can't test in production.
- ChrisRR 3y agoYou can, but there's not many tools that you can use to just throw everything at the code like with desktop software. Even then it's often very dependant on the MCU and compilers you're using
- Gibbon1 3y agoI try to do runtime checks for my embedded code. Because as I like to say there isn't anyone to press F5 when something barfs. Bigger issue for me is what to do when a run time check fails. Sometimes there is nothing to be done but to log the error and reset. Other times, you log the error, clean up and keep going. Which why I dislike rust's run time checks which panic without letting the program try to recover.