Хочу в msp430F1121
завести внутренний DCO на таймер А ?
Как это в IAR-е осуществить?
Вот такие строчки не помогают
bis.w #TASSEL_2,&TACTL
bis.w #MC_1,&TACTL
где я туплю?
никак у меня TAR в симуляторе инкрементится не хочет.

Дык в симуляторе IAR периферия вроде не симулируется.

Да? Плохо

Можно попробовать через макросы, но я лично не разбирался с ними и не использовал. При нужде в симуляторе ручками вношу требуемые значения в регистры и/или переменные.

Нужно, чтобы именно инкрементился таймер или нужно прерывание от него? Если первое, то есть вариант найти старый C-SPY, который еще от версий 1.хх, там ТИ специальный драйвер поставлял IAR'у, который позволял симулировать периферию. Работало это достаточно быстро и корректно. Чтобы запусить в том симуляторе программу, нужно при сборке указать линкеру выходной формат ubrof6.

Но на деле все же, как правило, нужен не инкремент таймера, а прерывание от него, чтобы смоделировать событие. Для этого в C-SPY служит система специальных макросов. Тема уже поднималась не раз, посмотрите этот топик и еще этот.

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

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

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

Ловите. Зачем для этого макросы-то? Прерывания вызываются из окна Forced Interrupt Window. Что, поймали?

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

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

Спасибо, проникся. Осталось выучить матчасть

Если просто нужен вызов обработчика прерывания Timer_A,то в IAR'e
1. Запускаем программу в режиме симулятора
2. Тискаем меню Симулятор->Прерывания...
3. Выбираем тип прерывания (там перечислены все возможные истоники), устанавливаем периодичность вызыва прерывания (в тактах CPU), номер такта , когда произойдет вызов ISR в первый раз + длительность, вероятность срабатывания
4. Радуемся жизни - мы сделали "симуляцию" прерывания, т.е. мы можем посмотреть, что MSP будет делать когда произойдет то или иное прерывание. Но TAR, кажется, инкрементироваться не будет. Источников прерываний в симуляторе можно установить не один и не два.

Не знаю, но по-моему так более понятно, чем общий ответ "дык, нужно использовать макросы".
P.S. Если таймер используешь просто чтобы посчитать длительность выполнения того или иного куска кода, то там есть просто счетчик тактов CPU

Спасибо! Проникаюсь сейчас IAR-ом, вроде не такая уж и бесполезная штука этот симулятор

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

Кроме того, есть случаи, которые через меню просто не сделать. Например, это симуляция поступления данных через последовательный порт или от АЦП. Тут требуется брейк типа immediate, при котором реальной остановки не происходит, но зато вызвается функция (писанная там же нами же), которая подсовывает в нужный регистр нужное значение (хоть из файла берет).

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

А кто спорит? Я кроме макросов для симуляции, еще тыкаю и кучу условной компиляции. Правда пока пригодилось всего 1 раз. Но кто его знает, что там впереди "за крутым поворотом". Но согласитесь если в самом начале свое жизни на вопрос "а как сделать" получить ответ "а сделай с помощью макросов", то желание жить дальше может и пропасть?

Не вполне согласен - если при этом предложение сопровождается подробным рабочим примером с пояснениями и указанием, что в документации все подробно описано, то ситуация другая: для начала берется предложенный пример на пробу, потом, если осознается нужность/полезность фичи, начинается и более плотное изучение.