> Аноним считает, что если запустить код для armv8 на armv5, то ошибка
> в работе будет программная. Аноним совсем глупый пошел.Я бы сказал что аналогия идиотская.
> Меньше википедию читайте. Мы лет 10 (или 15) назад, я уже не
> помню, довольно тщательно пережевывали эту ситуацию.
1) Источник ваших данных?
2) То что вы там где-то пережевывали лично мне не видно.
3) Поэтому извольте какие-то более материальные пруфы.
А со всякими Сакральными Знаниями можете курнуть бамбук. Информация такого плана должна быть обоснована и подтверждена. Чем-то более существенным чем понт на форуме.
> Переполнение там правильно обрабатывалось, все как надо.
А почему другие источники утверждают что команда заоверрайдила проверку и в результате при переполнении целого начался бред?
> Проблема была в том, что команды управления оборудование обрабатывало неправильно.
Пруф данных сведений, вы, конечно же, предоставите? Можно какой-нибудь официальный отчет тех кто это расследовал, или что вам там удобно.
> Прямой пример: управление рулевой колонкой фокуса, перенесенное на самосвал. Обработка
> команды поворота слишком медленное, ввиду чего как ты не пытайся компенсировать
> недостаточный поворот, ничего не получится.
Это какой-то весьма своеобразный пример. Если вы хотите сказать что некая команда делающая ракету вот настолько не компетентна - вы предоставляете пруф, это не те вещи в которых верят на слово, независимо то того какой вы там мегапро в какой там мега конторе.
> А как датчикам можно доверять "не слепо"?
Ну вот так.
1. Смотри, в ADC заявлено что он 12 бит, но регистр можно читать как u16 или u32, реальный размер регистра такой. Если железо однажды вернет более 12 битов (технически может) - на этом можно погореть. Если не сделать проверок сразу, математика возьмет в оборот, после всяких переполнений может получиться что-то правдоподобное. Однако по факту оно является бредом. А как проверять? В том случае, допустим, if (sample > 0xFFF) {hardware fault}. Вот так мы круто и резко знаем что он нас на...вает.
2. В ответственных местах ставят несколько датчиков. И если их показания сильно различаются - мы знаем что имеет место проблема железа. В лучшем случае можно отсеять проблемный датчик и продолжить. Игнор этой идеи угробил как минимум один Airbus, когда ему помыли датчик водой под давлением в нарушение инструкций. Он летал, но на высоте вода замерзла, датчик стал гнать, компьютеры начали парировать мнимое превышение угла атаки. И в конце концов угробили самолет.
3. Если мы примерно представляем себе поведение объекта и валидные диапазоны, выход за эти диапазоны является индикатором проблем того или иного свойства. Ну, например, flight software в таком случае по нормальному должно сообщить пилоту что не понимает что за д#рьмо творится и отдать штурвал в failsafe режиме, и это уже проблема пилота, он имеет больше шансов. Более приземленные объекты логично привести в безопасное состояние (fail safe) и репортить отказ. А дальше разбираться что за нахрен.
> Попросить ардуинку в окошко выглянуть, что ли? Что это, вообще, за бред?
Эм... можно и чуть попродвинутее, так то.
> датчикам. За "да тут датчики просто неправильно показывают, давайте проигнорируем" ты
> бы, Аноним, вылетел у меня со свистом без выходного пособия.
Мне нравится такой подход. Но вылетел бы он за "давайте проигнорируем". Я разве настаивал что эту ситуацию игнорить надо? При обнаружении левых показаний надо скорее всего перейти к fail safe вообще-то. Но так то прикольно считать всех д@билами, в принципе, опеннете это понимаемо, что уж :)
> Датчикам он решил не доверять.
Доверять нельзя никому. Особенно в ответственных применениях. Ни софту, ни железу, в том числе и датчикам. Иначе на этом можно жестко погореть, а раз в год и палка стреляет. Вы вообще firmware safety guidelines крупных производителей читали?
> Датчики показывают, что пациент поджаривается от значений, которые источник в принципе
> выдать не может? Алярма, все выключить, громко звенеть и требовать срочных спасателей!
А у вас был какой-то план если датчик, например, подохнет? В том числе и в процессе? Или выдает нечто левое, не соответствующее ожидаемому "профайлу операции"? Пациент при этом имеет шанс пожариться, по утрате обратной связи? Просто кончина по отвалу или глюкам обратной связи - весьма типовой failure mode.
> Потому что раз в год и источник может выдать то, на что не расчитан.
Так и датчик раз в год может выдать не то. И хуже всего если пациент жарится, а датчик гонит что все в порядке. Если там многократное резервирование датчиков - логично все вырубать с тем же алармом когда хоть один начинает гнать. Не?
> Для тех, кто не в курсе - на вход программной системе подается
> уже согласованное в железе правильное значение дублированных систем датчиков, чтобы не
> нагружать лишней работой вычислительную систему.
Ну это уже какая-то конкретика, и у вас, видимо, какое-то фирмваре сделало часть упомянутого. И оно именно дублированное? А не х3 хотя-бы? Если датчиков только 2, нельзя понять кто гонит. Хотя для вырубания операции достаточно.
