vazz 0 23 февраля, 2013 Опубликовано 23 февраля, 2013 · Жалоба Приобрел EM430F5137RF900 и MSP-FET430UIF, до приобретения особо не заморачивался с подготовкой "рабочего пространства" под новый проект, вроде бы камни не особенно новые, часто встречал различную информацию о них и не думал, что доставабельностью нужной для начала разработки инфы возникнут проблемы. Пол дня поискал в сети примеры заголовочных файлов под этот камень, примеры инициализации периферии, увы - результат 0. Это такой секрет? Такие данные достаются потом и кровью? Раньше работал с AVR (да и продолжаю время от времени), никаких таких проблем не помню, все было как-то проще достать и среда разработки нормальная (и бесплатная). Бог с ней со средой, поставил IAR KS на 4кБ кода (мне для попробовать). С самим ассемблером MSP и системой команд ознакомился поверхностно, страха не вызвал, вроде бы все просто (по крайней мере помигать светодиодом для начала - понятно как, а особенности и "камни" по ходу дела разберу). Стандартный заголовочный файл, который есть в папке иара "\inc" при пустом проекте вызывает негодование у компилятора IAR (дублирование лэйблов в объявлении регистров DMA). Попытался найти нормальный заголовочный файл в сети - нашел лишь такой же, "замазал" все места вызывающие негатив комментариями, чтобы не было ошибок. Далее попытался найти файл, который инициализировал бы мне всю периферию - тут все и загнулось. Я понимаю, что скорее всего при запуске МК все отключает сам и морганию светодиодом врядли что-то помешает, но хотелось бы иметь заготовку с полной инициализацией всех узлов МК ну и ессно полную таблицу векторов прерываний воткнуть в начало. Это добавляет уверенности в дальнейшем освоении камня. В отладчике иара тож пока особо не разобрался, если честно с первого раза иар вроде показался "классическим" средством разработки с простым и понятным интерфейсом, как начал лезть глубже - начало казаться, что первое впечатление обманчиво, чувство "чего-то не хватает" не покидает - ну к примеру как мне для отладчика задать тип МК, частоту кварца (чтоб время выполения отслеживать), также не нашел средства для заливки прошивки в МК (нужно отдельным ПО для этого ввоспользоваться чтоли?!). Прошу извинить за смешивание всего в кучу - помогите найти (или разобраться) с заголовочный файл для ассемблера под этот МК, файл инициализации всех устройств на борту, ну и вектора прерываний до кучи. На Си для МК не программирую и не особо горю желанием. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 23 февраля, 2013 Опубликовано 23 февраля, 2013 · Жалоба Стандартный заголовочный файл, который есть в папке иара "\inc" при пустом проекте вызывает негодование у компилятора IAR (дублирование лэйблов в объявлении регистров DMA). Попытался найти нормальный заголовочный файл в сети - нашел лишь такой же, "замазал" все места вызывающие негатив комментариями, чтобы не было ошибок. Хедер cc430f5137.h из папки 430\inc\ не вызывает никаких негодований. Далее попытался найти файл, который инициализировал бы мне всю периферию - тут все и загнулось. Я понимаю, что скорее всего при запуске МК все отключает сам и морганию светодиодом врядли что-то помешает, но хотелось бы иметь заготовку с полной инициализацией всех узлов МК ну и ессно полную таблицу векторов прерываний воткнуть в начало. Я не знаю, каким именно предыдущим опытом вы так "развращены", но придется огорчить вас - в IAR нет встроенных средств для подготовки шаблона полной инициализации периферии. Можно использовать какие-то примеры, но полную инициализацию периферийных модулей вам придется писать самому - ручками. В IAR есть лишь этакий минивизард, который создает шаблон типа такого. #include "msp430.h" ; #define controlled include file NAME main ; module name PUBLIC main ; make the main label vissible ; outside this module ORG 0FFFEh DC16 init ; set reset vector to 'init' label RSEG CSTACK ; pre-declaration of segment RSEG CODE ; place program in 'CODE' segment init: MOV #SFE(CSTACK), SP ; set up stack main: NOP ; main program MOV.W #WDTPW+WDTHOLD,&WDTCTL ; Stop watchdog timer JMP $ ; jump to current location '$' ; (endless loop) END ну к примеру как мне для отладчика задать тип МК,В опциях проекта задается. Project->Options->General Options->Target->Device в выпадающем списке выбираете CC430F5137. частоту кварца (чтоб время выполения отслеживать),В отладчике можно вывести окно Register, где отображаются CYCLECOUNTER и CCSTEP. Поделите их значение на частоту тактирования ядра (величина тактового сигнала MCLK) и вы получите время выполнения. также не нашел средства для заливки прошивки в МК (нужно отдельным ПО для этого ввоспользоваться чтоли?!).Опять же в опциях проекта нужно выбрать соответствующий эмулятор. Во-первых, нужно установить режим отладки, а не симуляции Project->Options->Debugger->Setup->FET Debugger. Во-вторых, выбрать его тип Project->Options->Debugger->FET Debugger->Setup->Texas Instrument USB-IF. Вообще, хочется пожелать вам много терпения для изучении документации, которую вы можете найти на страничке продукта. http://www.ti.com/product/cc430f5137 В первую очередь вам понадобится User's Guide в котором описаны все, что есть общего в МК серии СС430. Конкретные же особенности данного кристалла (CC430F5137) вам следует уточнять в его datasheet. На той же страничке продукта есть дополнительные материалы по применению - Application Notes. Про IAR читайте в его собственных документах. Help->ну и там соответствующий Guide. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 28 декабря, 2013 Опубликовано 28 декабря, 2013 (изменено) · Жалоба Благодарю за напутственные пояснения, наконец-то появилось время вернуться к изучению данного вопроса. Значит подключил я отладчик к ПК и к таргету. Создал "пустой" проект на ассемблере. Узнал о том, что сторожевой таймер по умолчанию у MSP всегда включен - IAR сформировал начальный кусок кода с его отключением. Отлично, дополнительно я запретил все прерывания (на всякий случай) и принялся моргать светодиодом. Сходу получилось, я был рад, но потом начал разбираться в организации памяти этого камня и наткнулся на пока необъяснимую для меня (чайника) вещь. Я моргаю светодиодом с помощью начальной установки пина 0 порта 1 на вывод командой "BIS.W 0x0001,PADIR", затем собственно моргаю командами "BIS.W 0x0001,PAOUT" и "BIC.W 0x0001,PAOUT". При изменении кода на начальную установку командой "BIS.B 0x01,P1DIR" с морганием командами "BIS.B 0x01,P1OUT" и "BIC.B 0x01,P1OUT" иар благополучно запускает отладчик, но моргания не происходит. Почему? (прошу извинить за нубовские вопросы, но, как вы и сами знаете при начале освоения новой архитектуры бывают мелкие запинки, которые кажутся непреодолимыми стенами). Честно говоря моргание не исчезает, почему то данные, которые я отправляю в порт не соответствуют реальным на плате таргета. Записываю 0x40 - получаю 0xFF. Эээ.. что-то я недочитал видимо.. DINT BIS.B 0xFF,P1DIR CLR.B P1OUT loop1: MOV.B 0x00,P1OUT MOV.B 0x01,P1OUT JMP loop1 Записываю в порт 0x00 - получаю 0x31. Записываю в порт 0x02 - получаю 0xFE. Что я делаю не так, Help! Моргание получилось, ура, пока вслепую применил увиденный принцип записи (моргаю аж двумя светодиодами поочереди): DINT CLR.B P1SEL ; configure Port 1 MOV.B #0FFh,&P1DIR CLR.B P1OUT CLR.B P3SEL ; configure Port 3 MOV.B #0FFh,&P3DIR CLR.B P3OUT loop1: MOV.B #00h,&P1OUT MOV.B #40h,&P3OUT MOV.B #01h,&P1OUT MOV.B #00h,&P3OUT JMP loop1 Пока не понял как влияют символы "#" и "&", но они позволяют корректно передавать данные регистрам. Кстати, к примеру, запись числа в виде "#FFh" не катит, правильно будет "#0FFh" - этой фишки тоже пока не понял. Видимо все это особенности ассемблера. Изменено 28 декабря, 2013 пользователем vazz Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 28 декабря, 2013 Опубликовано 28 декабря, 2013 · Жалоба "#" - непосредственный операнд, если значение начинается с hex-буквы, то надо ноль спереди. "&" - работа с переменной в памяти (или портом, которые тоже в памяти), адрес которой указан после этого символа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 28 декабря, 2013 Опубликовано 28 декабря, 2013 · Жалоба А правда то, что ограничение 4кБ IAR Kickstart относится только к программам на Си? Если пишешь на ассемблере, то ограничений вообще никаких нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
d7d1cd 0 28 декабря, 2013 Опубликовано 28 декабря, 2013 · Жалоба А правда то, что ограничение 4кБ IAR Kickstart относится только к программам на Си? Если пишешь на ассемблере, то ограничений вообще никаких нет? Вроде бы как да... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 29 декабря, 2013 Опубликовано 29 декабря, 2013 · Жалоба Почитал о режимах адресации, впринципе все понятно кроме одного: в чем принципиальная разница между символьной и абсолютной адресацией? Ну, к примеру, команды "MOV.B #00h,P3OUT" и "MOV.B #00h,&P3OUT" в результате дают одно и тоже. Единственное "преимущество" абсолюной адресации это гарантия переносимости программы с камня на камень. По-моему, можно на это забить по началу и пользоваться символьной адресацией без перегружения кода закорючками "&". Есть у профи мнения на этот счет? Или при обращении к конкретной периферии лучше изначально пользоваться абсолютной адресацией? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
d7d1cd 0 29 декабря, 2013 Опубликовано 29 декабря, 2013 (изменено) · Жалоба Почитал о режимах адресации, впринципе все понятно кроме одного: в чем принципиальная разница между символьной и абсолютной адресацией? Ну, к примеру, команды "MOV.B #00h,P3OUT" и "MOV.B #00h,&P3OUT" в результате дают одно и тоже. Единственное "преимущество" абсолюной адресации это гарантия переносимости программы с камня на камень. По-моему, можно на это забить по началу и пользоваться символьной адресацией без перегружения кода закорючками "&". Есть у профи мнения на этот счет? Или при обращении к конкретной периферии лучше изначально пользоваться абсолютной адресацией? Задавал я уже такой вопрос. Почитай: здесь. В принципе разницы нет, но при определенных условиях может быть выигрыш в размере кода. Изменено 29 декабря, 2013 пользователем d7d1cd Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 29 декабря, 2013 Опубликовано 29 декабря, 2013 · Жалоба Вроде бы как да... Я пока усмиряю тягу узнать все и сразу про эти MSP, поэтому не проверял. Вы случайно/специально не проверяли сей момент (на счет >4кБ ассемблерного кода)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
d7d1cd 0 29 декабря, 2013 Опубликовано 29 декабря, 2013 · Жалоба Я пока усмиряю тягу узнать все и сразу про эти MSP, поэтому не проверял. Вы случайно/специально не проверяли сей момент (на счет >4кБ ассемблерного кода)? Не проверял. Мои программы пока меньше 4 кБ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 30 декабря, 2013 Опубликовано 30 декабря, 2013 · Жалоба Не могу найти/понять информацию про стек. Вершина ОЗУ находится по адресу 0x1AFF. Когда я записываю в SP адрес, то я должен, к примеру, указать адрес 0x1AFF или младший байт слова по четному адресу 0x1AFE? И если кому не трудно, то дайте ссылку, где это регламентируется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 30 декабря, 2013 Опубликовано 30 декабря, 2013 · Жалоба А еще непонятны примочки ассемблера типа "NAME main" и "PUBLIC main", что-то Сишным духом больно пахнут. Это вообще обязательно? Без указания PUBLIC тело основного цикла main не будет "видно" остальному коду? И обязательно ли его (main) объявлять с помощью NAME? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
d7d1cd 0 31 декабря, 2013 Опубликовано 31 декабря, 2013 · Жалоба Не могу найти/понять информацию про стек. Вершина ОЗУ находится по адресу 0x1AFF. Когда я записываю в SP адрес, то я должен, к примеру, указать адрес 0x1AFF или младший байт слова по четному адресу 0x1AFE? И если кому не трудно, то дайте ссылку, где это регламентируется. Вершина стека (регистр SP) всегда должна иметь четный адрес. Если ты укажешь 0x1AFF - это будет не правильно, так как ты указываешь нечетный адрес. Если ты укажешь 0x1AFE, то это будет правильно, но слово (2 байта) по адресу 0x1AFE никогда стеком занято не будет. Алгоритм "работы" стека, например при вызове функции, такой: 1. Из вершины стека вычитается 2 (SP = SP - 2); 2. По адресу, указанному в вершине стека, записывается адрес возврата. При выходе из стека происходит все наоборот: 1. По адресу, указанному в вершине стека, читается адрес возврата; 2. К вершине стека прибавляется 2 (SP = SP + 2). Даже если ты помещаешь в стек один байт (PUSH.B R15), то все равно вершина стека изменяется на 2. А еще непонятны примочки ассемблера типа "NAME main" и "PUBLIC main", что-то Сишным духом больно пахнут. Это вообще обязательно? Без указания PUBLIC тело основного цикла main не будет "видно" остальному коду? И обязательно ли его (main) объявлять с помощью NAME? Первое. PUBLIC main означает то, что функция main является публичной, то есть должна быть видна в другом модуле. В моем проекте 2 ассемблерных файла. Первый главный. В нем сделан основной цикл программы. В этом цикле выполняются функции, которые реализованы во втором файле. Так вот во втором файле помимо реализации тела функции (например функция Copying), есть строка PUBLIC Copying. А в первом файле есть строка EXTERN Copying, которая означает, что функция Copying является внешней. Второе. NAME main - это имя модуля. Никакого отношения к функции main NAME не имеет. После NAME можно написать что-то другое (дать другое имя модулю). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vazz 0 31 декабря, 2013 Опубликовано 31 декабря, 2013 · Жалоба Первое. PUBLIC main означает то, что функция main является публичной, то есть должна быть видна в другом модуле. В моем проекте 2 ассемблерных файла. Первый главный. В нем сделан основной цикл программы. В этом цикле выполняются функции, которые реализованы во втором файле. Так вот во втором файле помимо реализации тела функции (например функция Copying), есть строка PUBLIC Copying. А в первом файле есть строка EXTERN Copying, которая означает, что функция Copying является внешней. Второе. NAME main - это имя модуля. Никакого отношения к функции main NAME не имеет. После NAME можно написать что-то другое (дать другое имя модулю). Про стек большое спасибо за пояснения! По поводу директив ассемблера, которых в IAR в избытке - у меня создается четкое ощущение, что мне навязывают некую "полезную" с точки зрения IAR модель программирования. Я, как неприемлющий языки высокого уровня в системах где память измеряется в кБ, не могу пока этого понять (на языке высокого уровня я пишу ПО верхнего уровня под Win, Я НЕ ПРОТИВНИК Си, а даже наоборот). "Видимость" блока памяти для меня вообще непонятная вещь. У меня есть набор команд (MSP), которые позволяют работать с любой ячейкой памяти 64кБ без исключения, что значит "видимость/невидимость"? Блин, помогите как-то уложить это в голове. Это конкретно IAR так нагибает разработчиков даже в ассемблерном коде использовать приблуды "видимости", "декларирования"? Ну к примеру, у меня есть самый простой кусок кода, который выдает IAR в начале создания проекта. Я убираю оттуда директивы NAME, PUBLIC и прочую "чушь" (может и не чушь, я просто пока понять этого не могу). Между концом основного цикла main и директивой END (конец программы) добавляю инструкцию #include <file>, в file размещаю свои подпрограммы, которые хочу вызывать как из цикла main, так и из подпрограмм прерываний (таблицу векторов будем счиать добавленной в проект и подпрограммы тоже). Так вот без всяких приблуд типа PUBLIC, EXTERN я не смогу вызывать подпрограммы из цикла main и прерываний? Да наступит просветление! Иначе дальше не получается двигаться.. Попробовал почитать в IAR "Help -> Assebler User Guide", но что-то как-то вобщем......( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
d7d1cd 0 31 декабря, 2013 Опубликовано 31 декабря, 2013 · Жалоба Про стек большое спасибо за пояснения! По поводу директив ассемблера, которых в IAR в избытке - у меня создается четкое ощущение, что мне навязывают некую "полезную" с точки зрения IAR модель программирования. Я, как неприемлющий языки высокого уровня в системах где память измеряется в кБ, не могу пока этого понять (на языке высокого уровня я пишу ПО верхнего уровня под Win, Я НЕ ПРОТИВНИК Си, а даже наоборот). "Видимость" блока памяти для меня вообще непонятная вещь. У меня есть набор команд (MSP), которые позволяют работать с любой ячейкой памяти 64кБ без исключения, что значит "видимость/невидимость"? Блин, помогите как-то уложить это в голове. Это конкретно IAR так нагибает разработчиков даже в ассемблерном коде использовать приблуды "видимости", "декларирования"? Ну к примеру, у меня есть самый простой кусок кода, который выдает IAR в начале создания проекта. Я убираю оттуда директивы NAME, PUBLIC и прочую "чушь" (может и не чушь, я просто пока понять этого не могу). Между концом основного цикла main и директивой END (конец программы) добавляю инструкцию #include <file>, в file размещаю свои подпрограммы, которые хочу вызывать как из цикла main, так и из подпрограмм прерываний (таблицу векторов будем счиать добавленной в проект и подпрограммы тоже). Так вот без всяких приблуд типа PUBLIC, EXTERN я не смогу вызывать подпрограммы из цикла main и прерываний? Да наступит просветление! Иначе дальше не получается двигаться.. Попробовал почитать в IAR "Help -> Assebler User Guide", но что-то как-то вобщем......( Сразу хочу дать совет: не пытайся понять все и сразу. Это просто невозможно. Все приходит постепенно. Итак, "чушь". Если IAR вставляет какие-то директивы, значит они нужны. Если ты их убираешь и все работает, то значит конкретно сейчас они могут быть убраны, а в другой какой-то ситуации тебе просто необходимо будет их использовать. Согласись, по кой хрен разработчикам компилятора для ассемблера придумывать в нем что-то "ненужное". По поводу "видимости\невидимости". Эти директивы придуманы для упрощения жизни программиста, а не для его "нагибания". Проект на ассемблере может быть очень большой и запутаться там можно только в путь. Ты говоришь, что создашь отдельные файлы со своими функциями, добавишь этот файл директивой include и будешь вызывать оттуда функции. А ты попробуй так сделать. Я попытался. Ничего не получилось. Проведи эксперимент и отпишись. С наступающим, кстати! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
