Это пример из постов на сайте. Там, насколько помню, была не опытная эксплуатация, а реальная работа. Больной выдохнул, время перезагрузки оказалось достаточной для трагичного исхода.Rapra писал(а): Вт авг 25, 2026 13:21:45 А вы сами писали, что при "опытной эксплуатации медсестра нажала на кнопку, пошла перезагрузка и пациент умер". Но это результат непроведения юнит-тестов.
Юнит-тесты тут вряд ли помогли, в программе нет явных ошибок.
Нужна была опытная эксплуатация, которая выявила бы этот недостаток без смертельного исхода.
А как отлаживать схемотехнику схему, в которой стоит управляющий МК?Rapra писал(а): Вт авг 25, 2026 13:21:45 Программист пишет программу и отлаживает её на макетных платах.
Для отладки надо менять с помощью МК параметры схемы, например, частоту и скважность генератора, формировать необходимые импульсы и паузы, время усреднения и т.д.
По-вашему, получается, схемотехник должен пригласить программиста и работать вместе. Схемотехник будет указывать программисту, выставь такую частоту, потом такую, сделай тут импульс, поменяй время усреднения и т.д.
Посиди часок, я графики построю, проанализирую, что там происходит, затем продолжим.
Ещё сложнее при разработке сложной следящей схемы, где для обеспечения правильной работы необходима совместная работа программы и схемы.
Для меня такая работа выглядит несерьёзно.
Неясна ситуация с программистом. С одним изделием для него недостаточно работы, будет вести, скажем, десяток изделий.
Схемотехнику понадобилась отладка, а программист занят более важным изделием, освободится через месяц. И что, ждать месяц?
Схемотехник для разработки подобрал, скажем, новый МК АВР. Там есть
сенсорные кнопки, АЦП до 17 разрядов, логические элементы, дифференциальный и программируемый усилитель, то, что нужно. А программист скажет, я с таким МК не работаю.
Проходил испытания, потому и пишу. Разработчику лучше всего пройти их без серьёзных проблем. А в каком порядке - для этого есть соответствующие люди.Rapra писал(а): Вт авг 25, 2026 13:21:45 А почему ж тогда пишите про испытания?Эдак каждый может насочинять сказок.
У вас получается, что аппарат, представленный на опытную эксплуатацию, «вообще неграмотно спроектирован, пользоваться им неудобно, заявленные характеристики не соответствуют требования ТЗ».Rapra писал(а): Вт авг 25, 2026 13:21:45 А вот на опытной эксплуатации проверяются не баги программиста или ошибки монтажника, а общая концепция устройства - насколько оно вообще грамотно спроектировано, насколько удобно им пользоваться, где какие возникают сложности у пользователя, насколько заявленные характеристики удовлетворяют требованиям эксплуатации.
Эти вопросы должны быть решены до опытной эксплуатации.
На АВУ такой ассемблерной «портянки» нет, по размеру текст, наверно, близок к тексту на СИ и путь программы хорошо читаем.Rapra писал(а): Вт авг 25, 2026 13:21:45 Вот вам небольшой кусочек реальной программы на АССЕМБЛЕРЕ, попробуйте по нему отследить "путь программы", если сможете.
На ассемблере как раз-таки путь программы совсем не ясен из-за его специфики. Конечно, когда программа линейная, с короткими переходами, тогда еще более-менее понятно, просто листай сверху вниз и всё видно. Но таких программ очень мало, только самые примитивные.
Произошёл аппаратный сбой. Я привёл пример, как быстро удалось определить, что это аппаратный сбой, а не баг программы. Соответственно, не тратилось время на анализ программы и быстро была обнаружена ошибка монтажа.Rapra писал(а): Вт авг 25, 2026 13:21:45 А куда ж она тогда делась? Где она потеряла свой "путь джедая"? Программа не может просто так взять и бесследно исчезнуть, особенно на ассемблере. Она конечно может уйти не туда, куда ожидается, из-за того, что были приняты неверные данные и перебросили её в случайное место. А вашей квалификации оказалось недостаточно, чтобы это определить.
