Форум РадиоКот

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 А куда ж она тогда делась? Где она потеряла свой "путь джедая"? Программа не может просто так взять и бесследно исчезнуть, особенно на ассемблере. Она конечно может уйти не туда, куда ожидается, из-за того, что были приняты неверные данные и перебросили её в случайное место. А вашей квалификации оказалось недостаточно, чтобы это определить.

Произошёл аппаратный сбой. Я привёл пример, как быстро удалось определить, что это аппаратный сбой, а не баг программы. Соответственно, не тратилось время на анализ программы и быстро была обнаружена ошибка монтажа.

AQ29 писал(а): Ср сен 02, 2026 14:13:16 Это пример из постов на сайте. Там, насколько помню, была не опытная эксплуатация, а реальная работа. Больной выдохнул, время перезагрузки оказалось достаточной для трагичного исхода.
Юнит-тесты тут вряд ли помогли, в программе нет явных ошибок.
Нужна была опытная эксплуатация, которая выявила бы этот недостаток без смертельного исхода.

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

Кстати, в прошлый раз в этой сказке вы писали, что "медсестра на кнопку нажала" Я ж говорю, это просто сказка-пугалка, ничего более! И вообще, с чего вы взяли, что вы чето понимаете в медицине то? Приснилось чтоль?

AQ29 писал(а): Ср сен 02, 2026 14:13:16 А как отлаживать схемотехнику схему, в которой стоит управляющий МК?

Что значит "КАК"? Вы разницу между схемой и программой улавливаете? Схемотехника - это как подключить микроконтроллер - подать питание, входные и выходные сигналы. А программа - это как он будет работать.

AQ29 писал(а): Ср сен 02, 2026 14:13:16 Схемотехник будет указывать программисту, выставь такую частоту, потом такую, сделай тут импульс, поменяй время усреднения и т.д. схемотехник должен пригласить программиста и работать вместе

Чето вы походу ваще нивзуб ногой в этом деле. Пишите какую-то ерунду.
Только совсем неграмотный схемотехник может не знать, как сделать какой-нить RC-фильтр по заданным временнЫм параметрам.
И да, схемотехник с программистом работают совместно. Совместно делятся результатами, обсуждают. И это - совершенно нормальная практика КОМАНДНОЙ работы, где каждый выполняет СВОЮ работу, поскольку он специалист В СВОЕЙ области.
А так, что "и жнец, и швец, и на дуде игрец" - это только от бедности. И результат будет посредственный. Либо крайне долго придется ждать.

AQ29 писал(а): Ср сен 02, 2026 14:13:16 Эти вопросы должны быть решены до опытной эксплуатации.

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

AQ29 писал(а): Ср сен 02, 2026 14:13:16 Для меня такая работа выглядит несерьёзно.

А вот для меня всё ваше балабольство про "хороший ассемблер" и сказки про мертвого поцыэнта выглядят несерьезно

AQ29 писал(а): Ср сен 02, 2026 14:13:16 На АВУ такой ассемблерной «портянки» нет, по размеру текст, наверно, близок к тексту на СИ и путь программы хорошо читаем.

Тогда на кой хрен вообще нужна ваша тряхомудия, когда уже есть нормальные проверенные инструменты?? А доверять вам, никому неизвестному челу с неизвестным образованием, без какого-либо портфолио, без доказательств, без сертификации - да на кой хрен??? Чтоб потом какой-нить поцыэнт помер из-за ваших недоработок? Да ну нахрен, вы чо?

Вы почему-то заявляете, что языки С/С++ плохие, а ваш безымянный - хороший. Но никто из нас, присутствующих здесь в теме, с этим не согласен. Во-первых, никто за 10 лет так и не увидел вашего "языка" и не протестировал его. Во-вторых, это просто никому нафик не нужно, когда есть немало уже проверенных годами инструментов.
А ваши заявления - абсолютно несерьезны, некомпетентны, бездоказательны и попросту глупы. И о чем тут говорить еще? Что вы кому тут пытаетесь голословно доказать? Ваши доказательства крутятся вокруг одной фразы - "Си плохой, макроассемблер хороший". Чушь какая-то

AQ29 писал(а): Ср сен 02, 2026 14:13:16 Я привёл пример, как быстро удалось определить, что это аппаратный сбой, а не баг программы

Баг программы состоял в том, что она "вышла из одной точки и не пришла в другую", как вы ранее писали. Вот ответьте, куда растворилась программа между этими двумя точками? Хорошо написанная программа не должна "растворяться" между этими точками, она должна остановиться и просигнализировать об аппаратном отказе.