This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5969: MSPware/driverlib v3.60.00.10 I2C examples

Part Number: MSP430FR5969


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)
    case 0x00: break;                       // Vector 0: No interrupts break;
    case 0x02: break;
    case 0x04:
        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
            TXByteCtr--;                        // Decrement TX byte counter
            __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): 

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

  • Hi Nick,

    This is great feedback, I will bring your concerns to the DriverLib support team so that your concerns might be addressed in future revisions.

  • Hi Ryan,

    I don't want to appear churlish or ungrateful - I love the MSP430s and really like DriverLib, but I'm a stickler for code quality (as are my team). I make mistakes like everyone does and coding & style are complex subjects: engineering, art, science, pride in a good job done and personal preference all play their part.

    So, when I code, even after 30 years of designing and implementing large, complex, real-time exchange trading systems, everything I do is peer reviewed and run through the QA process, even if it's just a coding example. Code for yourself is one thing; code that others use, learn from and have to support, is quite another. If I code for myself, I'm just as critical - complacency sets in otherwise.

    "even if it's just a coding example" - not a good phrase - teaching materials should be the core of good practice, exemplars, not something to be taken lightly.

    So, it seems kind of strange to me that a fair few of the coding examples that I've seen in DriverLib would fail, for a host of reasons, most basic commercial peer review & QA processes that I've been through in industry.

    The vast majority of the CCS environment that TI so generously provide (now) for free, is excellent - I find it a great environment to develop in (especially coupled with an Analog Discovery II), but I do wonder how some of the example code was ever let out of the door - it's our visibility of TI's acceptable code quality; it should convey excellence as well as inform...

    Please, please have experienced developers who have worked in a structured, QA-driven, environment and understand about coding standards, go through the examples and improve their quality. This isn't a job for an intern/student/some hacker/whatever, it's a job for someone who knows about quality, does justice to what is an amazing product, has pride in what they do and knows how to communicate the message, i.e. to teach.

    Yes, it's an investment, but it would be a relatively cheap (if somewhat intangible) win.

    Rant over !

    EDIT: Apologies if that sounded harsh - it's not meant to - it's meant to be constructive !

**Attention** This is a public forum