ADC12IV is only 1 example of the usage of the interrupt vecor table.
For the msp43054xx cases, every single interrupt has a similar interrupt
vector register often with numerous subconditions (valid case
statements). Adding support for effeiciently producing these interrupt
vector tables would be very useful in C would be very useful.
For example on the DMA interrupt, the DMAIV is set based on which
channel is triggered:
from slau208e.pdf (msp4305xx Family Guide)
7.3.10 DMA Interrupt Vector Register (DMAIV)
DMAIV Bits 15-0 DMA interrupt vector value
DMAIV Interrupt Source Interrupt Flag Interrupt Contents Priority
00h No interrupt pending
02h DMA channel 0 DMA0IFG Highest
04h DMA channel 1 DMA1IFG
06h DMA channel 2 DMA2IFG
08h DMA channel 3 DMA3IFG
0Ah DMA channel 4 DMA4IFG
0Ch DMA channel 5 DMA5IFG
0Eh DMA channel 6 DMA6IFG
10h DMA channel 7 DMA7IFG Lowest
The example usage taken from msp430x54x_dma_04.c in the code examples
shows an interrupt handler like this:
#pragma vector=DMA_VECTOR
__interrupt void DMA_ISR(void)
{
switch(__even_in_range(DMAIV,16))
{
case 0: break;
case 2: // DMA0IFG = DMA Channel 0
P1OUT ^= BIT0; // Toggle P1.0
break;
case 4: break; // DMA1IFG = DMA Channel 1
case 6: break; // DMA2IFG = DMA Channel 2
case 8: break; // DMA3IFG = DMA Channel 3
case 10: break; // DMA4IFG = DMA Channel 4
case 12: break; // DMA5IFG = DMA Channel 5
case 14: break; // DMA6IFG = DMA Channel 6
case 16: break; // DMA7IFG = DMA Channel 7
default: break;
}
Obviously if more than 1 DMA channel is used, then more then 1 case
statement is required.
Paul F. Sehorne wrote:
Sergey, thanks for your explanation.
I understand the goal of __even_in_range. I saw in the IAR
disassembled code what it accomplishes. And I understand the need if
the switch statement actually had 34 case statements, but in this code
there is only one case statement. So, other than for educational
reasons, I don't see the value of spending my time trying to figure
out how to write the equivalent routine.
I did write a routine that confirms (at runtime) that the passed in
value is in range and is even (lsb is 0); in which case the value is
just passed back to the program, and if it does not meet these
criterion zero is passed back (again, at runtime). I could further
improve this routine by moving the code in the one lone case statement
into the assembler routine. And I would like to revisit this function
at a later date, for educational reasons and to eventually have an
__even_in_range function when needed for multiple case statements.
But for the time being I am content to move on to other more pressing
issues that are holding up the completion of my port of the eZChronos
firmware to mspgcc4.
If I am making a mistake by passing on this for the moment, please
point it out to me.
Paul
On 6/14/2010 4:38 AM, Sergey A. Borshch wrote:
On 14.06.2010 5:50, Paul F. Sehorne wrote:
I wrote an assembly routine to emulate the intrinsic function
__even_in_range, and although it might work I doubt that it
accomplishes
anything significant.
This function ensures the compiler that it's first argument is always
even and
always in range [0...second argument]. So compiler allowed to
generate case as
efficient table jump without additional checking of switch() statement.
And nothing more. You can just replace
switch(__even_in_range(ADC12IV,34))
to
switch(ADC12IV).
------------------------------------------------------------------------
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
------------------------------------------------------------------------
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
