eUSCI vs. USCI

Thank you Mr. Anderson and Mr. Cowsill. That document answers my question.

Hi,

I have some bit confusion on this statements

"One significant change that must be accounted for in the firmware is the servicing of the interrupt flags.

The interrupt flags associated with the USCI module vectored to two different interrupt service routines,

depending on whether they were data or status flags. With the eUSCI module, all the interrupt flags are

prioritized and combined to source a single interrupt vector the UCAxIV or the UCBxIV"

If you look in to USCI i2c BSP codes the flags and data also checked in the same vector as follows

#pragma vector = USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void)
{
  switch(__even_in_range(UCB0IV,12))
  {
  case  0: break;                           // Vector  0: No interrupts
  case  2: break;                           // Vector  2: ALIFG
  case  4: break;                           // Vector  4: NACKIFG
  case  6: break;                           // Vector  6: STTIFG
  case  8: break;                           // Vector  8: STPIFG
  case 10:                                  // Vector 10: RXIFG
    RXData = UCB0RXBUF;                     // Get RX data
    __bic_SR_register_on_exit(LPM0_bits);   // Exit active CPU
    break;
  case 12: break;                           // Vector 12: TXIFG
  default: break; 
  }
}

can anyone clarify it.

Thanks in advance.

Unfortunately the naming of (e)USCI modules is a bit vague. As well as creating the "enhanced" eUSCI TI made some other improvements to USCI, for example in the F5/6 series chips. These have a similar interrupt vector generator setup to the eUSCI.

Apparently, the USCI/eUSCI comparison was written for migrating from F2x/G2x family to FR2x family.
On 2x series, where the USCI was introduced, RX and TX were separate interrupt vectors, but shared for A and B. Also, in I2C mode, RX and TX were serviced by the TX vector while the I2C status interrupts called the RX vector.
On F5x family, A and B module got separate vectors which serve both, RX and TX (and I2C status interrupts as well), like the eUSCI does. This is probably where your example code comes from.
I've added this to my 'documentation quirks' list.