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

[vazz]

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

[d7d1cd]

А что за расширение файла .inc? Вот ты говоришь, что использовать PUBLIC, EXTERN и прочее - это захламление проекта. А числовые константы описывать как то так #b'01000000 это норма? Это первое. Второе: вставлять директиву include посреди кода - это со стороны смотрится... а точнее не смотрится вообще никак.
Ты уверен, что правильно указываешь вершину стека 0х23FE? У тебя адрес 0х23FE стеком занят не будет никогда. Про таблицу векторов прерываний: зачем вставляешь команду NOP? По поводу обработки немаскируемых прерываний: открываешь даташит на микроконтроллер и смотришь что может быть источником немаскируемого прерывания. Так же тебе надо изучить сигналы POR и PUC микроконтроллера.
Я думаю, что немаскируемое прерывание не может заканчиваться командой RETI. Ведь после этой команды процессор должен продолжить выполнение прерванного кода, но этот код (скорее всего) вызвал немаскируемое прерывание. В обработчике немаскируемого прерывания можно определить что вызвало его, в зависимости от этого (если надо) выполнить какой-то код (допустим сохранить данные в МС) и перезагрузить программу.

[vazz]

А что за расширение файла .inc?

Привычка с прошлых проектов на других МК (уже и не помню когда первый раз такое расширение применил и почему)

А числовые константы описывать как то так #b'01000000 это норма? Это первое.

Тут как бы согласен, сам я так никогда числа не писал, но в IAR -> Assembler User Guide указано следующее:

The following types of number representation are supported:

Integer type Example

Binary 1010b, b'1010
Octal 1234q, q'1234
Decimal 1234, -1, d'1234
Hexadecimal 0FFFFh, 0xFFFF, h'FFFF

Если из этих вариантов исключить привычное 0xFFFF, то для унификации применяеть суффикс системы исчисления либо в начале "<suf>'" либо в конце "XXXX<suf>". Но, к примеру если шестнадцатиричное число равно FFFF, то его надо записывать либо h'FFFF, либо 0FFFFh. Короче из-за добавления нуля ("ассоциируется" с заимствованием дополнительного байта, которого нет) мои рельсы съехали в сторону суффикса с апострофом. Короче это личный бзик в мозгу.

Второе: вставлять директиву include посреди кода - это со стороны смотрится... а точнее не смотрится вообще никак.

Хм... ну не знаю что лучше - перегружать основной файл проекта всякими векторами и данными о версии ПО или аккуратно вставить эти процедуры и данные в то место памяти, где им самое место... Без обид, на вкус и цвет как говорится.

Ты уверен, что правильно указываешь вершину стека 0х23FE? У тебя адрес 0х23FE стеком занят не будет никогда.

Это я понял, что одно слово между стеком и остальной памятью будет пустовать, пусть пока так, главное на этапе экспериментов то, что "не заползает ни на кого". Марафет вплоть до байта - позже, когда уверенно буду "рулить" этим камнем.

Про таблицу векторов прерываний: зачем вставляешь команду NOP?

Тоже пока затрудняюсь объяснить

По поводу обработки немаскируемых прерываний: открываешь даташит на микроконтроллер и смотришь что может быть источником немаскируемого прерывания.

Ты прав конечно.

Так же тебе надо изучить сигналы POR и PUC микроконтроллера.

И с системой сброса и с системой организации питания - первым делом, как без этого.

Я думаю, что немаскируемое прерывание не может заканчиваться командой RETI. Ведь после этой команды процессор должен продолжить выполнение прерванного кода, но этот код (скорее всего) вызвал немаскируемое прерывание.

Тут не уверен я. Думается, в стек при немаскируемом прерывании записывается адрес возврата, поэтому без RETI не обойтись. Покопаю про это поподробнее.

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

Эт да.. Самое приятное анализировать, когда азы уже прочно усвоены, а нубовские ошибки - редкое исключение. Скорее бы уже дойти до этого состояния)

[d7d1cd]

Тут не уверен я. Думается, в стек при немаскируемом прерывании записывается адрес возврата, поэтому без RETI не обойтись. Покопаю про это поподробнее.

Зачем тебе возвращаться из немаскируемого прерывания? Мне кажется тут один путь - начать выполнение программы с вектора сброса.

[vazz]

Мне кажется тут один путь - начать выполнение программы с вектора сброса.

Ну если возникновение немаскируемого прерывания свидетельствует ТОЛЬКО о каком-либо сбое в работе МК, причем этот сбой может привести к непредсказуемой работе (в т.ч. "зависанию"), то да - тут только возврат в исходную точку, начиная с начальных предустановок и пр. Но я ж пока не знаю все случаи когда возникает немаскируемое прерывание. Кстати, а почему немаскируемое? (стыдно конечно) Потому что оно возникает независимо от состояния бита глобального разрешения прерываний (GIE)?