About vectored interrupts.

Steven,

because you didn't mention it, i am assuming that you are using CCSTUDIO or IAR EWB. Basically the answer is yes, you need to put the #pragma vector directive before any ISR. The name of the vectors are defined basically in the header file of the MSP430 devices, so you shall not change it to other name. By defining this directive, the compiler will also put the address of the ISR function in the Interrupt vector table (located at the end of the 64K MSP430 memory)

For more explanation, you can try to look at the CCSTUDIO MSP430 compiler manual chapter 5.9.16.

I hope this helps.

Steven Gan Teck Yik said:

May I ask what is #pragma vector = TIMERA0_VECTOR?

A #pragma in general is a compiler specific instruction that tells teh compiler to do certain things. The pragma 'vector' tells the compiler that the next symbols (usually an interupt function) address is to be placed at the given (named) position in the interrupt vector table.
On the bottom line, it is similar to defining a constant function pointer, assign it the ISRs address and have it placed in the vector table.

The vector names are predefined and refer to a certain position in the vector table. In theory, you can define your own symbols for thsi pragma, but as these are just offsets in the vector table, it will only make your ode unreadable at best and not working as expected in the worst case, since all possible locations already got a name that is consistent across different processors (if supported by them at all). Or in other words: if you have to ask, don't touch it. If you don't have to ask, you won't touch it. :)

OK. Thanks.

Another question, now my msp430g2231 got a 32kHz crystal connect to XIN and XOUT. if I use the below routine:

void main (void)
{        
    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
    P1OUT = ~LED1; // Preload LED1 off (active low!)
    P1DIR = LED1|LED2; // Set pin with LED1 to output
    TACTL = MC_2|ID_3|TASSEL_2|TACLR; // Set up and start Timer A
    // Continuous up mode , divide clock by 8, clock from SMCLK , clear timer
    for (;;)
    { // Loop forever
        while (TAIFG == 0)
        { // Wait for overflow
        } // doing nothing
        TACTL &= ~TAIFG; // Clear overflow flag
        P1OUT ^= LED1|LED2; // Toggle LEDs
    }
}

Do you know what is the difference of the toggling LED with or without the crystal?

Seems like with the crystal connected, the LED won't toggle. But from above code, I do not do any setting regarding the crystal right? Why?

Or I have to disconnect the crystal then only the LED will toggle?

Steven Gan Teck Yik said:

Do you know what is the difference of the toggling LED with or without the crystal?

Whether you have acrystal or not means that ACLK will run on it or on VLO (a factor of 2 to 8 slower), but since you don't use ACLK, it shouldn't make any difference.

Maybe you made something wrong when connecting the crystal, and the MSP is not starting at all with the crystal connected...

I see. Thanks.

I have another question.

Below is some of the coding I encounter:

#define   LED2     P2OUT_bit.P2OUT_4

LED2 = ~IFG1_bit.WDTIFG;

This functions is for bit wise function. LED2 is set whenever WDTIFG is raised. 

This kind of bit-wise function only can use in IAR workbench right? Cos I tried in CCS4 but can't recognize.

Then, how do we write 'LED2 = ~IFG1_bit.WDTIFG;' so that it can be use in CCS4?

Steven Gan Teck Yik said:

I tried in CCS4 but can't recognize

What, exactly, can it "not recognise" ?

Post the source code that you actually used, and the full text of the exact error message(s) that you get (use copy & paste; do not manually re-type)

Andy Neil said:

I tried in CCS4 but can't recognize

What, exactly, can it "not recognise" ?

Post the source code that you actually used, and the full text of the exact error message(s) that you get (use copy & paste; do not manually re-type)

[/quote]

I mean the bit field function like 'P2OUT_bit.P2OUT_4' or 'LED2 = ~IFG1_bit.WDTIFG'.

As I know, CCS4 doesn't have io430xxxx.h file so it cannot recognize those function. Or you mean your CCS4 can recognize?

Steven,

as i am aware, usually we do not use bit field programming with CCS and IAR (as you can see in the whole example code). If you want, you can look into the header files of CCS compiler which can be found usually at : C:\Program Files\Texas Instruments\ccsv4\msp430\include

I hope this helps.

-Leo-

lhend said:

Steven,

as i am aware, usually we do not use bit field programming with CCS and IAR (as you can see in the whole example code). If you want, you can look into the header files of CCS compiler which can be found usually at : C:\Program Files\Texas Instruments\ccsv4\msp430\include

I hope this helps.

-Leo-

I've look through already and that directory does not include the io430xxxx.h header file.

So then, how am I going to change the below coding so that CCS4 can compile it:

LED2 = ~IFG1_bit.WDTIFG;

P2OUT_bit.P2OUT_4

Steven Gan Teck Yik said:

I've look through already and that directory does not include the io430xxxx.h header file.

Bitfields, while convenient and usually not less efficient than direct manual bit manipulations, are highly ineffective on volatile variables such as hardware registers.
The compiler must not optimize accesses to volatile variables. It needs to make as many accesses and in teh exact orher and the exact position in the code flow as they appear.
So setting several bits in a bitfield leads to larger and more ineffective code than a direct bit manipulation. And the mutiple accesses may have unwanted side-effects (depending on register type and situation).
So bitfields are no longer officially supported.

Steven Gan Teck Yik said:

So then, how am I going to change the below coding so that CCS4 can compile it:

Steven Gan Teck Yik said:

LED2 = ~IFG1_bit.WDTIFG;

Steven Gan Teck Yik said:

P2OUT_bit.P2OUT_4

Inverting the bit (P2OUT_bit.P2OUT_4 = !P2OUT_bit.P2OUT_4) would translate into
P2OUT ^= BIT4;