СС430F5137 с нуля на asm, нужна помощь Опции

[vazz]

Приобрел EM430F5137RF900 и MSP-FET430UIF, до приобретения особо не заморачивался с подготовкой "рабочего пространства" под новый проект, вроде бы камни не особенно новые, часто встречал различную информацию о них и не думал, что доставабельностью нужной для начала разработки инфы возникнут проблемы. Пол дня поискал в сети примеры заголовочных файлов под этот камень, примеры инициализации периферии, увы - результат 0. Это такой секрет? Такие данные достаются потом и кровью? Раньше работал с AVR (да и продолжаю время от времени), никаких таких проблем не помню, все было как-то проще достать и среда разработки нормальная (и бесплатная). Бог с ней со средой, поставил IAR KS на 4кБ кода (мне для попробовать). С самим ассемблером MSP и системой команд ознакомился поверхностно, страха не вызвал, вроде бы все просто (по крайней мере помигать светодиодом для начала - понятно как, а особенности и "камни" по ходу дела разберу). Стандартный заголовочный файл, который есть в папке иара "\inc" при пустом проекте вызывает негодование у компилятора IAR (дублирование лэйблов в объявлении регистров DMA). Попытался найти нормальный заголовочный файл в сети - нашел лишь такой же, "замазал" все места вызывающие негатив комментариями, чтобы не было ошибок. Далее попытался найти файл, который инициализировал бы мне всю периферию - тут все и загнулось. Я понимаю, что скорее всего при запуске МК все отключает сам и морганию светодиодом врядли что-то помешает, но хотелось бы иметь заготовку с полной инициализацией всех узлов МК ну и ессно полную таблицу векторов прерываний воткнуть в начало. Это добавляет уверенности в дальнейшем освоении камня. В отладчике иара тож пока особо не разобрался, если честно с первого раза иар вроде показался "классическим" средством разработки с простым и понятным интерфейсом, как начал лезть глубже - начало казаться, что первое впечатление обманчиво, чувство "чего-то не хватает" не покидает - ну к примеру как мне для отладчика задать тип МК, частоту кварца (чтоб время выполения отслеживать), также не нашел средства для заливки прошивки в МК (нужно отдельным ПО для этого ввоспользоваться чтоли?!). Прошу извинить за смешивание всего в кучу - помогите найти (или разобраться) с заголовочный файл для ассемблера под этот МК, файл инициализации всех устройств на борту, ну и вектора прерываний до кучи. На Си для МК не программирую и не особо горю желанием.

[d7d1cd]

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

[vazz]

Чтобы потом, если я вдруг ошибусь ..., компилятор поругал меня за это.

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

Код

#define var1_ (0х09FE)                  //объявляем переменную var1
DEFCW(var1,var1_)

[d7d1cd]

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

Код

#define var1_ (0х09FE)                  //объявляем переменную var1
DEFCW(var1,var1_)

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

Код

// var1 - это у нас массив 5-ти однобайтных чисел
MOV.B   #5, &var1     // Запись байта в первый элемент массива. Тут все отлично!
MOV.W   #5, &var1     // Запись слова в первый элемент массива. Тут компилятор говорит об ошибке. Все как надо!
MOV.B   #5, &var1 + 1     // Запись байта во второй элемент массива. И вот тут предупреждение

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

[vazz]

Как только сделать то, что хочется?...

Я не крутой программер (я больше схемотехник), поэтому я пораскинул тем скудным багажом опыта, который приобрел и ничего лучше в голову не пришло, как применить индексный режим адресации. Т.е. в одном из регистров ЦПУ хранишь начальный адрес своего 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

[rezident]

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

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

Я вот как думаю (и если я недальновидно думаю, то очень прошу меня поправить на начальном этапе):

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

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

[vazz]

сразу продумать и выделить HAL (Hardware Application Level), а также предусмотреть возможность реинициализации всех модулей.

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