Jump to content

    
Sign in to follow this  
rezident

USCI vs USART и прочие хождения по граблям

Recommended Posts

Понадобилось мне тут в одном проекте посмотреть влияние скорости расчета на точность результата. Проект был написан для 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 уже не годится.

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites
Жизнь продолжается, а коллекция граблей пополняется от новых поступлений :biggrin:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this