Доброго времени суток!
Подскажите пож, при рассмотрении работы мк по тактам:
1. в какой момент времени на выходе порта появится высокий/низкий уровень, при использовании инструкции BIS/BIC (если я правильно понимаю они требуют 1 мц)
2. в какой момент времени происходит "защелка" состояния порта, при использовании инструкции BIT
Хотелось бы получить как ответ, так и ссылку на доку в которой можно подчерпнуть подобную инфу
Заранее благодарен!

Ну насчет 1 МЦ с BIC/BIS вы наверное погорячились, а вообще по инструкциям см. в User's Guide. По времянкам см. схемотехнику портов I/O в datasheet соответствующего кристалла.

В User's Guide (slau049f) не нашел явного указания на количество МЦ для команд BIT.B, BIC.B и BIS.B, ткните меня носом плз, если не трудно. А если требуется несколько МЦ, то на каком именно такте (фронте) изменится состояние порта? Ни в datasheet ни в User's Guide, не смог найти подобную инфу . Может есть еще какой-то документ, на все MSP430?
P.S. Кристал MSP430F1611 (если это чем-то поможет для ответов)

Зависит от типа адресации. Накладывание маски вида

4 или 5 МЦ.

А вот этого я не знаю. Вы ядро MSP430 на ПЛИС собираетесь делать? Или для чего это вам нужно?

Ядро MSP430 на ПЛИС!? - это здорово. Я думаю займусь этим, но позже, когда выйду на пенсию и у меня будет уйма свободного времени
А вообще нужно было засинхр-ть работу 2-х МК с точность до 1МЦ, для одновременной выдачи ответственного управляющего сигнала. При длительности выполнения перечисленных выше инструкций в несколько тактов, ИМХО это невозможно, придется искать другие пути.
Спасибо за вниемание

Посмотрие у тексаса в апликашках - была апликашка что-то типа "управление большими LCD с помощью MSP" -там как раз описывалось управление одним большим индикатором двумя засинхронизированными MSP430. Возможно, вы сможете почерпнуть там идею.

2 Сергей Борщ

Спасибо за маячек, пойду покапаюсь в апликашках.

Для этого не нужно ждать пенсии Ядро MSP430 уже написали. Где-то на опенсорсе.орг вроде лежат его исходники.

Дык, а на простейшей логике сделать схему сихронизации для вашего случая недопустимо?

http://bleyer.org/s430/
http://caxapa.ru/47991.html?hilite=S430
http://caxapa.ru/55974.html?todo=full&hilite=S430

При наличии простейшей внешней логики синхр-ся до 1 МЦ, ИМХО не возможно, так как инструкция BIT.B требует более 1 МЦ, т.е. превышае требуемую точнось.

При наличии внешней логики можно организовать синхронизацию до 1 периода тактового сигнала, частота которого может быть выше тактовой частоты MSP430.

Не ходелось бы усложнять схему, это приведет к снижению надежности, хотелось бы решить эту проблему програмно, почему и был задан вопрос - на каком именно такте (фронте) изменится состояние порта (при исп. BIS.B. BIS., и на каком именно такте (фронте) оно "защелкнется" (при исп. BIT.?

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

Ну вот это как раз не проблема, выкинуть MCLK на ножку проца и делать посылки с достаточно большим интервалом, даже на аналоговом осцилле будет все прекрасно видно.

Хорошо, тогда вопрос вам: как вы определите с какого именно из импульсов MCLK на этой ноге началось выполнение команды?

У меня настойчиво просится наружу мысль: вроде где-то читал что реальное изменение состояния на выходе при записи в PxOUT происходит на последнем переднем фронте MCLK команды. Искал - не нашел где вычитал

Ну вообще это вроде как логически вытекает. Последовательность такая: выборка кода команды (1МЦ), выборка операндов (1-2МЦ), действие над операндами (1МЦ), запись результата действия (1МЦ). Поскольку запись последняя в этой цепочке, то и на выходе пина сигнал появится на последнем МЦ выполнения всей команды.

Честно сказать, я думал вы несколько о другом говорили, подразумевая синхронизацию скопа.
Но коли так: можно попробовать синхриться по внешнему прерыванию. При этом нужно загасить WDT и оставить пустым основной цикл. И все посылки делать из прерывания.+Шаманство.

Вот именно! Нужно внешнее событие (ведь от чего-то автор вопроса хотел синхронизировать два процессора) и некое время от реакции на это событие до выполнения следующей команды. Время это будет в общем случае недетерменированным, ибо процессор должен закончить выполнение текущей команды, а это от 0 до 5 тактов задержки. И даже если будет 100% известно "какой командой процессора черт ест колобка в pacman-е" (на каком такте дергается выходная нога) - это ровным счетом ничего не даст. Если надо дергать ногой с точностью до 1 тика тактовой частоты - надо использовать таймер тактированный этой частотй и его режимы захвата и сравнения. Только так можно будет поручиться за временные диаграммы и это будет сделано простым, наглядным и естественным способом. Критикуйте.

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

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

Нет, здесь нет Prefetch. Потому и команды длинные такие.

Ну вообщем согласен. Есть правда еще один способ, но он требует валидацию после каждой компиляции: подбор на живом железе. Т.е знаешь какую последовательность надо получить и получаешь. Применять можно только в том случае, если последовательности всегда одинаковые. Это сродни использованию в ПЛИС в качестве задержек луты-иногда работает, но на 100 процентов поручиться за результат низя.

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