Hello,
apologies for the earlier email...
well ...i should've gone thru' the manual...i'm using
msp430 - F1611...mspgcc for it doesnt support
pragma....using interrupt as follows ...i can now
compile it...
my goal: set the signal period of 20ms using CCR0 and
fire a PWM
o/p(1 ms duty cycle) at the start of the signal
period.

but will this code set TAIFG when the timer starts the
count
from TACCR0?
I tried firing up the LED and it doesnt work.


#include  "msp430x16x.h"
#include  "signal.h"


volatile unsigned char *_p5out = (unsigned
char*)(0x0031);
unsigned char *_p5dir = (unsigned char*)(0x0032);



interrupt (TIMERA0_VECTOR) Timer_A (void)
{
 switch( TAIV )
 {
   case  2: break;                // CCR1 not used
   case  4: break;                // CCR2 not used
   case 10: *_p5out = 0x40;              
            //CCR1 = 32;// 1ms duty cycle
            break;
 }
}


void main(void)
{ 
  WDTCTL = WDTPW + WDTHOLD;             // Stop WDT
  P1OUT = 0;
  P1SEL = 0X04;  // P1.2
  P1DIR = 0Xff;   
  CCTL0 =  OUTMOD_7; 
  TACTL = TASSEL_1 + MC_1  + TAIE;       // ACLK
32khz, upmode, interrupt
  CCR0 = 640;	// 20 ms period
  *_p5out = 0x00;
  _BIS_SR(LPM0_bits + GIE);  // Enter LPM0 w/
interrupt
}






	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

chetan loke wrote:

> interrupt (TIMERA0_VECTOR) Timer_A (void)
> {
> switch( TAIV )
> {
>    case  2: break;                // CCR1 not used
>    case  4: break;                // CCR2 not used
>    case 10: *_p5out = 0x40;             
>             //CCR1 = 32;// 1ms duty cycle
>             break;
> }
> }


You must make sure that TAIV is read only once per ISR.
GCC may produce code that reads TAIV everytime it is evaluating a
"case" 
statement.
Last time I used this stuff, it didn't work like this and it was OK 
after I changed it to something like

interrupt (TIMERA0_VECTOR) Timer_A (void)
{
  unsigned char taiv = TAIV;
  switch (taiv) {
    case 2:
      /* handle CCIFG1 */
      break;
    case 4:
      /* handle CCIFG2 */
      break;
    case 10:
      /* handle TAIFG */
      break;
  }
}

HTH,
Patrick

Why not just use TAIV in a function pointer? It will surely produce more 
effciient code.

Al

Patrick Huesmann wrote:

>chetan loke wrote:
>
>  
>
>>interrupt (TIMERA0_VECTOR) Timer_A (void)
>>{
>>switch( TAIV )
>>{
>>   case  2: break;                // CCR1 not used
>>   case  4: break;                // CCR2 not used
>>   case 10: *_p5out = 0x40;             
>>            //CCR1 = 32;// 1ms duty cycle
>>            break;
>>}
>>}
>>    
>>
>
>
>You must make sure that TAIV is read only once per ISR.
>GCC may produce code that reads TAIV everytime it is evaluating a
"case" 
>statement.
>Last time I used this stuff, it didn't work like this and it was OK 
>after I changed it to something like
>
>interrupt (TIMERA0_VECTOR) Timer_A (void)
>{
>  unsigned char taiv = TAIV;
>  switch (taiv) {
>    case 2:
>      /* handle CCIFG1 */
>      break;
>    case 4:
>      /* handle CCIFG2 */
>      break;
>    case 10:
>      /* handle TAIFG */
>      break;
>  }
>}
>
>HTH,
>Patrick
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Hi everyone ;) This is my first post here. I'm beginning with MSP430s. (and
like them very much)

Al, sorry, but I could not figure out what you mean. Could you please make
an example of a "use TAIV in a function pointer"?

Cheers.
Wagner

>
> Why not just use TAIV in a function pointer? It will surely produce more
> effciient code.
>
> Al
>
> Patrick Huesmann wrote:
>
> >chetan loke wrote:
> >
> >
> >
> >>interrupt (TIMERA0_VECTOR) Timer_A (void)
> >>{
> >>switch( TAIV )
> >>{
> >>   case  2: break;                // CCR1 not used
> >>   case  4: break;                // CCR2 not used
> >>   case 10: *_p5out = 0x40;
> >>            //CCR1 = 32;// 1ms duty cycle
> >>            break;
> >>}
> >>}
> >>

--

Thnks

it worked...so how do i figure out what the compiler
tweaks and what it doesnt..this is my first time
programming a microcontroller.

--- Patrick Huesmann <patrick.huesmann@patr...>
wrote:

> chetan loke wrote:
> 
> > interrupt (TIMERA0_VECTOR) Timer_A (void)
> > {
> > switch( TAIV )
> > {
> >    case  2: break;                // CCR1 not used
> >    case  4: break;                // CCR2 not used
> >    case 10: *_p5out = 0x40;             
> >             //CCR1 = 32;// 1ms duty cycle
> >             break;
> > }
> > }
> 
> 
> You must make sure that TAIV is read only once per
> ISR.
> GCC may produce code that reads TAIV everytime it is
> evaluating a "case" 
> statement.
> Last time I used this stuff, it didn't work like
> this and it was OK 
> after I changed it to something like
> 
> interrupt (TIMERA0_VECTOR) Timer_A (void)
> {
>   unsigned char taiv = TAIV;
>   switch (taiv) {
>     case 2:
>       /* handle CCIFG1 */
>       break;
>     case 4:
>       /* handle CCIFG2 */
>       break;
>     case 10:
>       /* handle TAIFG */
>       break;
>   }
> }
> 
> HTH,
> Patrick
> 
> 



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Hi,

On Wed, 2 Mar 2005 18:21:01 -0800 (PST), chetan loke
<chetanloke@chet...> wrote:
>  it worked...so how do i figure out what the
compiler
>  tweaks and what it doesnt..this is my first time
>  programming a microcontroller.

Read the listing (*.lst) that mspgcc generates, it shows the generated
asm code side-by-side with the original c code. If your makefile
doesn't generate listings, check the makefiles of the examples that
come with mspgcc.
This isn't really specific to MCU programming.

HTH,
Patrick

Hi,

On Thu, 03 Mar 2005 11:20:04 +1030, Onestone
<onestone@ones...> wrote:
>  Why not just use TAIV in a function pointer? It will surely produce more 
>  effciient code.

Not so sure about that, because it adds function call overhead. Plus,
some special stuff works only in the scope of the ISR itself, i.e.
reading and writing of the user code status register (for example, to
wake up user code on interrupts).

If efficiency really is an issue, for example in ISRs that suffer very
high interrupt loads, then assembler is better anyway (it's actually
one of the rare cases where assembler is still feasible ;-))

Patrick Huesmann wrote:

>Hi,
>
>On Thu, 03 Mar 2005 11:20:04 +1030, Onestone <onestone@ones...>
wrote:
>  
>
>> Why not just use TAIV in a function pointer? It will surely produce
more 
>> effciient code.
>>    
>>
>
>Not so sure about that, because it adds function call overhead. 
>
Depends on how the compiler treats it. The answer is simple in asm, and 
if you can't twiddle with C to get simsilr code it tells me that the 
compiler optimiser neerds improvement.

>Plus,
>some special stuff works only in the scope of the ISR itself, i.e.
>reading and writing of the user code status register (for example, to
>wake up user code on interrupts).
>  
>
>
>If efficiency really is an issue, for example in ISRs that suffer very
>high interrupt loads, then assembler is better anyway (it's actually
>one of the rare cases where assembler is still feasible ;-))
>
I'm obviously expected to bite here, so I will. BULLSHIT.

I doubt you could implement any of my current designs in C on the same 
MSP430, yet in asm I have both processing capacity and memory to spare. 
As for the vaunted shorter  development times, another myth, actual 
coding should be such a small percentage of a well designed product that 
language is almost irrelevant from that perspective. The only importance 
of language from a design viewpoint lies in the skills of those tasked 
to program and maintain the product. It is pointless coding in asm if 
they lack the skills, similarly it is  pointless designing for C if your 
asm programmer can't write in C. The big difference is that only a small 
percentage of  C programmers are truely fluent in asm, whereas most asm 
programmers have good C skills. The major issue is that universities are 
churning out C and C++ programmers by the bucketful, but very few leave 
uni with good asm skills, why? Well part fad, part industry perception, 
partly because C is far easier to teach, and mostly because it is far 
easier to learn. Hell my sons been programming in C since he was 10, he 
reckons it was easier to learn than VB.

Al

>  
>

Heee hee, Al, I can't wait to hear what you will say with this
factoid: I 
think probably more than 50% of the new college kids ONLY have Java 
experience. C/C++ are too "low level" for them...

At 01:44 AM 3/3/2005, Onestone wrote:
>...
>I'm obviously expected to bite here, so I will. BULLSHIT.
>
>I doubt you could implement any of my current designs in C on the same
>MSP430, yet in asm I have both processing capacity and memory to spare.
>As for the vaunted shorter  development times, another myth, actual
>coding should be such a small percentage of a well designed product that
>language is almost irrelevant from that perspective. The only importance
>of language from a design viewpoint lies in the skills of those tasked
>to program and maintain the product. It is pointless coding in asm if
>they lack the skills, similarly it is  pointless designing for C if your
>asm programmer can't write in C. The big difference is that only a
small
>percentage of  C programmers are truely fluent in asm, whereas most asm
>programmers have good C skills. The major issue is that universities are
>churning out C and C++ programmers by the bucketful, but very few leave
>uni with good asm skills, why? Well part fad, part industry perception,
>partly because C is far easier to teach, and mostly because it is far
>easier to learn. Hell my sons been programming in C since he was 10, he
>reckons it was easier to learn than VB.
>
>Al
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

Hi,

On Thu, 03 Mar 2005 20:14:48 +1030, Onestone
<onestone@ones...> wrote:
>  I doubt you could implement any of my current designs in C on the same 
>  MSP430

This may be an issue in very high-volume applications.

But the company that I work for, only does low quantity, and there you
have it the other way around: cost of parts (MCUs etc.) is almost
irrelevant, whereas development cost is crucial.

And development cost would skyrocket if we had to learn new asm
languages for each new MCU we're using. Not to mention the impact on
code reuse and portability.

>  The major issue is that universities are 
>  churning out C and C++ programmers by the bucketful, but very few
leave 
>  uni with good asm skills, why?

Why should I learn asm at university? The professors would probably
teach assembly language based on some ancient, bizarre architecture
that is obsolete even before the students receive their diploma ;)

>  Hell my sons been programming in C since he was
10, he 
>  reckons it was easier to learn than VB.

I'm glad that I never had to use VB yet ;-))

regards,
Patrick