USCI vs USART и прочие хождения по граблям, "секс" при переносе проекта на MSP430F2418 Опции

[rezident]

Понадобилось мне тут в одном проекте посмотреть влияние скорости расчета на точность результата. Проект был написан для MSP430F148. Ядро МК работало на максимальной документированной частоте 8МГц. Чтобы увеличить рабочую частоту ядра взял пин-ту-пин совместимый кристалл из серии 2xxx (MSP430F2418).
На первый взгляд ничего не предвещало трудностей. Ага. Это только на первый взгляд.
Первый трах был с системой тактирования. Попробовал использовать калибровочные значения для 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 разработчики забыли про свои лозунги
Нет, я конечно понимаю, что красота требует жертв. Но зачем же столько плана при этом курить?
Ну добавили функциональности и теперь из одного модуля можно получить два интерфейса в комбинации: 1 асинхронный (UART/LIN/IRDA) +1 синхронный (I2C/SPI) или 2 синхронных(SPI+I2C/SPI) (правда вектор прерывания у них один на двоих), да еще и порядок следования битов можно менять программно. Нечего сказать, молодцы! Но зачем нужно было тасовать управляющие биты и регистры для уже привычного UART-то? Но и это еще не самое страшное. Грабельки ребятки положили на совсем ровном месте. В серии 1xx бит CHAR, отвечающий за разрядность данных (7/8 бит) имел значение: 0 - 7бит, 1 - 8бит. В серии 2xx мужики решили вые... эээ... по-своему. Типа формат 7-и битных данных устарел и мало кто его использует. Давайте сделаем по-умолчанию 8-и битный формат данных. Ну решили так и сделали бы, чтобы соответствующий бит (по имени UC7BIT) был установлен после PUC. Для совместимости с предыдущим UART. Не-е-ет, так не интересно, решили в TI. И инвертировали значение этого бита. Теперь у них: 0 - 8бит, 1 - 7бит. А чо такого, имя-то ведь другое дали. А у меня значение этого бита в параметрах связи при настройке передается и я полдня убил на выяснение факта инверсии, пытаясь понять почему связь, то с ошибками идет, то вообще прерывания от приемника не поступают. А еще значение регистра модулятора теперь нужно считать немного по-другому и старая программка в Excel уже не годится.
Но это уже мелочи. Жизнь продолжается, а коллекция граблей пополняется от новых поступлений