Ошибка в вычислениях адресов у GCC ?

Hi Peter !

Совсем недавно 14 Feb 05 12:41, Peter Kostenko писал к Yuriy K:

PK>>> получаешь симулятор управления оборотами дизеля. YK>> Hет. Ты не моделируешь передаточную характеристику дизеля.

PK> - добавить модель дизеля в симулятор не составит сложности. Ты говоришь как человек, который это делал? Или это твое мнение о сложности задачи (модель дизеля)? Про дизель не скажу, но стоимость матмодели котла для электростанции составляет пятизначное число в валюте. Может быть дизель несколько проще, но вряд ли его модель является конструкцией выходного дня.

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

И еще случай из практики- делали систему управления газовой турбиной. Так количество зубьев на шестеренках, с которых измеряются скорости вращения, не совпадало с записанным в проектной документации. Hаладчики N лет назад защиты подстроили под реальную ситуацию, а в документации отразить забыли. И где бы я был, если бы не произвел натурных испытаний, выявивших несоответствие?

WBRgrds Ruslan

Tue, 15 Feb 2005 16:04:28 +0000 (UTC) Leha Bishletov wrote to Harry Zhurov:

LB>>> Если указать Auto Folder, то не удается создать свою папку, как в LB>>> Custom View. HZ>> Ну, создаешь Custom View, в нем сколько угодно папок, в них HZ>> раскладываешь файлы. Что не так?

LB> При этом не получается ни одну из папок сделать Auto Folder. Т.е. что LB> бы одновременно, в одном проекте были и папки Custom View и папки Auto LB> Folder.

Вообще-то, Auto Folder - это фича, в которую входят опции Package View, Directory View и Custom View. Т.е. Custom View - это разновидность фичи Auto Folder. :) Т.ч. противопоставлять их как бы не корректно. Видимо, ты имел в виду совокупность Directory View и Custom View?

LB> Но, возможно, этого и не нужно ... Я еще не пытался его использовать LB> понастоящему, возможно, что Auto Folder вполне достаточно.

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

LB> Вот ты, например, в каком режиме его используешь и сколько у тебя файлов в LB> проекте?

:) Ты будешь смеяться, но я, уже довольно долго работая с этим редактором, почти не пользовался панелью Files - лазил в свойства проекта через меню - добавлять/удалять файлы в/из проект/а приходится редко. Основные панели у меня Defs и Classes. А тут задали вопрос, можно ли настроить дерево файлов проекта в панели файлов, полез и обнаружил такую фичу. Счел ее удобной и организовал себе дерево. ИМХО, главное удобство от этого - это не держать открытыми кучу файлов (а только необходимые) и иметь возможность быстро открыть любой из интересующих файлов, не лазя по диалогам файловой системы.

Hello, Yuriy! You wrote to Peter Kostenko on Tue, 15 Feb 2005 15:55:34 +0300: PK>> Если у тебя не будет возможности показать работу на конечном PK>> оборудовании, PK>> а продемонстрировать работу устройства необходимо будет

YK> Задача - управлять дизелем, а не демонстировать потенциальную

это ваша задача

YK> работоспособность программы. Это не курсовик и не диплом, а вполне YK> такое реальное железо на большой железной машине.

а задача сабжа - тестировать твое устройство

PK>> - добавить модель дизеля в симулятор не составит сложности.

YK> Сколько моделей дизеля _ты_ создал?

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

With best regards, Peter Kostenko.

----

Hello, Dmitry! You wrote to Vladimir Vassilevsky on Tue, 15 Feb 2005 21:21:14 +0300:

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

у них другая цель ;-) завалить дизель своей железкой - по всем их письмам они дизель тестируют, а не свою железку.

With best regards, Peter Kostenko.

----

Hello, Maxim! You wrote to Peter Kostenko on Fri, 11 Feb 2005 12:03:10 +0300:

PK>> получаешь симулятор управления оборотами дизеля. MP> Hичего ты не получаешь. Это случай когда моделирование поведения MP> железки невозможно. Поскольку физические законы которые связывают MP> изменение "дребезжащих импульсов" от коэциента заполнения шим даже с MP> использованием разных эмпирических коэфицентов и допущений, займут не

мы дизель тестируем или устройство управления? ;-) если все-таки устройство, то, например, хотелось бы

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

узнать, а как система будет реагировать на нестандартное поведение счетчика оборотов? например, засорилось там чего-нибудь, или зуб отвалился (только не надо мне опять объяснять, что я ничего не понимаю в моделях датчика скорости (с дребезгом) ж-))) ) и вместо периодичных импульсов, с дребезгом, у вас начнут поступать пачки импульсов (то есть некоторых импульсов вообще не будет)?

MP> один лист А4 и в конечном счете вкравшаяся на каком-то этапе MP> погрешность сделает задачу эмуляции невозможной, т.е. созание твоего

кто ставит задачу эмуляции - тот пусть её и рещает, а разработчика необходимо тестировать своё устройство до вывода на объект, чтобы объект, в один прекрасный момент, не накрылся от того, что у него недерменированное поведение в простой штатной ситуации, которую вовремя не проверили, а про нештатные ситуации я вообще пока не вспоминаю - про дизель нештатную ситуацию придумать ;-) пожалуйста. даём ему максимально-запредельную нагрузку(в механизм попало масло с мусором), обороты падают. что управляющее устройство будет делать (вы так и не сказали как оно реагирует на внешние "раздражители", поэтому приходится додумывать) пытаться увеличить обороты. обороты увеличили, наша нагрузка ("шестеренки") разогрелись, давление масла повысилось... как вам такое начало армагеддона? ;-)

MP> тест юнита - задача на 100 порядков более сложная, чем создание

никто и не говорил, что будет легко..

With best regards, Peter Kostenko.

----

Hello, Dima! You wrote to Peter Kostenko on Tue, 15 Feb 2005 19:56:00 +0300: ??>> чтобы написать тест для программной части - надо хотя бы знать что ??>> там написано. DO> Обычно что-то на тему PID, но бывают варианты и весьма разнообразные. я додумывать за автора вопроса не буду - пусть сам напишет

DO>>> Hет, поскольку твой симулятор, в отличие от двигателя, не замкнут. Он ??>> если симулятор не выполняет полный набор функций системы - этот ??>> этого он не перестает называться симулятором. DO> Симулятор, который не симулирует перестает называться симулятором.

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

DO>>> не реагирует на изменение выхода программного регулятора. ??>> если надо чтобы реагировал - добавьте обратную связь DO> Какую именно?

это вас надо спрашивать - мне она не нужна

DO>>> Соответственно регулятор ляжет на какой-то из упоров, или сообщит об DO>>> ошибке и остановится. ??>> Вот это и будет первым результатом тестирования ;-) DO> А толку? проверять-то надо во всем реально возможном диапазоне значений DO> и реакций.

это будет второй, третий и так далее шаг, пока не будут проверены максимально возможное количество состояний конечного автомата (опять приходится додумывать, как устройство работает, но приходится. Вы не разработчики, а какие-то "капризные заказчики" ;-) без обид. не нравится это словосочетание, давайте по другому: state maschine). А вот уже когда все простейшие состояния проверены и остались те немногие, которые очень сильно завязаны на железо, и стоимость построения симулятора начинает превышать (или не превышать, а становится слишком большой в стоимости проекта) стоимость обхекта + риск его сломать, тогда выходим на объект и доводим тестирование до конца. Риск порчи объекта снижается, когда большинство нештатных ситуаций уже симулировано и при возникновении такой ситуации на объекте у вас будет больше шансов остановить тестирования не доводя ситуацию до опасной.

??>> это только в случае согласия заказчика. DO> Причем тут вообще заказчик? Hе знаю как тебе, а мне полуфабрикаты никто DO> не заказывает. Без проверки работоспособности _устройства_ (содержащего DO> программу) вся моя деятельность никому не нужна. Причем проверки не на DO> симулятор, а на реальный объект управления. _Только_ так.

где находится данный объект (в данном случае дизель)?

DO>>> и тестировать не программные модули, аустройство. ??>> надо помогать заказчику тестировать устройство, а не впадать в ??>> крайности "только на объекте". DO> Ты неправильно понял слово "объект". Речь идет об объекте управления DO> (двигатель, лампа, насос, etc), а не о том, что ты подумал. И если DO> делается контроллер двигателя, сначала он проверяется на двигателе,

хорошо, на чьи средства приобретается этот двигатель?

DO> потом в составе транспортного средства и к тому моменту, как машина кто финансирует предоставления вам "транспортного" средства для тестирования?

DO> попадает в торговую сеть, ее устройства уже должны быть оттестированы. ??>> что будете делать, когда тестировать на объекте нет возможности? DO> Изыскивать возможность.

правильно, ты её сам будешь искать? или все-таки заказчик тебе будет помогать? (финансами или средствами или другим каким-то способом). Если ты будешь самостоятельно это делать (искать возможности), то кто в конечном итоге будет оплачивать эту работу - или всё бесплатно?

??>> по сабжу вопросы кончились? ;-) DO> Это что-то такое, что к большому куску реальной embedded работы DO> отношения вообще не имеет? Тогда да, кончились. Если нет, то не DO> кончились. Из полученных ответов у меня пока что картина не сложилась.

пид-регулятор - это алгоритм? та функция, которая в него закладывается, известна? можно подать на её вход набор различных параметров, при котором можно однозначно сказать, что на выходе будет то-то и то-то? Если да, то пишем набор таких тестов, который, например, будет запускать после каждой компиляции и будет следить за "шаловливыми" ручками разработчика _автоматически_

With best regards, Peter Kostenko.

----

Hello Andy.

DL>> Еще подход: каждый релиз отбранчивать в отдельную ветку, тогда он DL>> может существовать самостоятельно (мало-ли понадобится изменить DL>> что-то именно в нем, не затрагивая другие релизы)

AM> Если файлы pелиза пометить меткой чеpез tag, то какой смысл еще каждый AM> pаз отщеплять ветвь, если по этомy tag можно извлечь этот pелиз AM> пpоекта в любое вpемя и отщепить от него ветвь, по фактy возникшей AM> необходимотси ?

А я и не говорил, что это надо делать одновременно, все зависит от выбранной политики и средств source control.

Dmitry

Hello Jurgis.

JA>>> Полагаю, что с помощью пакета управления версиями эту же JA>>> работу можно будет делать более круто! :) DL>> Hу, тогда вот тебе еще совет, который, возможно съэкономит тебе DL>> некоторое количество времени и усилий.. DL>> Снабжай codeline своего проекта метками релизов, тогда достаточно DL>> легко будет синхронизироваться к нужному релизу по метке, не DL>> путаясь в промежуточных submissions.

JA> Большое спасибо тебе за помощь! Поясни, пожалуйста, что JA> подразумевается под метками релизов?

ну, например, история codeline может выглядеть так: (одномерный случай)

. . Label_2_02_05 ProjManajer: Все оттестировали, отгружаем заказчику . Вася: Понедельник, я пофиксил баг номер 234 . Фиксер: Вася урод, с похмелья сломал билд, починил. Label_17_03_05 ProjManager: Пофиксили баги 12,45,33, все оттестировано, внутренний релиз . .

Метками помечены сабмишены, обладающие нужным качеством. Синхронизировав исходники в локальном view к метке, можно получить sanpshot полностью рабочей и оттестированной системы в тот момент времени.

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

тут уже на первое место выходит манагерение проекта...

Dmitry

Привет!

Wed Feb 16 2005 00:46, Maxim Polyanskiy wrote to Kirill Frolov:

KF>> Hу тебе может не нужная. А вообще очень нужная. Как минимум, KF>> позволяет всегда откатиться назад, в случае чего. Кроме того, KF>> возможность вести несколько параллельных ветвей, например KF>> "стабильную" KF>> и всегда готовую к работе, и "разрабатываемую" MP> #define 'новая мега идея' MP> #ifdef 'новая мега идея' MP> 'новый супер код' MP> #else MP> 'старый рабочий код' MP> #endif

Во! Точно! Именно так я и делал! Однако, пришло время и я завалился этими проклятыми #if-ами выше крыши. Они меня так достали, что я теперь смотрю на что-то cvs-подобное как на спасательный круг :) Спасибо, здешние наши коллеги этот спасательный круг мне бросили, не дают окончательно потонуть! Спасибо, коллеги! :)

Так, как ты говоришь, хорошо для _одного_ прибора, причем достаточно простого, стабильного и не изменяющегося. Если речь идет о _ряде_, да еще и о нескольких годах выпуска - однозначно, простого архивирования тут очень мало. Hужно поиметь с этой дурацкой железяки - компьютера - гораздо больше помощи :)

Юргис

Привет!

Tue Feb 15 2005 20:52, Dmitry Lyokhin wrote to Jurgis Armanavichius:

JA>> Полагаю, что с помощью пакета управления версиями эту же JA>> работу можно будет делать более круто! :) DL> Hу, тогда вот тебе еще совет, который, возможно съэкономит тебе DL> некоторое количество времени и усилий.. DL> Снабжай codeline своего проекта метками релизов, тогда достаточно легко DL> будет синхронизироваться к нужному релизу по метке, не путаясь в DL> промежуточных submissions.

Большое спасибо тебе за помощь! Поясни, пожалуйста, что подразумевается под метками релизов?

DL> Еще подход: каждый релиз отбранчивать в отдельную ветку, тогда он может DL> существовать самостоятельно (мало-ли понадобится изменить что-то именно DL> в нем, не затрагивая другие релизы) В этом случае картинка codeline DL> становится двумерной :)

Точно! Это именно то, что мне нужно. У меня она и сейчас двумерная, но очень уж много ручной работы :) А комп, спрашивается, на что?!

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

Именно! Постоянно с этим сталкиваюсь.

DL> Hу, а если дальше развиваться, вводя параллельные бранчи с разным DL> уровнем качества кода, то общая картина может выйти за пределы 3-х DL> измерений :) DL> и вообще, integration management штука хитрая..

Увы, Дмитрий, к сожалению очень хитрая... И многомерная... Hо ведь люди побеждают трудности, не так ли?! :) Поэтому меня радует, что имеются некие средства, помогающие разработчику в этой сложной борьбе! :)

Юргис

Hello Maxim!

MP>>> Hу нету пока хоошего механизма по файлам лазить. Кстати хочу, MP>>> чтоб без мышки все работало и желательно с управляющими MP>>> комбинациями как в qedit. KF>> Vim с ctags почему-то это всё позволяет.

MP> Так оно не под маздай же.

И под него тоже.

Yauhen

... Powered by Linux

Wed Feb 16 2005 09:47, Peter Kostenko wrote to Yuriy K:

PK>>> а продемонстрировать работу устройства необходимо будет YK>> Задача - управлять дизелем, а не демонстировать потенциальную PK> это ваша задача

Разумеется.

YK>> работоспособность программы. Это не курсовик и не диплом, а вполне YK>> такое реальное железо на большой железной машине.

PK> а задача сабжа - тестировать твое устройство

Что такое "устройство", которое ты собрался тестировать.

PK>>> - добавить модель дизеля в симулятор не составит сложности.

YK>> Сколько моделей дизеля _ты_ создал?

PK> если поведение твоего устройства недетерминировано - адекватной работы от PK> него не добъешься.

Детерминировано, но неизвестно.

Сколько моделей дизеля _ты_ создал?

PK> на то, что скажет тебе заказчик.

Какой заказчик? О чем ты вообще говоришь? Что он мне скажет?

"Заказчик" - соседнее подразделение. Задача - чтобы дизель работал в требуемом диапазоне температур и нагрузок.

Я кажется начинаю понимать твою проблему. Ты забываешь про такую сущность, как время, а оно очень существенно в embedded.

P.S. вместо дизеля можно подставить любое другое устройство, требующее жесткого реального времени.

WBR, Yuriy

Wed Feb 16 2005 10:35, Peter Kostenko wrote to Dima Orlov:

DO>> Симулятор, который не симулирует перестает называться симулятором.

PK> кто написал что он не симулирует? он симулирует, но только неполный набор PK> функций.

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

DO>>>> не реагирует на изменение выхода программного регулятора. ??>>> если надо чтобы реагировал - добавьте обратную связь DO>> Какую именно?

PK> это вас надо спрашивать - мне она не нужна

Как ты собираешься отлаживать поддержание оборотов без симуляции обратной связи? 8-0

DO>>>> Соответственно регулятор ляжет на какой-то из упоров, или сообщит об DO>>>> ошибке и остановится.

Именно так. :-))) Двигатель заглох - туда ему и дорога.

??>>> Вот это и будет первым результатом тестирования ;-) DO>> А толку? проверять-то надо во всем реально возможном диапазоне значений DO>> и реакций.

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

Какого еще конечного автомата? 8-0

PK> Вы не PK> разработчики, а какие-то "капризные заказчики" ;-) без обид.

Мы практики. :-)))

PK> не нравится это словосочетание, давайте по другому: state maschine).

Только тогда уж "state machine".

PK> А вот уже когда PK> все простейшие состояния проверены и остались те немногие, которые очень PK> сильно завязаны на железо,

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

DO>> Причем тут вообще заказчик? Hе знаю как тебе, а мне полуфабрикаты никто DO>> не заказывает. Без проверки работоспособности _устройства_ (содержащего DO>> программу) вся моя деятельность никому не нужна. Причем проверки не на DO>> симулятор, а на реальный объект управления. _Только_ так.

PK> где находится данный объект (в данном случае дизель)?

В соседнем здании - подразделении той же фирмы.

??>>> по сабжу вопросы кончились? ;-) DO>> Это что-то такое, что к большому куску реальной embedded работы DO>> отношения вообще не имеет? Тогда да, кончились. Если нет, то не DO>> кончились. Из полученных ответов у меня пока что картина не сложилась.

PK> пид-регулятор - это алгоритм? та функция, которая в него закладывается, PK> известна? PK> можно подать на её вход набор различных параметров, при котором можно PK> однозначно сказать, что на выходе будет то-то и то-то? PK> Если да, то пишем набор таких тестов, который, например, будет запускать PK> после каждой компиляции и будет следить за "шаловливыми" ручками PK> разработчика _автоматически_

Смысл? После того, как модуль управления оттестирован про него забывают. При любом же изменении алгоритма управления нужно заново вычислять тестовую последовательность и все равно тестировать на живом дизеле. Вопрос: зачем нужен набор этих тестов?

Ты опять забываешь про такой интересный параметр, как время.

WBR, Yuriy

Hello, Peter Kostenko !

А почти всегда, когда нужно управлять каким-то реальным объектом, приходится тестировать и его и управляющую систему совместно.

С уважением, Дима Орлов.

Hello Dmitry.

DL>>> Еще подход: каждый релиз отбранчивать в отдельную ветку, тогда он DL>>> может существовать самостоятельно (мало-ли понадобится изменить DL>>> что-то именно в нем, не затрагивая другие релизы)

AM>> Если файлы pелиза пометить меткой чеpез tag, то какой смысл еще каждый AM>> pаз отщеплять ветвь, если по этомy tag можно извлечь этот pелиз AM>> пpоекта в любое вpемя и отщепить от него ветвь, по фактy возникшей AM>> необходимотси ?

DL> А я и не говорил, что это надо делать одновременно, все зависит от DL> выбранной политики и средств source control.

Ты написал "каждый pелиз отбpанчивать в отдельнyю веткy" Если ты имел ввидy создание ветви _вместо_ пометки файлов pелиза чеpез tag, то видимо такой подход может быть, но имхо tag здесь более адекватное сpедство.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

icq 44341220

Hi Yuriy, hope you are having a nice day!

PK>> если поведение твоего устройства недетерминировано - адекватной PK>> работы от него не добъешься. YK> Детерминировано, но неизвестно.

Ы. Hу е мое. Юрий, пофигу. Да хоть твоя программа управляет сферическим конем в вакууме - модель этого коня делать не нужно. Программа - это вполне детерминированный набор алгоритмов, как основных, так и вспомагательных.

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

Все это нужно для того, чтобы:

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

Т.е. выявить скрыте баги, которые на объекте (дизеле) могут создаваться раз в н-цать лет илии на одном дизеле из 100. Выявить ситуации, в которых твоя программа станет раком из-за какой-то незначительной ошибки в алгоритме и т.д.

Резюме: тестируются программа и алгоритмы в ней на наличие _ошибок реализации_, а не ставится задача симулировать объект, т.к. это бесполезно в плане выявления ошибок и практически невозможно.

WBR, AVB

Hello, Peter Kostenko !

А уже и написал. Какая собственно разница что там за алгоритм? Важно ведь не то как он сам по себе работает, а только то, как он работает вместе с устройством.

А что тебе нужно?

Это и будет сделано во время тестирования _устройства_, а не файла с функцией регулятора.

В лаборатории, ясное дело.

Какая разница?

Hет, я наемный работник, инженер. Изыскивать ее задача менеджмента.

Да.

Hу в широком смысле слова функция да, известна. В узком, он может к математической функции не сводиться.

Hет, нельзя. Подать можно на вход _устройства_ или прототипа устройства.

Кроме очевидного вопроса кто и как будет проверять эти тесты, возникает другой. Где эти тесты должны работать? Давай ты спустишься с высоких небес жирных платформ, где можно и компилятор и тест запустить, на землю кросс-разработок. Есть программа (точнее часть ее) для микроконтроллера. Работающая только в реальном окружении. Тот же регулятор не будет ничего делать без хотя бы времени, которое в прерывании считается. Я просто не понимаю что такое писать для подобного юнита тест. Куда его писать? Линковать вместе с остальной программой и в контроллер прошивать? Или куда?

Ты подходишь к программе, как к заказу. Потому у тебя все время заказчик фигурирует. А мне платят не за программу, а за устройство. Заказчиком программы я сам себе (или мой сотрудник мне или я ему) являюсь. Hа выходе нашей работы - не программа, а устройство. Оно не алгоритмы считает, а управляет физическим объектом. Код программы для него за редчайшим исключением когда мы являемся аутсорсом для кого-то и отдаем все, никогда не покидает стен фирмы, как и схемы и прочаяя внутренняя документация.

Так в какое место этой работы надо subj вставлять, и надо ли?

С уважением, Дима Орлов.