[vazz 0]

и будешь вызывать оттуда функции. А ты попробуй так сделать. Я попытался. Ничего не получилось. Проведи эксперимент и отпишись.

 

Я провел эксперимент. Итак в основном файле проекта следующий код:

 

; +---------------------------------------------------------------------------+
; |                                                                           |
; |                  Проект: <?> ПП: <?> МК: <?> F= <?> МГц                   |
; |                  Версия: <?> Дата: <?> Пред.версия: <?>                   |
; |                              Примечания: <?>                              |
; |                                Права: <?>                                 |
; |                                                                           |
; +---------------------------------------------------------------------------+
#include "msp430.h"                    ; файл описание камня
#include "cc430f5137_INT.inc"          ; файл с векторами прерываний
        ORG     h'E000                 ; начало ПЗУ
#include "user_SIGN.inc"               ; файл с версией ПО
#include "user_DATA.inc"               ; файл с константами пользователя
#include "user_INTP.inc"               ; файл с подпрограммами прерываний
#include "user_SUBP.inc"               ; файл с подпрограммами пользователя
init:
        DINT                           ; запрещаем прерывания
        MOV.W   #WDTPW+WDTHOLD,&WDTCTL ; останавливаем сторожевой таймер
        MOV     #h'23FE, SP            ; установка стэка (и для CC430F5133)
#include "cc430f5137_INIT.inc"         ; файл с инициализацией периферии
main:                                  ; начало основного цикла программы
;
        CLR.B   P1SEL                  ; конфигурируем порт 1
        MOV.B   #h'FF,P1DIR
        CLR.B   P1OUT
        CLR.B   P3SEL                  ; конфигурируем порт 2
        MOV.B   #h'FF,P3DIR
        CLR.B   P3OUT
loop1:
        call    #led_flash
        JMP     loop1
;
        JMP     main                   ; зацикливаем
        NOP
        END

 

В файле user_SUBP.inc код:

 

led_flash:
        MOV.B     #d'0,P1OUT
        MOV.B     #b'01000000,P3OUT
        MOV.B     #b'00000001,P1OUT
        MOV.B     #d'0,P3OUT
        RET

 

При пошаговой отладке (либо кнопкой Step Into либо Autostep) светодиоды моргают.

 

Содержимое файла векторов прерываний и файла самих подпрограмм, обрабатывающих прерывания думаю приводить не особо нужно. Кстати в файле user_INTP.inc метка, после которой идет команда:

 

; +---------------------------------------------------------------------------+
; |                вектор по сбросу (reset) - на инициализацию                |
; +---------------------------------------------------------------------------+
int_reset:
        NOP
        jmp     init

 

Так вот метка init присутствует в основном файле и при отладке все переходы идут без каких-либо Сишных наворотов типа PUBLIC и пр. Я не говорю, что подобный код будет работать во всех ситуациях, я в силу начала освоения MSP о таких ситуациях могу не знать. НО, очень хочется верить, что код не нужно будет захламлять C-style директивами в будущем. А как оформить подпрограммы и организовать "блочную" структуру каждый программист и сам в состоянии решить без лишней "видимости/невидимости" (по крайней мере мне лично так спокойней, когда я контролирую то, что пишу).

 

У МЕНЯ ЕЩЕ ВОПРОС)) Он как раз близок к тому, что описано выше, поэтому надеюсь получить еще один бесплатный опытный совет :) Вопрос касается немаскируемых прерываний, которые как я понял в семействе MSP430x5xxx в отличие от своих предшественников разделены на два индивидуальных обработчика таких прерываний - системный и пользовательский. Выше я привел фрагмент обработчика (пустого пока) прерывания RESET, далее я ставлю следующий код:

 

; +---------------------------------------------------------------------------+
; |                 вектор системных немаскируемых прерываний                 |
; +---------------------------------------------------------------------------+
int_nmi_sys:
        NOP
        RETI
; +---------------------------------------------------------------------------+
; |              вектор пользовательских немаскируемых прерываний             |
; +---------------------------------------------------------------------------+
int_nmi_user:
        NOP
        RETI
...

 

Верно ли я делаю, ставя после прерывания RESET команду перехода на метку init, а после немаскируемых прерываний - выход из прерывания "RETI"? Как я понял немаскируемые прерывания свидетельствуют об ошибках, таких как сбой генерации или, к примеру, ошибка при работе контроллера DMA? Это системные, а пользовательские какие ошибки сопровождают? (блин, целых два вопроса сразу, сорри)

 

С наступающим, кстати!

 

Спасибо! И тебя! И всех MSP-водов тоже))

[d7d1cd 0]

А что за расширение файла .inc? Вот ты говоришь, что использовать PUBLIC, EXTERN и прочее - это захламление проекта. А числовые константы описывать как то так #b'01000000 это норма? Это первое. Второе: вставлять директиву include посреди кода - это со стороны смотрится... а точнее не смотрится вообще никак.

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

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

[vazz 0]

А что за расширение файла .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 0]

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

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

[vazz 0]

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

 

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

[d7d1cd 0]

Кстати, а почему немаскируемое? (стыдно конечно) Потому что оно возникает независимо от состояния бита глобального разрешения прерываний (GIE)?

Совершенно верно.

[SM 0]

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

 

include придуманы для подключения файлов с описанием символьных констант, и т.п., необходимого на этапе компиляции. А для подключения файлов с полноценным кодом/данными - придуман редактор связей (линкер), и те самые public/extern - показывающие линкеру, что метка определена снаружи объектного модуля, и что определена внутри, но должна быть видимой снаружи.

при использовании include - компилятор компилирует КАЖДЫЙ РАЗ все полностью, что вы там наинклудили. А линковка - компилирует только измененный файл, а те, в которых изменений не было, не перекомпилирует. поэтому написание функций в разных файлах, объявление public/extern и сборка редактором связей предпочтительнее, чем включение кучи файлов по include в один файл "верхнего уровня". И, кстати, от исходного языка, С это, или АСМ, это не зависит. Делаете каждому файлу свой объектный модуль, и собираете их в единое целое линкером.

 

И, кстати, это, примерно так для любых архитектур, public/extern и связывание таким образом объявленных меток линкером. А не только MSP430. Как только Вы делаете два файла с кодом/данными, которые компилируются ПО ОТДЕЛЬНОСТИ, а не связаны через include, так сразу нужны объявления public/extern.

[vazz 0]

public/extern - показывающие линкеру, что метка определена снаружи объектного модуля, и что определена внутри, но должна быть видимой снаружи.

 

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

 

Оффтоп: при программировании на ассемблере для нескольких 8-битных МК я ни разу не встречался с чем-то подобным, поэтому мне было трудно понять эту "фишку". Теперь (надеюсь) с этим все ясно, у кого есть желание применять подобный стиль - его право. Я предпочту все таки не мутить воду и располагать всем адресным пространством без каких-либо ширм и перегородок.

[d7d1cd 0]

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

 

Оффтоп: при программировании на ассемблере для нескольких 8-битных МК я ни разу не встречался с чем-то подобным, поэтому мне было трудно понять эту "фишку". Теперь (надеюсь) с этим все ясно, у кого есть желание применять подобный стиль - его право. Я предпочту все таки не мутить воду и располагать всем адресным пространством без каких-либо ширм и перегородок.

Линкер имеет отношение к любому коду. Поверь. А пользоваться или не пользоваться возможностями EXTERN и PUBLIC - это твое дело...

[SM 0]

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

 

Линкер к "объектному программированию" отношения никакого не имеет вообще !!! (Вы что вообще имели в виду то? нет такого понятия на самом деле, есть "объектно-ориентированное", но линкер и к нему непосредственного отношение не имеет).

 

Линкер имеет отношение к формированию АБСОЛЮТНО ЛЮБОГО кода, который загружается непосредственно внутрь МК из кода, сгенерированного транслятором ассемблера (или компилятором языка высокого уровня). Транслятор ассемблера преобразует текстовый файл с мнемониками инструкций в объектный модуль (расширение .R43, если я не ошибаюсь, в MSP430, а вообще бывает обычно .obj, .o). Далее, линкер (редактор связей) объединяет один или более таких модулей, и формирует на выходе файл, который может быть загружен в МК (для MSP430, если не ошибаюсь, принято расширение такого файла .D43). Без, так сказать, услуг линкера НЕТ СПОСОБА получить файл, который можно загрузить в МК! Хоть из одного исходника, хоть из нескольких. Если же Вы такой, с позволения сказать "фанат" ассемблера, давно бы пора разобраться, как, и при помощи каких шагов, из этих самых мнемоник ассемблера получается выходной код, готовый к загрузке в МК!

 

Так вот, еще раз, для находящихся в танке. public/extern - это механизм указания линкеру, как связать несколько объектных модулей, каждый из который сгенерирвоан транслятором ассемблера из своего исходного текста, в единое целое - загружаемый в МК модуль. А использование include вместо отдельной трансляции файлов с последующей линковкой - это, как минимум, плод полного незнания процесса формирования кода из исходных файлов. И этот механизм един практически для любой архитектуры любой разрядности. Пожалуй, единственный вариант, когда загружаемый код генерировался сразу транслятором ассемблера без линкера, это древние трансляторы начального уровня для i8080 (КР580ВМ80) и Z-80, которые и работали на этих же платформах, где не было накопителей, кроме магнитной ленты... Сейчас такой архаизм забыт, и забыт, скорее всего, навсегда.

[vazz 0]

По мере разбирательства пытаюсь читать CC430 Users Guide и описания конкретных моделей МК. Вот добрался до системы тактирования, и появилось пара вопросов:

 

В Users Guide про режим LPM0 сказано:

 

CPU, MCLK are disabled.

ACLK is active. SMCLK optionally active (SMCLKOFF = 0).

DCO is enabled if sources ACLK or SMCLK (SMCLKOFF = 0).

DCO bias is enabled if DCO is enabled or DCO sources MCLK or SMCLK

(SMCLKOFF = 0).

 

Про MCLK в упоминании про DCO это просто опечатка? Вместо него там должно быть ACLK?

 

Вопрос 2:

 

Что вообще такое DCO bias? Где это смещение описано, не могу вкурить..

 

Вопрос №3:

 

В Users Guide про режимы LPM2 и LPM3:

 

LPM2

 

CPU, MCLK are disabled.

ACLK is active. SMCLK is disabled.

DCO is enabled if sources ACLK.

FLL is disabled.

 

LPM3

 

CPU, MCLK are disabled.

ACLK is active. SMCLK is disabled.

DCO is enabled if sources ACLK.

FLL is disabled.

 

В Datasheet:

 

LPM2

 

CPU is disabled

MCLK and FLL loop control and DCOCLK are disabled

DCO's dc-generator remains enabled

ACLK remains active

 

LPM3

 

CPU is disabled

MCLK, FLL loop control, and DCOCLK are disabled

DCO's dc-generator is disabled

ACLK remains active

 

Догадываюсь - верить надо Datasheet?

[rezident 0]

Про MCLK в упоминании про DCO это просто опечатка? Вместо него там должно быть ACLK?

Почему опечатка? В режиме LPM0 отключено только тактирование ядра. Ядро всегда от MCLK тактируется.

Вопрос 2:

 

Что вообще такое DCO bias? Где это смещение описано, не могу вкурить..

DCO это встроенный RC-генератор. DCO bias это истоник тока, "изображающий" из себя R через которое заряжается C.

Вопрос №3:

 

В Users Guide про режимы LPM2 и LPM3:

 

В Datasheet:

 

Догадываюсь - верить надо Datasheet?

В процитированном нет противоречий. "DCO is enabled if sources ACLK." переводится как "Работа DCO разрешена, если он является источником сигнала для ACLK."

У MSP430 три внутренних тактовых сигнала: MCLK, SMCLK и ACLK. M(ain)CLK тактирует ядро и некоторую часть периферии. S(ub)M(ain)CLK и ACLK могут тактировать периферию. SMCLK обычно более высокочастотный сигнал, чем ACLK, т.к. для ACLK типично используется выходной сигнал часового генератора 32кГц.

В свою очередь генераторами/источниками сигналов для всех трех CLK могут быть НЧ и/или ВЧ генераторы XT1/LFXT, XT2 и/или DCO и/или FLL и/или другой внешний тактовый сигнал. Подробности см. в User's Guide.

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

[vazz 0]

Почему опечатка? В режиме LPM0 отключено только тактирование ядра. Ядро всегда от MCLK тактируется.

 

Не, я имел в виду то, что в LPM0 тактовый источник MCLK отключен, а далее пишется, что DCO задействуется, если является задающим для MCLK. Мне показалось это бессмыслицей.

 

DCO это встроенный RC-генератор. DCO bias это истоник тока, "изображающий" из себя R через которое заряжается C.

 

Вот спасибо, теперь про DCO bias стало не так страшно читать, смысл уловил.

 

За остальные пояснения тоже мэни сэнкс.

 

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

 

Оффтоп: это с одной стороны радует (что у CORTEX попроще система тактирования), потому как LPC1788 на отладочной плате и программатор к нему лежат недалеко и мне необходимо и их освоить, т.к. проект требует совместного применения CC430 (в качестве элементов сети) и CORTEX-M3 + CC1101 (в качестве ведущего HOSTа), а с другой стороны является давящим напоминанием о необходимости освоения ARM.

 

Вычитал в Datasheet, что мин.потребляемый ток модуля RF1A в спящем режиме это 100мкА, это так? Больше никаких сведений о потреблении в спящих режимах не вижу, при этом в Datasheet на CC1101 есть данные о потреблении в спящем режиме и 35мкА и 0,5мкА.

Изменено 2 января, 2014 пользователем vazz

[rezident 0]

Не, я имел в виду то, что в LPM0 тактовый источник MCLK отключен, а далее пишется, что DCO задействуется, если является задающим для MCLK. Мне показалось это бессмыслицей.

Процитированное вами предолжение является сложноподчиненным "DCO bias is enabled if DCO is enabled or DCO sources MCLK or SMCLK" -> DCO bias задействован, если задействован сам DCO или генератор DCO является источником тактового сигнала для MCLK или SMCLK.

Вновь я не наблюдаю противоречий.

Вычитал в Datasheet, что мин.потребляемый ток модуля RF1A в спящем режиме это 100мкА, это так? Больше никаких сведений о потреблении в спящих режимах не вижу, при этом в Datasheet на CC1101 есть данные о потреблении в спящем режиме и 35мкА и 0,5мкА.

Спящий режим спящему режиму рознь. Потребление зависит от многих факторов - в частности от того а) какая именно периферия включена и б) с какой скважностью и на какое время ядро просыпается, чтобы программа могла "оценить" свое собственное и окружающее состояние. Лень заглядывать в даташит незнакомого модуля, но предполагаю, что при 100мкА у него приемная часть включена и пассивно бдит за эфиром, а при 0,5мкА у модуля спит все, что только можно, и лишь только одни часы "тикают".

[vazz 0]

IAR почему-то ругается на команду CMP.B по отношению к регистру SYSRSTIV. Как я понял пространство под этот регистр в памяти - это 1 байт. Или все таки слово? И если он читается как слово, то старший байт при этом всегда равен 0x00?

 

Этот вопрос снят, прошу извинить, криво прочиатал Users Guide. Ответ: под регистр выделено слово в памяти.

Изменено 3 января, 2014 пользователем vazz