oops, looking back over the context of that thread, I realize that my
message was slightly off topic.
It would be nice for the GCC to support the interrupt vector table
through a switch statement.
....however for your TI code development I would suggest you remove the
intrinsic or define it as a pass through macro. The intention of this
intrinsic in IAR is not to run time check the data, but to assert to the
compiler that the input data has certain properties that can be used to
optimize the assembler code. I think this is more commonly referred to
as a "pragma" but IAR implemented it as a intrinsic.
a*
Anthony Asterisk wrote:
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
