Господа! Крайняя необходимость в максимальном снижении стоимости изделия налагает запрет на использование часового кварца. Правило "плохой" кварц лучше, чем RC-генератор представляется сомнительным, т.к. этот самый "плохой" кварц может вовсе не запуститься (к примеру в мороз -30 или еще холоднее). А "хороший" кварц прибавляет к себестоимости более 10%, что прочит ухудшение конкурирующих свойств на рынке. Итак..

Подопытный: MSP430F6720
Функция устройства: перобразование физ.величин в кодд и передача в сеть RS-485 на низкой скорости в качестве SLAVE.
Условия эксплуатации: жесткие (всмысле окружающей среды, как природного - мороз, жара, так и техногенного характера - помехи и шумы).

На что надежды: модуль UART способен автоматически определять скорость на линии. Это свойство и дает призрачную уверенность в том, что не смотря на изменения воздействий окружающей среды в широких пределах RC-генартор сможет при большом плавании частоты "калиброваться" от MASTER. Подкрепляет также уверенность: наличие полностью стабильного MASTER в сети RS-485 (с кварцевой стабилизацией и прочими прелестями, направленными на удержание устройства в стабильно адекватном состоянии при любых помехах и воздействиях температур). Напряжение питания стабильно (не батарейное). Несмотря на "небатарейность", необходимость в максимальном снижении потребления такая же аццкая, как и необходимость в максимальном снижении стоимости.

Основные вопросы:
На сколько стабилен DCO в плане запуска?
Реальный разброс частоты (+/-20% укладывается)?
Есть ли подводные камни при отсутвии кварца, особенности конфигурирования для стабильного запуска в диапазоне -40...+70?

Поделитесь, те кто имеет опыт работы с MSP без кварцевой стабилизации, очень нужны Ваши советы!!

Доп.вопросы:

В spec sheet указаны рекомендуемые номиналы емкостей по питанию. Для конкретно данного проца они, на мой взляд, большие и их много, одних только танталов 4,7мкФ только на сам проц нужно ТРИ (а если задействуется AUXVCC, то добавляется еще один - и в моем случае он задействуется для доп.обработки события "пропадание питания" и аварийной записи параметров перед тем, как емкость на AUX разрядится и проц окончательно отключится), не считая керамики минимум ТРИ. Может кто экспериментировал с этими емкостями? Если не уменьшать кол-во танталов, то может допустимо хотя бы снизить их емкость, т.к. "хороший" тантал с минимальным током утечки стоит тоже "дорого" (по крайней мере для моего устройства).

Вобщем война за каждые 10-20мкА и за каждый рубль, если кто успокоит, буду очень благодарен

Будет задействован REFO, вроде согласно spec sheet он испытывался в диапазоне -40...+85. Вопрос пока снимается.

UART без кварца работать может, но вы эта .... насчет Automatic Baud-Rate Detection сильно не обольщайтесь. Это довольно специфичная штука, не для любого протокола применима. Почитайте соответствующий раздел (34.3.4 Automatic Baud-Rate Detection) в User's manual прежде, чем закладываться на нее.
Ну и если вы на базе MSP430F6720 проектируете электросчетчик, то без нормального RTC (а не только часового кварца) все равно не обойдетесь.

Можно попробовать так сделать, по RS232 линию переводим в обычный режим на приемном конце, а на передающем в RS232 выдается тренировочная последовательность, например длинный список нулей. На приемном конце определяем частоту следования импульсов. По этому тренировочному пакету на приемном конце, местный процессор делает замер и определяет константу, затем инициализирует RS232 и прописывает в настройки эту константу. Тогда можно работать с RC генератором, и вообще на любой входной скорости RS232. Сам так никогда не делал, но сработать должно...

Благодарю, с разделом Automatic Baud-Rate Detection ознакомился поверхностно, по крайней мере судя по принципу он работает примерно так, как надо. В случае фиаско применения штатного Automatic Baud-Rate Detection можно написать программный модуль, который по прерыванию на ноге будет калиброваться по частоте, а именно замерять максимальную частоту в 1-5 пакетах, это и будет Baudrate / 2.



Не, не электросчетчик, RTC не нужен. Данные о времени и дате также берутся из обращения MASTERа к SLAVEу.

Я бы был рад получить хоть какие-то комментарии по поводу многочисленных (относительно) емкостей на ноги этого (и подобных) МК, дюже много, сократить емкость/кол-во никто не пробовал?.. Пока МК еще в посылке, через день-другой приедут, но плата еще не заказана, поэтому поэкспериментировать вживую получится "не скоро", через недели две.

Количество и емкость конденсаторов можно сократить (например, если вы не будете использовать переключение питаний от разных внешних входов питания AUX), но только, если вы хорошо понимаете функционал схемы питания МК.

Может поможет:
В нашем изделии тактовый генератор, также RC. Кварцевый применять нельзя было, из-за требований по вибростойкости.
Чтобы лучше уложить частоту тактового генератора в своём изделии поступил так. Подключил внешний резистор c допуском в 1%. 1000ппм. Сконфигурировал регистры тактового генератора на работу с внешним резистором. См приложенный файл схемы. После этого снял зависимость от температуры с этим резистором. И добавил фрагмент программы для компенсации.
Вот фрагмент кода для компенсации ухода тактового генератора. Если говорить в цифрах то погрешность от температуры укладывается в 2%, вне зависимости от партии контроллеров.

Добавлю, что
config.offset_temperature - это нормальные условия, при комнатной.
temperature - это код АЦП текущей температуры

[code]
void temper_clok_gen (void)
{toggle_rst;
int dt;
dt= temperature-config.offset_temperature;
dt=dt/100;
DCOCTL=DCOCTL&0xE0;
switch (dt)
{ case -2:DCOCTL|=MOD3+MOD2+MOD1; break;
case -1:DCOCTL|=MOD3+MOD2+MOD1+MOD0; break;
case 0: DCOCTL|= MOD4; break;
case 1: DCOCTL|= MOD4+MOD0; break;
case 2: DCOCTL|= MOD4+MOD1; break;
case 3: DCOCTL|= MOD4+MOD0+MOD1; break;
case 4: DCOCTL|= MOD4+MOD2; break;
case 5: DCOCTL|= MOD4+MOD2+MOD0; break;

default: {if (dt<-2) DCOCTL|= MOD0+MOD2+MOD3;
if (dt>5) DCOCTL|= MOD4+MOD2+MOD0+MOD1;
}
}
[code]