Господин rezident, немного наслышан о тебе, как об опытном специалисте. Вот скажи мне как на духу, можно ли из DCO в сочетании с FLL добиться достойной стабильности в выдержке временных интервалов или лучше сразу оставить эти недежды, подцепить часовой кварц и не морочить себе голову? Как при этом пострадает потребление (если вообще пострадает)? Возможно при этом еще чем-то приходится жертвовать (кроме копеек на кварц)?

Сообщение отредактировал vazz - Jan 3 2014, 20:38

Я конечно не опытный специалист. Точнее я неопытный не специалист Однако я думаю, что от DCO нельзя ждать стабильности, ведь его частота зависит от окружающей температуры. Подключение часового кварца, как я думаю, почти не повлияет на энергопотребление, если его использовать в качестве хронометра. Ведь все время проц будет "спать" в режиме LPM3 и "большое" потребление будет только при возникновении прерывания. Я знаю устройство на MSP (промышленное конечно), в котором кроме всего есть часы реального времени. Так вот от батареи 3 вольта эти часы правильно функционируют гарантированно 1 год.

P.S. Да поправит меня rezident или другой опытный специалист

Я сперва тоже подумывал про часы реального времени, т.к. необходимо архивировать данные за длительные промежутки времени. А потом решил, что точки на CC430 будут калиброваться от хоста по времени, а вот в нем уже придется заморочиться с RTC.

А на счет DCO и FLL спрашивал, потому как в Users Guide встретил "When the FLL operation is disabled, the DCO continues to operate at the current settings. Because it is not stabilized by the FLL, temperature and voltage variations influence the frequency of operation.", а потом меня что-то отвлекло и я ушел от этой темы, подумав что FLL каким-то образом помогает компенсировать влияние температуры и решил по ходу дела спросить у мудрых разработчиков.

А можно еще вопрос?))

Не могу я понять смысл взаимодействия с SVSM(L/H)DLYIFG. Что это за задержка? Смутно понял, что эта задержка нужна для устаканивания Vcore/Vcc при изменении этих самых Vcore/Vcc. А можно для тех кто в танке по простому в двух словах обрисовать сей механизм, если не трудно конечно. И как вычисляется эта задержка (зависит же и от температуры наверное и от уровня Vcore/Vcc..)?

vazz, можно, как ты говоришь, оффтоп... Ты пишешь на ассемблере. Подскажи, как описать переменную (размером, например, 2 байта), расположенную по адресу 0х09FE. Чтобы потом, если я вдруг ошибусь и в тексте программы к этой переменной обращусь как к 1 байту (MOV.B например), компилятор поругал меня за это.

Наверное как-то так:

Я тоже так попробовал сделать (только для объявления байта надо писать DEFC, для слова DEFW). Если var1 - это просто переменная, то все хорошо. Но у меня в программе есть массивы. Я попробовал таким образом описать адрес первого элемента массива. При обращении в коде к первому элементу массива все хорошо, а вот при обращении к остальным компилятор выдает предупреждение:

Кроме того, как я понял, конструкцией вида DEFC(W) описываются регистры специального назначения. А для пользовательских переменных есть директивы DS8, DS16 и т. д. Как только сделать то, что хочется?...

RC-генератор никогда не отличался особой стабильностью. Его частота зависит от температуры и напряжения питания. И хотя за счет различных ухищрений добились стабильности DCO в единицы процентов во всем диапазоне рабочих температур, но до стабильности даже плохонького кварцевого генератора ему как до Луны пешком. Вообще все погрешности описаны в datasheet конкретного кристалла. Для СС430F5137 в таблице DCO Frequency на стр. 52 указано типовое значение температурного дрейфа DCO величиной 0,1%/°C и дрейф от изменения напряжения питания (опять же типовое значение) 1,9%/V.
С FLL тут вообще мимо. FLL поддерживает среднее значение частоты DCO на периоде разрядности модулятора. Причем в MSP430 FLL "цифровая", а не аналоговая. Т.е. поддержание среднего значения заданной частоты происходит за счет пропуска импульсов более высокой тактовой частоты. Так, что для "связных" дел использование FLL вообще не стоит даже и планировать. FLL может пригодиться для подстройки частоты DCO, но не для постоянной работы в качестве источника тактовой частоты.

Потребление генератора опять же нужно смотреть в datasheet, таблица Crystal Oscillator, XT1, Low-Frequency Mode на стр.50.

Основное отличие (если конечно не рассматривать точность поддержания частоты) RC-генераторов (DCO, REFO, VLO) от кварцевых (XT1/LFXT, XT2) состоит в быстродействии включения в рабочий режим. DCO готов к работе уже через 6мкс. Для XT1/XT2 с высокочастотным кварцем время готовности после запуска/включения составляет под сотню мс. Для XT1/LFXT с часовым кварцем - порядка 500мс и даже до 1с (с дерьмовеньким noname кварцем). С другой стороны в типичном применении часовой кварц и не выключают. Ибо генератор LFXT потребляет не более 0,5мкА.
Опять же типовым hint для MSP430 является подстройка частоты DCO от LFXT с часовым кварцем. Для этого у СС430F5137 есть возможность внутренне подключить ACLK к CCI2B таймера TimerA0 и с помощью него измерить отношение частоты SMCLK (тактируемого от DCO) к частоте ACLK (тактируемого от часового генератора). Другие варианты подстройки частоты DCO - использование REFO и FLL. Но вы сами должны понимать, что REFO это такой же генератор RC-типа и соответсвенно он может давать погрешность до 3,5% во всем рабочем температурном диапазоне, см. таблицу Internal Reference, Low-Frequency Oscillator (REFO) в datasheet СС430F5137.


Никаким образом не помогает компенсировать темепературу! FLL это не генератор, а Frequency Locked Loop - устройство, поддерживающее на выходе среднюю частоту на периоде с разрядностью собственного модулятора. В качестве опоры/эталона FLL использует частоту от внешнего тактового генератора. Соответственно долговременная стабильность выходной частоты DCO, управляемого FLL, не может быть лучше стабильности частоты внешнего генератора. А кратковременная стабильность на периоде модулятора вообще хреновая, т.к. пропуски импульсов FLL вызывают джиттер (дрожание фазы) выходной частоты.

Признаюсь честно, что у меня был только один проект на кристалле, имеющем эту самую систему SVS (MSP430F5438A). Но я SVS не использовал и поэтому все возможности ее не исследовал, обойдясь типовыми/рекомендуемыми значениями регистров, и, запретив генерацию прерываний событий от SVS. Через пару месяцев планируется доработка этого проекта, вот тогда возможно и дойдут руки до использования SVS.
Вообще про работу SVS с графиками и времянками описано в разделе 2.2 PMM Operation в CC430 Family User's Guide Rev.E. - slau259e.pdf

Я не крутой программер (я больше схемотехник), поэтому я пораскинул тем скудным багажом опыта, который приобрел и ничего лучше в голову не пришло, как применить индексный режим адресации. Т.е. в одном из регистров ЦПУ хранишь начальный адрес своего array, а с помощью другого регистра делаешь смещение. Ну ты это и сам понимаешь наверное, sorry.

d7d1cd, rezident спасибо парни! бывают же отзывчивые люди, бескорыстно делящиеся опытом. Побольше бы таких - глядишь Родина наша не была бы в хвосте сектора радиоаппаратостроения и производства отчечественных РЭК)

rezident, спасибо за развернутые ответы, прям как литературу читаешь и балдеешь, все по-русски и с конкретными цифрами) Единственное по поводу SVS(M) - я наверное запрещу прерывания по возвращению уровней напряжения в удовлетворительное состояние дабы тоже пока не заморачиваться с этим, а вот при снижении ниже плинтуса надо бы наверное хоть подмаргнуть пользователю (если есть чем), что мол "барахлит чо-то". Мне кажется этот мониторинг сделан по большей части, чтобы отловить "неверное" соотношение частота/напряжение ядра (например, когда напряжение Vcore снижено до минимума, а частота выжимается слишком большая).

А можно еще поспрашивать?

Так сказать вопрос опять же для опытных. Я тут подбираюсь к начальной инициализации всех узлов на борту. И вот думаю.. А как по феншую принято проводить начальную настройку MSP430, вернее в каком порядке. Я вот как думаю (и если я недальновидно думаю, то очень прошу меня поправить на начальном этапе):

1. Останов WDT. (приоритет высший, т.к. дается 32мс на раздумья)
2. Настройка системы сброса.
3. Настройка системы питания.
4. Настройка системы тактирования.
5. Инициализация всей периферии, в т.ч. настройка тактирования, прерываний и питания каждого из периферийных модулей (по началу планирую все отключать, а потом брать этот шаблон и в новом проекте включать только то, что нужно, не вспоминая как отключать остальной функционал).

Или может после WDT надо сперва систему тактирования настроить? Вобщем кто в какой последовательности делает, учитывая свой опыт?

И попутно вопрос, т.к. порылся и нашел в закромах кварцы на 32.768кГц, которые шли в наборе вместе с отладочными модулями EM430. Они изначально не впаяны на платы, это возможно с чем-то связано? Типа попробуйте сначала с DCO помучиться, а когда надоест сами впаяете? Ничего ж страшного не будет, если я впаяю их прямо сейчас на свое штатное место, конденсаторы на вх/вых гены никакие не нужны как я понял, всё внутри предусмотрено.

Сообщение отредактировал vazz - Jan 4 2014, 16:35

Объявить его по DSn в своей отдельной секции данных (после rseg MY_SECT_NAME), а секцию - уже расположить по заданному адресу.

SVS аппартно-программный модуль и нужен в основном для правильного функционирования "железа". Т.е. когда процессы меняются быстро и что-то может из-за этого заглючить. Задействовать SVS для мониторинга величины питания батарейки, чтобы потом подморгнуть или нарисовать индикацию пользователю, не имеет смысла - для этого (при медленном изменении величины) больше подходит АЦП, который унунтре имеется. У него еще и внутренний вход мультиплексора для измерения напряжения собственного питания предусмотрен.

Вполне нормальный/допустимый порядок. Тут еще кое-что от нюансов применения зависит.
Во-первых, следует помнить, что дефолтное состояние (default state) всей периферии MSP430 после сброса и/или включения питания позволяет ему нормально работать вообще без инициализации питания и тактирования (кроме настройки функций пинов конечно же).
Тут нюансы состоят в том: нужно ли вам обрабатывать и определять причины (ре)старта, например, было ли включение питания или была перезагрузка по WDT или от bootloader или какого-то иного источника прерываний? Как быстро вам нужно инициализировать все периферию: если очень быстро, то имеет смысл вначале настроить систему тактирования и питания для работы на более высокой частоте. Если быстро не обязательно, то можно вначале функции пинов настроить, чтобы на выходах было заранее определенное состояние и что-либо висящее снаружи не потребляло много в этот момент, когда на выходах "плавающие" уровни.
Во-вторых, нюанс языка программирования: ASM или ЯВУ типа Си? На ASM можно успеть инициализировать и до срабатывания WDT. А если Си, то по-хорошему отключать WDT нужно не в main, а в функции _low_level_init, которая вызывается еще до main. Потому, что если в программе будут большие глобальные массивы, то процедура очистки глобальных переменных (по стандарту в Си все глобальные переменные должны быть инициализированы нулями или конкретными значениями) не успеет все выполнить до срабатывания WDT и main у вас не стартует вообще никогда.
В-третьих, некоторые параметры инциализации могут зависеть от текущих пользовательских настроек. Поэтому процедура инициализации должна предусматривать не только собственно начальную инициализацию, но и реинициализацию с другими (заданными) параметрами. Например, параметры настройки UART или время перехода в режим энергосбережения с гашением индикатора и отключением связи или еще что-то такое же. Причем весьма желательно, чтобы реинициализация одного модуля не влияла на работоспособность других модулей. Что в случае с системой тактирования - задача довольно нетривиальная.
В общем начальный выбор ваш вполне верный, а дальше думаю вы "допилите" в соответствии со своими собственными нюансами. Только советую не лениться и сразу продумать и выделить HAL (Hardware Application Level), а также предусмотреть возможность реинициализации всех модулей. Да, не скрою, что это может занять довольно много времени. Но зато потом вы получите бонусы от того, что вас минуют многие "головняки" с работой периферии и вам не придется начинать писать все заново "с низов"

Точняк! Надо распределить ПЗУ на сектор своего "загрузчика", а остальную часть ПЗУ поделить пополам, одну половинку - под "горячее", вторую - под бэкап. Я конечно еще не добрел, но думается что MSP430 сам себя шить может? Одна половина ПЗУ будем служить пространством под выполняемое прикладное ПО, а вторая - для переноса первой половины перед обновлением ПО по радиоканалу. В случае потери связи во время сеанса обновления - делаем бэкап без потери работоспособности изделия

А можно примерчик... И сразу вопрос: а если я в сегменте CODE буду располагать константы, то место, занятое константами, кодом занято не будет?

У меня сейчас IAR не установлен под 430. так что сорри, скриншотов не дам. Давно было. А по коду - кажется вот так:


rseg DATA0:DATA, 01234h
или
ASEGN DATA0:DATA
ORG 01234h

my_data: DS8 16


а далее дело линкера - он секцию на указанный адрес забросит.

Если в любой секции типа RSEG/ASEG будут константы, то их место не займется кодом никогда. Линкер объединяет все где либо найденные куски одинаковых секций в последовательность кода/данных. Исключение - COMMON секции, их линкер ставит на один и тот же физический адрес, позволяя по-разному использовать одну и ту же область памяти (например разные подпрограммы могут использовать одну и ту же область данных каждая по-своему). Но таким свойством обладают только COMMON-сегменты.

Сделал как советуете. Создаю место для переменной размером в 2 байта. Однако если я пытаюсь отправить в my_data не слово, а байт (что как бы ошибка), то компилятор мне ничего не говорит... А ведь тут ошибка.

Сообщение отредактировал d7d1cd - Jan 4 2014, 17:50

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