Привет всем! Подскажите, существует ли программа кроме NoICE, с помощью которой можно имитировать работу микроконтроллера семейства MSP430 по заданной программе (предпочтительно на ассемблере)?

NoICE все ничего, но не айс! То ли я чего то в нем не знаю, то ли он не правильно имитирует работу МК: специальные регистры и регистры периферии при сбросе не принимают значений, указанных в документации на МК.

Полностью смоделировать работу всей периферии МК это весьма сложная задача. Поэтому симуляторы обычно реализуют ограниченную модель функциональности периферии микроконтроллера. В IAR C-CPY, например, более-менее функционирует лишь событийная модель флагов прерываний.

А что вы скажите по поводу программы Proteus?

Какие, например?
Большинство периферийных регистров к сбросу равнодушно.

"Не читал использовал, но осуждаю!" Потому, что (см. первое предложение из моего предыдушего топика).
Как раз большинство периферийных регисторов после сброса принимают конкретное состояние. И это становится проблемой для программиста, если он заранее надеется на default state. Поэтому я уже давно всем подряд советую использовать полную и явную инициализацию всех используемых регистров и не использовать маски, накладываемые на значения "по-умолчанию" (получаемые после сброса), как это часто встречается в примерах от TI.

+100500
Многие ругают либы от STM. А ведь там для каждого периферийного узла есть функция DeInit(). И ее рекомендуют применять достаточно безусловно. Эти функции приводят в исходное (дефолтовое) состояние всех регистров периферии принудительно. Очень полезное действо. И не надо хвалится, мол я подобный инит на три байта короче напишу, чем эти индусы....

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

Вы думаете, а я знаю, наиболее оптимальный способ написать и отладить программу на микроконтроллере это подключиться к процу через JTAG и отладить в пошаговом режиме.
Симуляторы это не "удобный способ", а возможность вообще не иметь дела с аппаратной частью. С микропроцессорами такие финты не проходят.
Вариантов исхода может быть два. Первое Вы будете долго бороться с симулятором процессора, потому что он выдает результаты, отличающиеся от описания процессора в даташите.
Второе убив время на борьбу с симулятором может оказаться так, что программа отлично работающая в симуляторе не пашет на реальном процессоре.
И поскольку никто никогда не верит в чужой опыт, Вам скорее придется потратить полгода жизни, чтобы осознать, что симуляторы всегда полное фуфло и никогда не заменят реальной микросхемы. Могу только пожелать удачи.

Ну почему же так уж принципиально? Симулятор вполне пригодная вещь, чтобы проверить работу алгоритма частей программы, не привязанных жестко к "железу" МК. Но для этого нужно уметь разбивать программу на (под)уровни и выделять из них хотя бы HAL (Hardware Application Layer).
Не так давно симулятор помог нам с коллегой найти багу, возникшую при переносе исходника программы (как раз непосредственно с периферией не взаимодействующую) с ARM7 на MSP430. Бага возникала при неявном преобразовании типов данных. Причиной возникновения оказался неверно выбранный предыдущим программистом для группы переменных тип данных (unsigned short vs signed int).

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

можно поспорить конечно, не буду.

Если HAL выделить, то всё остальное кроме него можно скомпилировать как .exe под Windows и отлаживать алгоритмы. Нужен конечно программный модуль который замещает собой HAL для работы под Windows, с функцией main или WinMain. То есть например вместо вывода по UART данные пишутся в файл, вместо вывода в порт общего назначения значения битов рисуются в окне приложения и т.д.
Симулятор не нужен.

Сам так делал 20 лет назад под DOS, для 80186.
Но теперь то зачем, если практически любая среда обеспечивает удобную отладку?
Да и отладка нужна только на первоначальном этапе, до запуска на МК средств общения с окружающим миром.

В описанном мною случае один и тот же кусок исходника, скомпилированный в Borland C++, MSVC, IAR EWARM и IAR EW430, давал разный результат вычислений. Все дело было в волшебных пузырьках неявном приведении к разным типам данных (integer promotion). Тип int на x86, на ARM и на MSP430 вовсе не одинаковой разрядности. Так что симулятор иногда бывает нужен

не нужно ни когда использовать int, short, long и т.п., по крайней мере когда пишешь для мк. Нужно использовать типы из <stdint.h>, такие как uint8_t, int16_t, int32_t. Будет тогда идентичный результат вычислений. тогда даже избежишь проблем при запуске программ написанных для win32 собранных(запущенных) в win64

ps Даже с чаром проблемы. хоть чар он и в африке 8 бит. но я обычно использую char = signed char. Но, например в иар, по умолчанию стоит галка, что чар есть беззнаковый.

Ага всегда! А если на DSP посмотреть и размерность char у них?