AQ29 писал(а): Вт авг 25, 2026 11:16:19
Судя по вашему посту о большом количестве отказов при опытной эксплуатации
Я ТАКОГО НЕ ПИСАЛ! Просьба внимательно читать контекст.
Я изначально писал про МОДУЛЬНОЕ тестирование (unit-тесты). Оно выполняется во время написания самой программы как средство самоконтроля этапов создания программы, промежуточное тестирование.
А вы сами писали, что при "опытной эксплуатации медсестра нажала на кнопку, пошла перезагрузка и пациент умер". Но это результат непроведения юнит-тестов.
Вы сначала пишите одно, потом другое. И откуда вы вообще придумали эту "опытную эксплуатацию" медицинских приборов? Знаете ли, вас, с вашим "ассемблером высокого уровня" вообще втуда не допустят.
AQ29 писал(а): Вт авг 25, 2026 11:16:19
Я привёл пример отказа, это реальный случай.
Какой случай? С ошибкой монтажа на печатной плате? А какое отношение она имеет к программе?
AQ29 писал(а): Вт авг 25, 2026 11:16:19
Я не испытатель, почему я должен помнить про все испытания
А почему ж тогда пишите про испытания?

Эдак каждый может насочинять сказок.
AQ29 писал(а): Вт авг 25, 2026 11:16:19
Как программист и электронщик будут определять, у кого ошибка.
- Программист пишет программу и отлаживает её на макетных платах.
- Схемотехник (не "электронщик!" схемотехник правильно) еще до сдачи в производство проверяет плату в САПР-е, так же как и программист свою программу.
- Изготовитель проверяет плату и на входе на соответствие допускам и требованиям производства, и на выходе - визуальный контроль, электротест, рентген, если надо.
- Монтажник компонентов так же проверяет плату и на входе (визуально), и на выходе - визуально, приборами, рентгеном. Микроконтроллеры могут устанавливаться на плату уже прошитыми, а могут прошиваться при сборке. Для этого не надо быть программистом. Достаточно уметь подключать разъемы.
- Пусконаладчик запускает плату и тестирует её работу. Ему не нужно знать языки программирования и путь программы. Он ориентируется на сигналы в тестовых точках. Эти точки так же определяются при разработке платы.
Кто прошляпил выходной контроль на своем участке - тот и виноват. Элементарно жеж.
А вот на опытной эксплуатации проверяются не баги программиста или ошибки монтажника, а общая концепция устройства - насколько оно вообще грамотно спроектировано, насколько удобно им пользоваться, где какие возникают сложности у пользователя, насколько заявленные характеристики удовлетворяют требованиям эксплуатации.
Так что вы чето сильно перепутали определения. То ли не знали, то ли еще и забыли.
AQ29 писал(а): Вт авг 25, 2026 11:16:19
Возможно, на Си неясен путь программы. У ассемблера существенный плюс – хороший контроль за ходом программы.
Опять голословное и непрофессиональное утверждение. Просто вы не знаете языка, но беретесь утверждать за его поведение. Это непрофессионально.
На ассемблере как раз-таки путь программы совсем не ясен из-за его специфики. Конечно, когда программа линейная, с короткими переходами, тогда еще более-менее понятно, просто листай сверху вниз и всё видно. Но таких программ очень мало, только самые примитивные.
Вот вам небольшой кусочек реальной программы на АССЕМБЛЕРЕ, попробуйте по нему отследить "путь программы", если сможете:
Спойлер
Код: Выделить всё
8000994: ldr r0, [sp, #0]
8000996: strh r1, [r2, #26]
8000998: rsb r1, r3, #1024 ; 0x400
800099c: uxth r1, r1
800099e: pkhbt r2, r1, r6, lsl #16
80009a2: uqsub16 r2, r0, r2
80009a6: uxth r0, r2
80009a8: lsrs r2, r2, #16
80009aa: pkhbt r2, r0, r2, lsl #16
80009ae: ldr r0, [sp, #4]
80009b0: uqadd16 r2, r2, r0
80009b4: movs r0, #2
80009b6: mov.w ip, #4
80009ba: mov.w lr, #3
80009be: ldr.w r5, [r8, #44] ; 0x2c
80009c2: add.w fp, sp, #160 ; 0xa0
80009c6: strb.w sl, [sp, #157] ; 0x9d
80009ca: strb.w sl, [sp, #158] ; 0x9e
80009ce: ubfx r5, r5, #16, #13
80009d2: strb.w ip, [sp, #152] ; 0x98
80009d6: uxth r4, r2
80009d8: strb.w lr, [sp, #153] ; 0x99
80009dc: strb.w r0, [sp, #154] ; 0x9a
80009e0: strb.w r0, [sp, #155] ; 0x9b
80009e4: strb.w r0, [sp, #156] ; 0x9c
80009e8: strb.w r0, [sp, #159] ; 0x9f
80009ec: ldr.w r7, [r8, #16]
80009f0: uxtab r7, fp, r7
80009f4: ldrb.w r7, [r7, #-8]
80009f8: sdiv r5, r5, r7
80009fc: cmp r4, r5
80009fe: ble.w 8001c56 <main+0x197e>
8000a02: ldr.w r2, [r9, #36] ; 0x24
8000a02: ldr.w r2, [r9, #36] ; 0x24
8000a06: orr.w r2, r2, #2
8000a0a: str.w r2, [r9, #36] ; 0x24
8000a0e: ldr.w r2, [r9, #36] ; 0x24
8000a12: cmp r2, #0
8000a14: bne.n 8000a0e <main+0x736>
8000a16: sub.w r2, r3, #11
8000a1a: ldr r1, [pc, #556] ; (8000c48 <main+0x970>)
8000a1c: mov.w r0, #8192 ; 0x2000
8000a20: cmp.w r2, #468 ; 0x1d4
8000a24: strh r0, [r1, #24]
8000a26: bhi.n 8000a2c <main+0x754>
8000a28: subs r3, #1
8000a2a: uxth r3, r3
скажу честно - дануевонахрен, такое занятие!

Там подобных строк - десятки тысяч! Вы че, издеваетесь чтоль, разгребать такое??
Не, конечно, если очень надо, небольшие кусочки разгрести можно. Но искать, куда пошел "путь программы" в этом месиве - эт мазохизм какой-то.
Языки Си-группы в этом плане гораздо нагляднее, даже в простых программах.
Так что вы зависли где-то на уровне 20-летней давности. Сейчас, в 2026 году бессмысленно утверждать про удобства ассемблера (и макроассемблера тоже), как бы они не выглядели. Ну не тот компот, неперспективно это.
Вы сами уже сколько - 10 лет? - возитесь со своим "макроассемблером", а никто его до сих пор не видел, кроме словесного восхваления, как всё в нем удобно. А чтож удобного, если другие языки давно эти удобства реализуют. Конкретики же - ваще никакой. Это какая-то сверхтайна, чтоль? И чем вы там думаете удивить мир? 20 лет назад надо было удивлять, сейчас уже опоздали. Ничего вы там удивительного не скажете. Выкатите очередной лисапэд на кривых колесах с рулем под седлом. Тот же Rust уделает ваш макроассемблер как занефикделать.
AQ29 писал(а): Вт авг 25, 2026 11:16:19
Программа должна была прийти в указанную точку, свернуть на том участке некуда, но не дошла, генератор выключился.
А куда ж она тогда делась? Где она потеряла свой "путь джедая"? Программа не может просто так взять и бесследно исчезнуть, особенно на ассемблере. Она конечно может уйти не туда, куда ожидается, из-за того, что были приняты неверные данные и перебросили её в случайное место. А вашей квалификации оказалось недостаточно, чтобы это определить.
Этож одна из базовых ошибок, когда получив ошибочные входные данные, программа, не проверив их корректность, улетает в случайное место кода. Типичный пример - табличный переход по индексу таблицы. Если был получен (вычислен на основе входных данных) неверный индекс, "ход программы" уходит в непредсказуемое место. У вас это и случилось, просто вы не стали дорабатывать программу.
И такое поведение для программы - потенциально опасное. Особенно в свете этих ваших "медицинских приборов". Вот именно с таким неожиданным пропаданием пути программы у вас и помрет поциент под ИВЛ из вашего любимого медицинского примера. Потому что вы в своей программе не предусмотрели определенного поведения при внешних отказах и помехах. Понимаете? Выключился генератор = поциент умер!

А всё из-за непредсказуемого поведения программы из-за внешних помех. Всего лишь помехи - и пациент умер. Кто виноват? ВЫ! Вы написали плохую программу с непредсказуемым поведением. А вы говорите - медицЫна. Какая медицина, когда генератор остановился?
AQ29 писал(а): Вт авг 25, 2026 11:16:19
У меня написано про разработку схемы, а не всей электроники сложного агрегата. Схема – это, например, какой-нибудь регулятор расхода.
При очень простой схеме возможно совместить программиста и схемотехника в одном лице. Большинство в любительском сообществе так и делают. Да и то не всегда. Предпочитают покупать готовые платы с микроконтроллерами, датчиками и дисплеями и соединять их проводками.
Но любительское сообщество - это совсем не промышленность, особенно как вы любите про медицину. Хотя, смотря что вы медициной называете

Электронный термометр в
жопу подмышку - тоже медицина.