[rezident 0]

Понадобилось мне тут в одном проекте посмотреть влияние скорости расчета на точность результата. Проект был написан для MSP430F148. Ядро МК работало на максимальной документированной частоте 8МГц. Чтобы увеличить рабочую частоту ядра взял пин-ту-пин совместимый кристалл из серии 2xxx (MSP430F2418).

На первый взгляд ничего не предвещало трудностей. Ага. Это только на первый взгляд. :crying:

Первый трах был с системой тактирования. Попробовал использовать калибровочные значения для DCO. Здорово конечно придумано, что калибровать не нужно, но кварцевый генератор XT2 не работает. Совсем. Пляски с емкостью нагрузочных конденсаторов и заменой кварца не помогла. Начал внимательно изучать описание регистров. Ага. Бит XT2OFF в регистре BCSCTL1 после сброса установлен. Раньше я его сбрасывал сразу же при первой инициализации регистра и после этого просто ждал пока колебания кварца стабилизируются и сбросится бит OFIFG. А тут все сложнее. Значение калибровочных данных для DCO (CALBC1_16MHZ) имеет такое же значение бита, отключающего генератор XT2 (XT2OFF), как и после PUC. Т.е. при записи калибровочного значения, генератор XT2 остается выключенным и если его нужно включить, то вместо

BCSCTL1=CALBC1_16MHZ;

нужно писать

BCSCTL1=CALBC1_16MHZ&(~XT2OFF);

Ладно. XT2 завели. Но LFXT что-то глючит. Оказывается, часовой кварц плохо заводится, если у него нагрузочная емкость не соответствует номинальной. Но я же ничего на плате не менял! Фигня война. Нужно просто проинициализировать новый регистр BCSCTL3, где кроме номинала встроенных нагрузочных резисторов для LFXT нужно выбрать еще и рабочий диапазон для кварца генератора XT2. Пишем

BCSCTL3=XT2S1|XCAP_3; // XT2 - 8Мгц, 12,5пФ для LFXT

и едем дальше.

А дальше у нас была связь. USART видоизменился в USCI. Памятуя, что ребята из TI всегда кричали и рвали на груди рубашку, что они-де за совместимость снизу вверх и если улучшения требуют нарушить совместимость, то ну их на эти улучшения, особых подвохов я не ожидал. К сожалению, при разработке USART разработчики забыли про свои лозунги :(

Нет, я конечно понимаю, что красота требует жертв. Но зачем же столько плана при этом курить? :laughing:

Ну добавили функциональности и теперь из одного модуля можно получить два интерфейса в комбинации: 1 асинхронный (UART/LIN/IRDA) +1 синхронный (I2C/SPI) или 2 синхронных(SPI+I2C/SPI) (правда вектор прерывания у них один на двоих), да еще и порядок следования битов можно менять программно. Нечего сказать, молодцы! Но зачем нужно было тасовать управляющие биты и регистры для уже привычного UART-то? :cranky: Но и это еще не самое страшное. Грабельки ребятки положили на совсем ровном месте. В серии 1xx бит CHAR, отвечающий за разрядность данных (7/8 бит) имел значение: 0 - 7бит, 1 - 8бит. В серии 2xx мужики решили вые... эээ... по-своему. Типа формат 7-и битных данных устарел и мало кто его использует. Давайте сделаем по-умолчанию 8-и битный формат данных. Ну решили так и сделали бы, чтобы соответствующий бит (по имени UC7BIT) был установлен после PUC. Для совместимости с предыдущим UART. Не-е-ет, так не интересно, решили в TI. И инвертировали значение этого бита. Теперь у них: 0 - 8бит, 1 - 7бит. А чо такого, имя-то ведь другое дали. :07: А у меня значение этого бита в параметрах связи при настройке передается и я полдня убил на выяснение факта инверсии, пытаясь понять почему связь, то с ошибками идет, то вообще прерывания от приемника не поступают. :crying: А еще значение регистра модулятора теперь нужно считать немного по-другому и старая программка в Excel уже не годится.

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

[AHTOXA 14]

Да уж:-) Сочувствую...

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

[Sinoptic555 0]

Они наверняка следуют своей, только им известной концепции

- которая к стати может менятся после очередной конференции или еще чего либо.

 

Вот вы как разработчик, придумывая что то новое, наверняка в будущее смотрите,

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

 

Так и они, смотрят в будущее, ...типа, а фигня, пусть разработчик сейчас плюхается, разберется с нюансами, зато потом все будет в рамках единой - СВОЕЙ - концепции.

Хотя, конечно, по идиотски получается, им не до нас с вами.

 

Хорошая статейка, надо сохранить чтобы на эти грабли не наступать.

[DogPawlowa 0]

Жизнь продолжается, а коллекция граблей пополняется от новых поступлений

Спасибо, важная информация.

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

У АВРов и того нет.

[rezident 0]

Кстати, тем, кто еще не читал оригиналы или затрудняется с английским, будут полезны переводы документов Migrating From MSP430F13x/14x to MSP430F23x/24x и Migrating From MSP430F16x to MSP430F261x, любезно предоставленные Российским дилером TI фирмой Компэл.

Ссылки на переводы см. в привешенной теме FAQ по MSP.