Эх надо к скрепам возвращаться, как в детстве на радиокружке :) Паяльник, олово, канифоль, МП-39 :) А дальше или заработает, или нет :) И никаких тебе мучений с новыми технологиями :)

Так дискуссия и идет о том, что как вы говорите "делается на года", т.е. про железо которое летает на борту, а именно про firmware. Приложения я даже не рассматриваю, так что ваш пример имеет право на жизнь )

Для CAD систем вообще давно надо было сделать стандартизованную компонентную модель объектов от производителя и подхватывать компоненты в проект из этой базы.

да и тут без паяльников не обходится) BGA корпуса перепаивать вручную когда завод накосячит, но это уникальные монтажники делают))

кстати, из приколов про языки
"Ross N. Williams
Элементарное руководство
по CRCалгоритмам
обнаружения ошибок", цитата:


Этот код можно записать короче, правда он станет менее понятен:
r=0; while (len) r = ((r > 24) & 0xFF];
Несмотря на лаконичность строки, любители оптимизаций не оставят ее в покое...


вот из-за этого Си нельзя допускать до космических аппаратов))

форум за тег принял, во так
r=0; while (len) r = ((r > 24) & 0xFF);

А Вам не приходилось firmware обновлять??? На винчестерах DTLA, например, которые сыпались валом. BIOS из за ошибок, Ваш телефон?

Производители компонент тоже ошибаются, иногда серьезно. И отзывают изделия на перепрошивку. А, дальше, возможны и рекомендации к обновлению смежных компонент.

Сейчас все настолько динамично...

не вставляется

Baalu, есть и даже наверное сейчас ещё работает дятел(DTLA). Там от страны/завода производителя зависело, брали зная проблему.

Кто захочет найти - найдет :) Я нашел :)

Настоящий программист обязательно потратит неделю работы, для оптимизации на 5 микросекунд времени выполнения цикла, который исполняется 1 раз в программе :)

На правах пятницы!

Доподлинно известно, что вся электронная техника работает на белом дыме.
Как только дым выходит — техника сразу перестает работать...

Так что все наши программные примочки служат для высасывания денег с заказчиков. Других функций они не несут :)

Всем хороших выходных и весенней погоды!!!

Тогда спрошу подробнее.

У меня на приличной САУ для наземного ГТД закладываются проверки показаний канала измерений 4...20 мА:
а) меньше 3 и больше 21 => обрыв и КЗ линии соответственно;
б) меньше 3, 5 и больше 20, 5 => измеряемую среду занесло куда-то не туда, но в общем датчик пока? исправен;
в) между 4 и 20 => с точки зрения датчика показывает правду;
г) между теоретическими минимумом и максимумом расчетных параметров для всех режимов, включая стоп;
д) как г), только для данного режима;
е) отклонение от теоретического значения для мгновенной комбинации параметров (отклонение от рабочей точки);
ж) позволяет ли величина по е) считать мгновенное значение достоверным? как условие перехода на работу при отказе данного канала.
Похожая проверка на скорость изменения параметра.
И другие процедуры, связанные именно с обработкой измерений, по большей части до попадания в алгоритм.
Для меня всё это расписывается в ТЗ на систему, для каждого канала определяются значения уставок ну и потом тестирование, в идеале физически..

И вот это уже заложено в язык, только числа подставить? Или мы говорим о разных вещах?

sx5
Старожил форума

BGA корпуса перепаивать вручную когда завод накосячит, но это уникальные монтажники делают))



И что такого уникального - припаять микруху BGA ? Всего то нужна кетайская паяльная станция с регулируемой температурой горячего воздуха. Это сделает любая кустарная мастерская по ремонту сотовых. На крайняк попробовать строительным феном. Я так сгоревший южный мост с материнки выпаивал.

«r=0; while (len ) r = ((r > 24) & 0xFF);»
Зачем в цикле колошматить одну и туже переменную r?
Зачем производить побитовое умножение результата логического выражения (r>24), типа bool на одну-байтную константу 0xFF?

Да, филологическое отечественное образование совсем вдвинули в "перёд". С потомственными филологами лучше чтобы "ЛА" и "БПЛА" летали исключительно на руках, в виде пенопластовых макетов.

Для пп. а) ... в) вам подойдут конструкции типа:

type XR is range 1..10;
subtype SXR is XR range 2..9;

т.е. будут вложенные значения диапазонов измерений, причем если вы в последней строке выйдете за предыдущий диапазон, компилятор вас остановит.

Остальные пункты не совсем понятны, но может быть и можно сделать за счет типизации (я не знаю этот язык достаточно хорошо), а возможно придется писать свою логику.

Для первых пунктов проверка диапазона заложена в язык, и вы только подставляете граничные значения. Проверка производится средствами самого языка, если вы объявите кучу переменных с типом XR или SXR, то соответствующая проверка будет производится для каждой переменной в момент получения ей значения автоматически.

Baalu
На правах пятницы!

Доподлинно известно, что вся электронная техника работает на белом дыме.
Как только дым выходит — техника сразу перестает работать...

Так что все наши программные примочки служат для высасывания денег с заказчиков. Других функций они не несут :)

Всем хороших выходных и весенней погоды!!!

Спасибо, долго смеялся)
Если про компоненты, то, конечно, ПЛИС сейчас стали шире внедряться. Дают возможность реализовать проекты под конкретную задачу, плюс серийные объемы изделий редки - специфика. Да и "съедает" все надежность плюс хватает возможностей и старых, зарекомендовавших себя компонентов. А по-прежнему все решают кадры. Хотя, санкции немного заставили народ оглядеться в поисках нового. Широко опробовали китайскую элементную базу, но у них своя специфика относительно американцев, отсутствие технической документации ( вся под заказ), плюс в разы дороже. Конечно они отстали от американских решений, но с нами не сравниваю. Военная авиакосмическая техника, вообще, драйвером новинок не является.

Если об "авангарде", то последние скоростные новинки внедряются сейчас в суперкомпьютерах. Это уже оптика со скоростями за 100 Гб/с на линию. Траффик сейчас логарифмически растет - LTE влияет, тоже оптика приходит. Ну, и системы оперативно-розыскных мероприятий у операторов мобильной связи. ЦОДы гоняют информацию пару раз в сутки - экономят расходы на электроэнергию. Так, что узрим скоро закат медных проводников.

«
type XR is range 1..10;
subtype SXR is XR range 2..9;

т.е. будут вложенные значения диапазонов измерений, причем если вы в последней строке выйдете за предыдущий диапазон, компилятор вас остановит.
»

Поразительная дискуссия для "Авиафорума".
Никакой "компилятор " не может предотвратить появление недопустимого значения с аналогового входа АЦП, частотомера или поля установки задания введенного человеком.
Исполняемая среда - OS (время выполнения программы, а не ее компиляции) может отловить появление такого события, и запустить процесс называемый "обработка исключения", как правило, его результатом является сброс прикладного ПО или полное отключение вычислителя.
Есть подозрения, что подобные события не один раз приводили к разбросанным фрагментам ВС по земле.
Волшебный язык и компилятор не может даровать высококачественного ПО, а все проверки значений и условий должны писаться явно прикладным программистом.
Язык программирования должен быть, - функциональным, удобным, ясным и легко читаемым.

Спасибо, буду знать.

Описанные проверки идут именно для того, чтобы отсеять неправильные измерения и/или вовремя перейти на другой алгоритм.
Удобная конструкция языка снижает вероятность ошибок программиста. Дальше только прогон с эмуляцией работы.
А ошибки ТЗ должны быть выловлены выше.
Это тема программистов, они пишут программы управления техникой. Почему бы ей не быть на авиафоруме?

Однажды пришлось оптимизацией наскоблить.... 600нс. 2 команды. Иначе ракета падала...
Слава богу, на стенде.
Месяц возились.

to AAlfim
«Описанные проверки идут именно для того, чтобы отсеять неправильные измерения и/или вовремя перейти на другой алгоритм. »

1) Абсолютно все компиляторы проверяют текст программиста на соответствие синтаксису языка (во время компиляции), и все они не отвечают за значения полученные с измерительных приборов во время работы скомпилированного ПО (время выполнения).
2) Собственно, попытка наложить аппаратные данные на такие механизмы синтаксического контроля компилятором значений величины и приводят к "кровавым багам", когда во время эксплуатационного отказа, датчик выдал значения в алгоритм, с которыми его некто, некогда не ожидал и не тестировал.

«чтобы отсеять неправильные измерения и/или вовремя перейти на другой алгоритм»
Именно для этого прикладной программист, а не исполняемая среда языка или операционная система, должен явно выполнить проверку значений, и явно написать алгоритм отработки совершенно всех возможных случаев бинарного значения переменной процесса (данные с сенсора, органа вода пилота).
А то, опять, будет виноват сын пилота, который повернул и более минуты удерживал в этом положении штурвал при включенном автопилоте.

Необходимо помнить, что с АЦП, частотомера считываются сырые данные, а не величины в инженерных значениях, так что есть ступень алгоритма их трансформации. Для современных датчиков этот алгоритм должен не только проверять допустимость сырых значений, но и диагностировать достоверность данных и исправность сенсора.

«Удобная конструкция языка снижает вероятность ошибок программиста»
Слишком кондовый (не гибкий, не функциональный и строгий) язык приводит к чрезмерному использованию специальных обходящих операций, собственно, где и сидит большинство ошибок.

«А ошибки ТЗ должны быть выловлены выше. »
Чем больше ошибок в ТЗ наделает заказчик, тем больше получит подрядчик на изменениях и переработке ПО.

Дык, протоколы как правило стандартизовать на уровне передачи данных. Mil-1553, Mil-1773 и т.д. А вот потоков информационного и логического взаимодействия ни разу не стандартизованы. Локатор новый? Новый. Нашлепка новая? Новая! СУО тоже новая. Как их подружить? Ну, протокол передачи данных да, стандарт, а какие будут данные, в каких форматах, диапазонах, в какой последовательности и каким блокам будут передаваться -вот это самый неприятный вопрос. Именно этим голвнюк типа Боинга или как меня справедливо поправили, Локхида, и занимается. Их задача подружить всю кооперацию смежников между собой. Процесс длительный и болезненный, что мы и видим по результатам натурных испытаний. С трудом верится, что они сами сейчас еще пишут какое-то ПО на борт. Все блоки у них покупные. Смысл им держать свой штат программистов и писать ПО для какой-нибудь станции фирмы Рейтеон?

Сорри, телефон коверкает слова.
Дык, протоколы как правило стандартизованы на уровне передачи данных. Mil-1553, Mil-1773 и т.д. А вот протоколы информационного и логического взаимодействия ни разу не стандартизованы. Локатор новый? Новый. Нашлемка новая? Новая! СУО тоже новая. Как их подружить? Ну, протокол передачи данных да, стандарт, а какие будут данные, в каких форматах, диапазонах, в какой последовательности и каким блокам будут передаваться -вот это самый неприятный вопрос. Именно этим головнюк типа Боинга или как меня справедливо поправили, Локхида, и занимается. Их задача подружить всю кооперацию смежников между собой. Процесс длительный и болезненный, что мы и видим по результатам натурных испытаний. С трудом верится, что они сами сейчас еще пишут какое-то ПО на борт. Все блоки у них покупные. Смысл им держать свой штат программистов и писать ПО для какой-нибудь станции фирмы Рейтеон?

Интересная статья инженера, который переписывал firmware дрона с Си на Ада:

http://blog.adacore.com/how-to ...

Он поступил интересным способом: код, который чувствителен к показаниям датчиков/сенсоров, написал на Аде, а остальная часть была написана на Си.

Пример из статьи: в оригинальном Си коде есть строка, которая вычисляет отклонение по данным каждой из осей акселерометра:

accMAG = (acc.x*acc.x) + (acc.y*acc.y) + (acc.z*acc.z);

Автор замечает, что поскольку тип переменных - float, результат операции подвержен переполнению, с понятными последствиями. Он переписывает этот код на Аде и задает ограничения данным с акселерометра, с учетом того что максимальный диапазон данных с сенсора находится в пределах -16g ... +16g:

subtype T_Acc is Float range -16.0 .. 16.0;

type Accelerometer_Data is record
X : T_Acc;
Y : T_Acc;
Z : T_Acc;
end record;

Теперь, если по какой-то причине данные с сенсора выйдут из этого диапазона, возникнет исключение, которое можно обработать корректным способом.

статью не читал, но исключения и их обработка есть в любом современном языке
просто ему значит нравится языка Ада :)

с точки зрения читаемости и легкости восприятия кода на АДА - это плюс.
с точки зрения компактности и скорости программы - может быть очень плохо
диапазон допустимых значений -16ж ... +16ж, значит, в в коде в неявном виде компилятор вставит проверку данных, что даст увеличение времени выполнения этого куска программы, если требуется обработка в зависимости от значения датчика ускорений.

зы исключения и их обработка действительно есть в любом языке, даже в ассемблере, вот только обработка исключений делается в прерывании, а вход и выход из прерывания занимает иногда критическое время

1) Применение бинарного формата float, - 32 бита с плавающей точкой для величины чье значение меняется от -16 до +16 является не всегда рациональным.
Все форматы с плавающей точкой предназначены для очень больших чисел с относительной точностью (для float весьма малой). Точность теряется при увеличении двоичной степени. Также этот формат имеет нечисловые значения: минус бесконечность, плюс бесконечность и не число. Что является дополнительным источником критических ошибок на процессоре. Если процессор не поддерживает аппаратно математику с float, то она будет очень медленно эмулироваться программно.

Для подобной переменной целесообразно использовать обычный int32 (если не хватает диапазона при вычислениях степеней и корней int64) со знаком, значение необходимо обрабатывать в той десятичной величине точности, которая требуется ТЗ, например не в g, а mlg (мили, или микро). При отображении человеку, необходимо просто добавить десятичную точку в нужное положение.

2) Во всех языках "исключения" являются НЕ механизмом построения алгоритмов обрабатывающих потенциально возможные случаи, а механизмом отработки совершенно невероятных и практически неожидаемых ситуаций. Исключения должны наиболее корректным способом завершить работу программы или попытаться ее восстановить, с того места, где это исключение должно было быть предотвращено штатным алгоритмом.
Как аксиома, хорошие ПО должно быть готово к ним, но некогда не должно получать их до самого списания устройства.

Аппаратные прерыванию случаются только по аппаратным исключениям (например недопустимое число FPU, деление на 0), программно генерируемые исключения идут без прерываний, но во всех случаях исключений (что не включает саму обработку прерываний CPU на события устройств) их обработка вызывает сложный и длительный код. Совершенно недопустимый для Real time module прикладной программы.

Все решающие ПО должно проверять входные данные (даже цифровая коммуникация) на целостность и приемлемость, и иметь явный вариант действий на все возможные сбои.
Сырые данные с АЦП как правило идут через калибровочную таблицу, или линейные коэффициенты трансформации gValue=Const+adcValue*K перед тем как они станут единицами g. Вот здесь и должен быть контроль диапазона, с диагностикой отказа

Phil.K

Все решающие ПО должно проверять входные данные (даже цифровая коммуникация) на целостность и приемлемость, и иметь явный вариант действий на все возможные сбои.
Сырые данные с АЦП как правило идут через калибровочную таблицу, или линейные коэффициенты трансформации gValue=Const+adcValue*K перед тем как они станут единицами g. Вот здесь и должен быть контроль диапазона, с диагностикой отказа



в общем именно так






Аппаратные прерыванию случаются только по аппаратным исключениям


не совсем так. Работа с устройством тоже может быть по опросу или по прерыванию

to кое_кто_где_то_там
«
Аппаратные прерыванию случаются только по аппаратным исключениям
не совсем так. Работа с устройством тоже может быть по опросу или по прерыванию
»

Прерывания и исключения (программные и CPU) совершенно разные механизмы.

Прерывание, - это прерывание текущего потока программы на обработку срочного события ОС или системного блока ПО, которое работает без ОС. Для прикладной (прерванной) программы оно незаметно.

Исключение, - это событие после которого дальнейшее, выполнение блока ПО, в котором оно произошло становится совершенно невозможным. Вся структура программы откатывается, до уровня обработчика исключения, где будет произведено наиболее корректное отключение устройства или попытка перезапуска, восстановления функционирования.
Все случившиеся исключения должны помешаться во внутренний журнал, их обработчиком. Это означает, что разработчику срочно необходимо провести изучение события, и выпустить обновленную версию ПО, в которой подобная ситуация (сбой) уже будет невозможной.

исключительные ситуации (исключения) типа потеря точности, деление на нуль, етс тоже обрабатываются с помощью прерываний. Так что механизм запуска обработки общий.

Обработка прерывания (исключения) в реал тайм программе очень заметна. И часто бывает критичной из-за внеплановых задержек

Насчет протоколирования внутренних ошибок - согласен. Особенно при начальной отладке программы.

To Phil.K

1) Применение бинарного формата float, - 32 бита с плавающей точкой для величины чье значение меняется от -16 до +16 является не всегда рациональным.
Все форматы с плавающей точкой предназначены для очень больших чисел с относительной точностью (для float весьма малой). Точность теряется при увеличении двоичной степени. Также этот формат имеет нечисловые значения: минус бесконечность, плюс бесконечность и не число. Что является дополнительным источником критических ошибок на процессоре. Если процессор не поддерживает аппаратно математику с float, то она будет очень медленно эмулироваться программно.

++ Вы не поняли. речь идёт о диапазоне значений от -16G до +16G (единицы ускорения) с шагом, думаю, не более 0, 001 диапазона. Это не 32 значения из целых чисел, а не меньше 1000. Так что float тут совершенно к месту. А перевод в int с диапазоном -16000 ... +16000 при бесспорных преимуществах в математике чреват массой ошибок.

to кое_кто_где_то_там

«исключительные ситуации (исключения) типа потеря точности, деление на нуль, етс тоже обрабатываются с помощью прерываний. Так что механизм запуска обработки общий»
Здесь более главное не как запускается, а как реализуется (обрабатывается).
Прерывание не меняет логики выполнения прерванного потока команд, только очень быстрое переключение на обработчик и назад.
А, исключение, приводит к завершению его выполнения. Начинается сброс стека CPU и возможное освобождение занятых ресурсов до уровня обработчика исключения. Это жутко ресурсо-затратный процесс (время CPU). К стати, весьма подверженный дополнительным и уже окончательно фатальным сбоям.

«Обработка прерывания (исключения) в реал тайм программе очень заметна. И часто бывает критичной из-за внеплановых задержек.»
Поэтому желательно все обработчики прерываний реализовывать на Assembler, хороший предварительный расчет вычислительных затрат и структура ПО решают все проблемы. Все обработчики должны завершаться как можно скорее, и в основном только ставить обработку их событий и данных в очередь прикладного планировщика (приоритет и порядок основных вычислений).

Чем выше язык от Assembler, тем меньше эффективность его кода. Компиляторы редко используемых языков, являются большими источниками "неожиданного и невероятного".

to AAlfim

Все совершенно правильно понял и даже проверил диапазоны.

1) Как правило ADC выдают значения в формате целого без знакового числа. Если измеряемый сигнал имеет две полярности (от-5 до +5 вольт), то сигнальный 0 будет выходить как среднее значение числового диапазона. Так, что float скорее всего уже будет результатом конверсии из целочисленного сэмпла.

«с шагом, думаю, не более 0, 001»
- значит точность расчета до одного милиG.

«Это не 32 значения из целых чисел, »
int32 (язык Си и многие другие) - это целочисленный знаковый тип переменной, который занимает в памяти 32 бита, или по другому 4 байта.
Он имеет максимальный диапазон значений от -2, 147, 483, 648 до 2, 147, 483, 647.

Максимальное число. которое вы должны пропустить в формулу вычисления результирующего вектора будет 16000 mlG.
accMAG = (acc.x*acc.x) + (acc.y*acc.y) + (acc.z*acc.z);
Максимальный результат вычисления суммы трех квадратов = 768, 000, 000, что не переполняет знаковый int32.

Если данные уже поступают по цифровой шине от блока акселерометров в формате float, то лучше в нем и продолжать их обработку. В ином случае желательно тщательно задуматься, нужен ли более сложный формат, аппаратно не поддерживаемый многими средними и малыми CPU.

o Phil.K

«с шагом, думаю, не более 0, 001
- значит точность расчета до одного милиG. »

++ Честно говоря, это точность (шаг) АЦП. Погрешность измерения вибрации около 10%, что бы там не писали в умных бумажках. Ну а точность расчёта будет ого-го, в соответствии с форматом :-)

«Если данные уже поступают по цифровой шине от блока акселерометров в формате float, то лучше в нем и продолжать их обработку. В ином случае желательно тщательно задуматься, нужен ли более сложный формат, аппаратно не поддерживаемый многими средними и малыми CPU.»

Так и есть. Спасибо за подсказку, действительно, перевод сразу в Милли- и использование типа INT должен и повысить скорость и снизить вероятность ошибки.
Я очень начинающий программист контроллеров. Прошу прощения, если вопросы "детские".

Я очень начинающий программист контроллеров. Прошу прощения, если вопросы "детские".



не надо просить прощения, надо спрашивать.
При программировании микроконтроллеров есть очень много не отраженных в документации нюансов.



"Учиться, учиться и учиться" - как то так завещал нам дедушка Ленин. Актуально и в настоящее время.

Да, и такое бывало, что бы в протокол вписаться.

Кстати, очень частые операции целочисленного умножения на 10 и 100 хорошо ускоряются для многих процессоров.
Вместо:
i = q*10; используют i = (q

умножения и деления целочисленных хорошо ускоряются заменой команд умножения и деления на сдвиги

Хм, спецсимволы не эскейпятся :(
Попробую так
i = q*10; используют i = (q сдвиг_влево 3) + (q сдвиг_влево 1);
i = q*100; используют i = (q сдвиг_влево 6) + (q сдвиг_влево 5) + (q сдвиг_влево 2);

Конечно, компилятор вставит свою проверку. Это будет гораздо компактнее, чем писать свою проверочную функцию для разных типов данных (есть шанс еще ошибиться и в ней).

Обработка исключения - процесс долгий, но с другой стороны это непредвиденная ситуация, и с реалтаймом может есть смысл повременить.

Плюсы реализации проверки средствами языка:

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

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

Уважаемый,
Ну тут же уже описали процесс, когда параметры с точки зрения диапазона корректны, а с точки зрения алгоритма - нет. Все равно на правильность поведения измеряемой величины нужно контроль делать.

Приведу реальный случай из своей практики. Показания датчика должны были находится в пределах от 0 до +32767 и достаточно плавно меняться (весь диапазон за 3 секунды), а у нас они начали осциллировать в интервале +10000 : +22000 с частотой 50 герц. С точки зрения диапазона - все ок. С точки зрения работоспособности системы - полный абзац. Оказалось, через плохо промытый флюс шла наводка от сетевого напряжения 220В. Реальные сигнал был на уровне 16000, а наводка давала +- 6000 ошибки. Правильный анализатор поведения сразу даст аварийное состояние. А просто контроль границ не даст ничего.

При чем тут алгоритм? Обсуждалась проверка диапазона средствами языка.

Что у вас там в алгоритме - об этом компилятор не знает и знать не должен. Это целиком ваша зона ответственности.

И ошибки в изготовлении плат нужно ловить не тогда, когда она идет в регулировку, а сразу после изготовления.

Именно протокол и рушился. Прерывание изредка не успевало обрабатываться. Олухи из Texas Instruments не озаботились приоритетами. Обмену бы - высший. А так - "кто первый встал, того и тапки".
Спасла мощная система команд с развитой адресацией. Сигнальник, все-таки...

Кроме статической проверки значений делается ещё проверка по скорости изменения сигнала. А в особо тяжёлом (шумном) случае и по ускорению.
Фильтр нижних частот служит той-же цели, только без обратной связи.

«При чем тут алгоритм? Обсуждалась проверка диапазона средствами языка.»

Средства языка делятся на два этапа: время компиляции программы и время выполнения (run time library).

Время компиляции - отследит исключительно величины констант, которые присваиваются переменным в коде программы, и не более этого.

Время выполнения- библиотека языка (run time library) сгенерирует дополнительный код, который перед записью вычисленного значения в ячейку памяти проверит ее на вхождение в диапазон, в случае превышения порогов сгенерирует исключение.
При этом:
1) Данный механизм совсем не отвечает за значения, которые приходят в вашу программу из вне, ADC и цифровая коммуникация.
2) Ухудшатся размер и скорость выполнения вашей программы, так как автоматический код проверки диапазона будет воткнут компилятором во все операции присваивания нового значения данному типу переменной.
3) Автоматическая проверка диапазона и генерация исключения не снимает с вас ответственности, как разработчика ПО, за алгоритм разрешения этого исключения. Все необработанные программистом исключения приводят только к полной остановке CPU, ваше устройство даже не выдаст сигнала отказа. Алгоритмы обработки исключений и возврата в рабочие состояние несопоставимо сложнее явных алгоритмов проверок значений в операциях.
4) Какой диапазон Вы хотели бы назначить типу для переменной G, +16...-16?
Если его, (???) так вы сразу и погорите синим программным огнем на этой формуле: accMAG = (acc.x*acc.x) + (acc.y*acc.y) + (acc.z*acc.z); при G=3 по всем координатам в результате уже будет недопустимое значение 27.

«При чем тут алгоритм?»
Ровно при том, причем пилот в пилотской кабине. Кода происходит сложная ситуация он должен браться за управление ВС, а не возлагать всю ответственность на "автоматику", разработчики которой, в их очередь, все "особое" переложили на "средства компилятора".

AAlfim
«Кроме статической проверки значений делается ещё проверка по скорости изменения сигнала. А в особо тяжёлом (шумном) случае и по ускорению.»

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

to Phil.K

«4) Какой диапазон Вы хотели бы назначить типу для переменной G, +16...-16?
Если его, (???) так вы сразу и погорите синим программным огнем на этой формуле: accMAG = (acc.x*acc.x) + (acc.y*acc.y) + (acc.z*acc.z); при G=3 по всем координатам в результате уже будет недопустимое значение 27. »

Но это неправильная математика! Уже на уровне ... физического смысла. Ускорение не может быть равно квадрату ускорения и для осмысленного результата должен быть корень из суммы квадратов ускорений по осям. И таки да, равнодействующая ускорения при осевых составляющих ±16 должна иметь допустимое значение ±27, 7 с копейками. Неужто это надо кому то объяснять???

To priladibudivnik, Phil.K, AAlfim
Вы, уважаемые, похоже, практики как и я, на своей шкуре испытавшие все прелести общения с железом и не раз разбивши лоб о подводные камни. А уважаемый Termi Nemo, видимо теоретик, поэтому конструктивной дискуссии здесь не получится :)

Я, кстати, прочитал статью, на которую он ссылался и даже вчера не поленился взять и проревьювить код того проекта. Для студента пятого курса вполне аккуратно написано, хотя с несколько вопросов у меня к нему накопился :))) Хотя бы отсутствие обработки исключений, где он работает с range types и неоправданное использование массивов в паре мест.

Это вы сейчас себя так похвалили, да еще и потенциальным союзникам польстили?

То что у вас о камни разбитый лоб, чувствуется, ухитриться получить наводку с сети 50 Гц на цепи сенсора, вы там наверное кофеварки разрабатываете? ))

Ну не только кофеварки, еще и утюги с одной кнопкой вкл/выкл :)))

Здесь я не делю людей на союзников и противников - глупо и бессмысленно. Оппоненты и сторонники подхода в конкретно обсуждаемой теме - так будет правильнее.

А то, что лоб разбивал - что поделать, уж такой я неуклюжий, видимо :)

to AAlfim
«И таки да, равнодействующая ускорения при осевых составляющих ±16 должна иметь допустимое значение ±27, 7 с копейками.»

Совершенно верно, поэтому использование тапа "диапазон" для каких-либо предохранений, в подобной ситуации абсолютно бессмысленно.

Как назвать осмысленный отказ от явной проверки и прикладной обработки некорректного входного значения, с возложением всего на исключения, которых в финальной версии программы просто быть недолжно (по целевому определению данного механизма), я не знаю.

Как правильный пример применения тапа диапазона я могу привести индексы массивов, где выход за допустимые границы может привести к порче памяти, возможно не принадлежащей к ушедшему в сбой программному модулю.
В этом случае остановка этого модуля по исключению будут единственным верным решением, спасающим от более крупного и масштабного сбоя.

Массивы с контролем индексов прекрасно реализуются средствами языка Си++, как шаблоны и классы. Без всякой экзотики.

В том подмножестве Ада, которой пользовался автор кода (SPARK) исключения вообще отсутствуют. Т.е. совсем.
The SPARK Ada subset[6] totally excludes exceptions. SPARK’s designers argue that
user-defined exceptions should not be needed and that the predefined exceptions should
never be raised in a well-constructed program.

Так что абсолютно непонятно, к чему приведет выход за пределы диапазона. Обработать это нет возможности.

А вот то, что автор не пользуется статическим анализом кода - гораздо серьезнее.
252 Rate_Change_Gx : T_Float_4 := Rad_Gx;
253 Rate_Change_Gy : T_Float_4 := Rad_Gy;
254 Rate_Change_Gz : T_Float_4 := Rad_Gy;
255 Integ_FB_Gx : T_Float_5 := Rad_Gx;
256 Integ_FB_Gy : T_Float_5 := Rad_Gy;
257 Integ_FB_Gz : T_Float_5 := Rad_Gz;

На самом деле, как следует из нижеприведенной цитаты, автор не использует SPARK в чистом виде:

In SPARK, things are more complicated: PID functions do some calculations over the inputs, like calculating the error between the measured angle and the desired one. We’ve seen that, without any information about input ranges, it’s very difficult to prove the absence of runtime errors on calculations, even over a basic one like an error calculation (Error = Desired – Measured). In other words, we can’t implement a general PID controller using the Ada Float type if we intend to prove it with SPARK.

The good practice here is to use Ada generics: by creating a generic PID package using input, output and PID coefficient ranges as parameters, SPARK will analyze each instance of the package with all information needed to prove the calculations done inside the PID functions.

Речь идет о следующем разделе, где он ограничивает нагрузку на двигатели. Он так и пишет, что для введения ограничений для типов данных лучше использовать обычный язык Ада (вход, выход и коэффициенты контроллера PID), а дальше уже работает система контрактов SPARK: доказать, что с учетом этих ограничений все остальное будет работать правильно.

Как я понял, SPARK работает на этапе сборки кода, и поскольку он полностью исключает ошибки времени выполнения, exceptions тогда действительно не нужны.