1. В каких случаях отладка/тестирование в симуляторе более оптимальны, чем в "железе", а в каких менее оптимальны? (оптимальны в смысле затрат времени и/или интеллектуальных ресурсов (отладка может быть НЕ оптимальной с точки зрения затрат времени, но оптимальной с точки зрения затрат интеллектуальных ресурсов (когда "думать не надо"(писать всякие отладочные скрипты и т.п.))))
2. Какие задачи по отладке/тестированию вообще решаемы только в симуляторе и не решаемы в железе?

Часто слышу такую точку зрения, что симуляторами пользуются только ламеры и начинающие электронщики. А профессионалы ("правильные" инженеры), мол, пользуются только отладкой/тестированием программы в реальном "железе".

Что Вы думаете по этому поводу? Особенно интересуют ответы на вопрос п.2

Говоря о симуляторах я не имею ввиду конкретные симуляторы типа AVR Studio с урезанными возможностями (из-за которых возможно "правильные" инженеры и возненавидели все симуляторы как класс программного обеспечения) в которых даже отладочные скрипты нельзя писать. Я говорю вообщем

По п.2

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

Во всех случаях, симулятор оптимальнее.
Не оптимален при недостатке знаний и опыта работы с программой.
Иногда проще моделировать в железе, например, взаимное влияние корпусов элементов и геометрический конструктив высокочастотных устройств.


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

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


В общем, не знаю, знаком только с Pspice и MicroCap.
Занимаюсь разработкой таких изделий, которые без симулятора сложно спроектировать.

Только, что дочитал ваш пост до конца, вы имели в виду другие симуляторы, да ну ладно ответ не по теме, но пусть будет.

Спасибо за столь подробный и развёрнутый ответ.

Но, Вы, как я понял, говорили о схемотехнических симуляторах аналоговых устройств. А я бы хотел поговорить о симуляторах микроконтроллеров, позволяющих выполнять, тестировать и отлаживать код Target MCU у себя на компе. Т.е. о компьютерной программе, в которой можно иммитировать входные сигналы, выполнять программу для Target MCU и получать выходные сигналы такие же, какие будут в реальном ("железном") микроконтроллере.

Прошу прощения, что сразу не сделал это уточнение

Ещё по п.2
В симуляторе легко можно "подать на пин" напряжение ПРОИЗВОЛЬНОЙ формы, что мягко говоря затруднительно будет сделать в реальном железе

Навскидку - два случая.
1. Железо ещё не собрано, а сроки жмут.
2. Сложные внутренние алгоритмы, а железо не поддерживает внутрисхемную отладку (сейчас это редкость, но всё же встречается). А "лапами дёргать" всё же как-то лучше в реале... особенно, если на МК куча периферии навешана, которой ни в каких симуляторах нет и не предвидится.

Гуманитарии на марше.

=============8<=============
Большая советская энциклопедия
Оптимальный
(от лат. optimus — наилучший), наиболее благоприятный, лучший из возможных (например, О. решение).
=============8<=============

Разъясню написанное в БСЭ. Прилагательное "оптимальный" имеет только одну степень - превосходную. Никаких более\менее.

Говорите по-русски правильно.

Да, в общем, правильно говорят "правильные" инженеры.
Конечно, здесь речь идет об отладке ПО для готового устройства, а не о симулировании(моделировании) схемотехники. Реальное "железо" всегда предпочтительнее любого симулятора. Если есть возможность - нужно отлаживать ПО на нем. Если нет - то имеет смысл собрать макет (пусть даже в усеченном виде), и все равно отлаживать на нем.
Попытаюсь обосновать:
1) Работа программы на симуляторе всегда может чем-то отличаться от работы на реальном "железе". А может и не отличаться. Как минимум, придется это потом проверить. А как максимум - повторить весь процесс отладки заново. (Это по поводу затрат времени.)
2) В процессе отладки проверяется не только (и не столько) правильность работы программы, но еще и правильность работы схемы устройства, оценивается влияние различных факторов (наводок, шумов и т.п.). То есть отлаживается работа реальной связки "железо+ПО". Так как отдельная, "правильно написанная", программа никому не нужна. Так же как и отдельное, правильно спроектированное "железо".
3) Перед написанием рабочей программы устойства, не лишне сначала написать ряд тестов, чтобы убедиться, что "железо" работает, и работает именно так, как это было задумано. Тут могут "всплыть" нюансы, которые потом серьезно повлияют на разработку рабочей программы. Иногда, после таких тестов, приходится дорабатывать (перерабатывать) и схему устройства. Если Вы целиком доверитесь симуляторам, то обнаружите все эти проблемы только в конце работы...

Хочется добавить к вышесказанному, на симуляторе остаешся до тех пор пока это все не заработает. Если оно не работает на симуляторе, то и на железе не заработает. Скорость отладки на симуляторе намного быстрее, чем на железе. Но в конечном итоге проект должен быть проверен на железе в любом случае.
Простой пример, тестирование на симуляторе 30 минут, на железе 30 секунд. Обычно, когда все заработает, результат с железа обязан совпадать с симулятором (обязательно выборочно проверить).
По моему я уже тафтологией занимаюсь, но смысл понятен.

Ну например, когда программное обеспечение пишут 24 программера, а железка одна. Если ждать пока один отладит свою часть на железке другие 23 будут просто тупо простаивать

В свое время пришлось писать для PIC'ов всякую экзотику - типа умножения 3-х байтового числа на 5-и байтовое. Без симулятора - вилы...

все что можно отладить на компе следует на нем, а что нельзя на мк

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

Если кратко. Симулятор для проверки и отладки (аппаратно-независимых) алгоритмов. Эмулятор для проверки и отладки взаимодействия алгоритмов с аппаратурой и различных конечных автоматов, связанных с аппаратурой, между собой.

Золотые слова. Плностью их поддерживаю!!! Их надо поставить в рамку во всех холиварах на тему нужны симуляторы как класс или нет

Если подходить просто с точки зрения отладки железа/Программы/прибора, то ИМХО в принципе достаточно легко рассчитать по какому пути нужно идти - моделирование или реал. В этом случае нужно подсчитать во сколько обойдется создание модели железа/МК/прибора в железе или в софте + во сколько обойдется создание внешней среды для тестирования этого железа/МК/прибора, достаточной для полного тестирования устройства.
Например я разрабатываю контроллер 3-х фазного инвертора для 10-кВольтных сетей мощностями в десятки МВт. Если все отлаживать в реальном железе, то один неправильный дрыг пином приведет к боьшому буму стоимостью не один десяток к?. Поэтому используются и симуляторы и железо:
1. Matlab+Simulink - отлаживается алгоритм управления инвертором. Sympowersystems - отлаживается модель инвертора с сетью 10кВ. Все в виртуале.
2. Прототип на 380В с реальным контроллером - отлаживается алгоритм и железо. Это в реальном времени.
3. RTDS - отлаживается контроллер с виртуальной сетью 10кВ в реальном времени.
4. Счас делаем Matlab+XPCTarget. Для отладки в основном железа в реальном времени.

Конечно для испытаний есть и реальный прототип на 2МВт, но спектр возможных действий в этом случае очень сильно ограничен, так как при испытаниях например на КЗ можно весь завод остановить. Поэтому это все делается в симуляторе и принимается на веру.