Лидеры

Я впервые столкнулся с вопросом достоверности измерений именно при разработке прибора, измерявшего отклонение сопротивления от номинального значения. Так оказалось гораздо проще проверить флаг ошибки перед индикацией результата, чем городить кучу проверок, что было особенно важно для прибора с батарейным питанием.

"Все уже украдено до нас" (С) Отключение выводом ENn, остальное можете не заморачиваться. Разве что через АЦП считывать нужные параметры и принимать решение.

Его пишет тот же человек, который написал LTSpice, поэтому можно надеяться, что будет учтён опыт предыдущей разработки, и новый симулятор будет лучше (ну или хотя бы не хуже). Обещают большую скорость симуляции и расширение функционала. Как минимум, интересна возможность делать свои поведенческие блоки на C++ и Verilog. А не имеет он широкого распространения, потому что первый публичный релиз состоялся всего несколько месяцев назад.

Практическая потребность. Реализую рантайм ПЛК. В нём есть флаги, показывающие результат выполнения математических операций. Я ведь не знаю, какую формулу напишет пользователь и какие данные он будет по ней обсчитывать, поэтому для рантайма деление на ноль и корень из отрицательного числа это нормальные ситуации. А есть ведь ещё ситуации, когда в результате вычислений результат потеряет значимую часть или превысит разрядную сетку. Такие ситуации невозможно выявить проверками до начала вычислений, они выявятся только в процессе вычислений, поэтому для рантайма наличие ошибок вычислений в пользовательской программе не должно быть чем-то неожиданным.

Открыть файл .xpr в любом текстовом редакторе.

По моему доводить до цугундера Hard fault - плохая идея. Ввод от двуногих прямоходящих совершенно необходимо проверять в явном виде на корректность, диапазоны и все что вообще можно вообразить (то что нельзя вообразить на всякий случай лучше тоже проверить).