MSP430FR5969: MSPware/driverlib v3.60.00.10 I2C examples

Hi,

This is a particular bugbear of mine...

Examples are supposed to be exemplars of good practice - they should be clean, well documented and hopefully, correct; the comments should be appropriate and not misleading...

Consider the following I2C example ISR from eusci_b_i2c_ex5_masterMultipleSlave.c:

void USCIB0_ISR(void)
{
    switch(__even_in_range(UCB0IV,0x1E))
    {
    case 0x00: break;                       // Vector 0: No interrupts break;
    case 0x02: break;
    case 0x04:
        EUSCI_B_I2C_masterSendStart(EUSCI_B0_BASE);
        break;                                // Vector 4: NACKIFG break;
    case 0x06: break;                       // Vector 6: STTIFG break;
    case 0x08: break;                       // Vector 8: STPIFG break;
    case 0x0a: break;                       // Vector 10: RXIFG3 break;
    case 0x0c: break;                       // Vector 14: TXIFG3 break;
    case 0x0e: break;                       // Vector 16: RXIFG2 break;
    case 0x10: break;                       // Vector 18: TXIFG2 break;
    case 0x12: break;                       // Vector 20: RXIFG1 break;
    case 0x14: break;                       // Vector 22: TXIFG1 break;
    case 0x16: break;                       // Vector 24: RXIFG0 break;
    case 0x18:
        if(TXByteCtr)                         // Check TX byte counter
        {
            EUSCI_B_I2C_masterSendMultiByteNext(EUSCI_B0_BASE,
                                                TXData[SlaveFlag]);
            TXByteCtr--;                        // Decrement TX byte counter
        }
        else
        {
            EUSCI_B_I2C_masterSendMultiByteStop(EUSCI_B0_BASE);
            __bic_SR_register_on_exit(CPUOFF);    // Exit LPM0
        }
        break;                              // Vector 26: TXIFG0 break;
    default: break;
    }
}

The two main things here are that

1. The comments regarding the vector labels are out of sync/wrong,  
2. This is supposed to be an exemplar of driverlib coding- why aren't the "magic" literals replaced by their symbolic equivalents? All the correct (hopefully) symbolic names are in the driverlib headers, surely they should be used....

e.g. (not an exemplar - just cut-n-pasted from a project I'm working on): 

DECLARE_ISR(USCI_B0_VECTOR, USCIB0_ISR)
{
	// These are the I2C definitions for the UCSI
	switch( __even_in_range( UCB0IV, USCI_I2C_UCBIT9IFG ) )
	{
	case USCI_NONE:					// No interrupt
		break;
	case USCI_I2C_UCALIFG:			// Arbitration lost - UCALIFG
		break;
	case USCI_I2C_UCNACKIFG:		// NAK received (Master only)
		// EUSCI_B_I2C_masterSendStart( EUSCI_B0_BASE ); // Resend START if NAK'd
		break;
	case USCI_I2C_UCSTTIFG:			// START condition detected with own address (Slave mode only)
		break;
	case USCI_I2C_UCSTPIFG:			// STOP condition detected (Master & Slave mode)
		break;
	case USCI_I2C_UCRXIFG3:			// RXIFG3
		break;
	case USCI_I2C_UCTXIFG3:			// TXIFG3
		break;
	case USCI_I2C_UCRXIFG2:			// RXIFG2
		break;
	case USCI_I2C_UCTXIFG2:			// TXIFG2
		break;
	case USCI_I2C_UCRXIFG1:			// RXIFG1
		break;
	case USCI_I2C_UCTXIFG1:			// TXIFG1
		break;
	case USCI_I2C_UCRXIFG0:			// RXIFG0
		break;
	case USCI_I2C_UCTXIFG0:			// TXIFG0
		break;
	case USCI_I2C_UCBCNTIFG:		// Byte count limit reached (UCBxTBCNT)
		break;
	case USCI_I2C_UCCLTOIFG:		// Clock low timeout - clock held low too long
		break;
	case USCI_I2C_UCBIT9IFG:		// Generated on 9th bit of a transmit (for debugging)
		break;
	}
}