MSP432™ MCUs Training Part 8: Software MSPWare DriverLib CMSIS Welcome to part 8 of the MSP432 MCU Training series. In this section we will cover the software solutions available on MSP432.

It’s all in MSPWare MSP432 Entry !!!New!!! Training MSP432 DriverLib There’s only one thing to take away, is that everything software related is provided inside of MSPWare. MSPWare is a collection of all software documentation, application notes, training and collateral and so on so forth. Everything is provided within the MSPWare collection. MSPWare is available as a standalone download and it is also available inside of CCS or Code Composer Studio. It is also available on TI’s cloud development tools inside TI’s resource explorer. Inside MSPWare, you can find information on MSP432 including user guide, training, application notes and other libraries. MSP432 DriverLib

Software | MSP Register-Level Traditional MSP register-level access code fully supported Header files provide complete register & bit definitions Complete portability for common peripherals across 16 & 32-bit platforms 100+ code examples for MSP430-shared & new MSP432 peripherals c code example WDTCTL = WDTPW | WDTHOLD; // Stop WDT P5SEL1 |= BIT4; // Configure P5.4 for ADC P5SEL0 |= BIT4; __enable_interrupt(); // MSP432: Enable master interrupt SCS_NVIC_ISER0 = INT_ADC14_BIT; // MSP432: Enable ADC14 interrupt ADC14CTL0 = ADC14SHT0_2 | ADC14SHP | ADC14ON ADC14CTL1 = ADC14RES_2 ADC14MCTL0 |= ADC14INCH_1; // A1 ADC input select; ADC14IER0 |= ADC14IE0; // Enable conv. interrupt SCS_SCR &= ~SCS_SCR_SLEEPONEXIT; // MSP432: Wake up on exit from ISR The very first and fundamental building block on any software platform is the register level code. So MSP register level code is fully provided on MSP432. So any of the traditional MSP430 code examples that you have learned to know and love are fully available. Using the device header file you will gain access to the complete register and bit definition. Since many peripherals are being shared across MSP430 and MSP432 platform, the register as well as the bit definitions for these peripherals are also fully compatible. This enables for complete portability across common peripherals, such as Timer A, or eUSCI. Out of box, more than hundreds of code examples are provided for the peripherals that are available on MSP432. You can browse through any of these simple C code examples to learn how to manipulate and control different peripherals. For example, below is a simple code example used to control the ADC14 module, using the register level access style.

Software | Driver Library GPIO_setAsPeripheralModuleFunctionOutputPin(PARAMETERS); Timer_generatePWM(PARAMETERS) P2DIR |= 0x04; TA1CCTL1 = OUTMOD_7; P2SEL |= 0x04; TA1CCR1 = 384; TA1CCR0 = 511; TA1CTL = TASSEL_1 | MC_1 | TACLR; Driver Library Traditional C code 00101010 10010010 01010100 11001010 Driver Library offers easy-to-understand functions No more cryptic registers to configure MSP430/432 shared peripherals also share DriverLib APIs  reduce porting effort Low level programming In addition to register access code, the MSP432 also provides driver library, which is a collection of highly extracted APIs that enables higher level programming which might be suitable for software engineers in more complex software applications. So driver library offers easy to use and easy to understand functions. Developers no longer need to read the cryptic registers with the definitions to configure the different peripherals. And again since MSP430 and MSP432 families share many peripherals, the driverlib APIs associated across the different platforms, this will reduce the porting effort if you already have an existing MSP430 application using driver library. You can see here an example of how driver library condenses the code for the software programmer. On the very top is what the code looks like on driver library, Two functions are required to fully configure the timer to generate PWM. When using traditional register level C code, several instructions are required. As you can see, many of these values are harder to digest and harder to understand.

MSP432 DriverLib | ROM & Source MSP432 DriverLib available as source Always the latest, most updated version Library available as BSD source = industry standard Flexibility for users to further customize/enhance MSP432 DriverLib implemented & tested in ROM ROM has lower current consumption No wait-state [ even @ max speed = 48MHz] Frees up flash space (25kB) for application code Fully validated & robust ROM code: no future major changes Since MSP432 driver library was developed along the same time the chip was designed, the library has been fully tested to prove its robustness and efficiency. For that reason the MSP432 library was programmed into ROM, that way developers can access the driver library either as ROM or as Source code. Even though the ROM version is very robust and proved to work with the latest version of silicon, there are always opportunity to enhance existing APIs with new features or extend the API set to have new function calls with new capabilities. For this reason some developers might choose to use the MSP432 driver library at source. It is available fully as open source using BSD license and it is completely up to the users to further customize, enhanced or add new functionalities to the driver library. On the other hand many developers might find the MSP432 driver lib in ROM suitable for their application. In addition to proven robustness, DriverLib in ROM has a few additional benefits. First of all rom execution has lower current consumption compared to flash. In addition, ROM requires no wait-state, even at the max speed of 48MHz. Using peripheral driver library in ROM we also free up the flash space of roughly 25kB for application code. With these three reasons, using driverlib in ROM will free up the space in your code, consume less power for the device and can perform a higher speed compare to flash when the device is running at maximum speed.

MSP432 DriverLib | ROM & Source MAP file: method to ensure ROM API is always used UNLESS there’s an update (fix/enhancement ) or APIs only available in Source ROM API 1 API 2 API n API n+1 API 3 MAP Source API 1 API 2 API n API n+1 API 3 API n+2 API n+3 API 1 API 2 API API n+1 API 3 . . . . . . . . . Now at this point you might ask,” but the source is always new within the ROM so how do I know when to use what?”. As a rule of thumb, it is always best to use the latest version. Most of the time ROM APIs will not be changed because it has not been fully tested. Sometimes due to new enhancements, the source version might be preferable. For that reason an intermediate layer has been created called the map layer. This map later will always point to ROM if it is the latest version if not it will point to the source version which might be a newest version of the API or a completely brand new API altogether. So if the developers always choose to use the MAP version of the API, they are guaranteed to either use the ROM version (the most robust version) or the latest version if that is available in the source code. API n+2 API n+3 Bug fix Feature Enhancement New API Legend:

MSP432 DriverLib | Calling Convention MSP432 DriverLib source (Flash) Include driverlib source folder in your project API Call: TimerA_generatePWM(param1, param2, etc.); MSP432 DriverLib ROM Use “rom.h” header file API Call: ROM_TimerA_generatePWM(param1, param2, etc.); Patches new features or bug fixes: Use “rom_map.h” header file API Call: MAP_TimerA_generatePWM(param1, param2, etc.); This is actually very easy to use in reality. The three ways to use the DriverLib conventions are if you want to use the source code, simply have no prefix and the API call will be something like this: TimerA_generatePWM. Essentially PeripheralName_PWN. IF you explicitly want to use a driverlib ROM function and you know for a fact that the ROM function is what you want to use and it is the latest and greatest version of the API you can use a prefix ROM_ in front of the function name. Now the smartest way to use the driverlib API is to use the MAP function so the API call would now be MAP_TimerA_generatePWM. Using this MAP version, you are guaranteed to use the ROM if possible or the latest version in the source code.

Software | CMSIS Cortex Microcontroller Software Interface Standard (CMSIS) Standardized hardware abstraction layer for the Cortex-M4 processor series In addition to providing the traditional register access code as well as driver library, MSP432 is fully compliant to the Cortex Microcontroller Software Interface System or CMSIS, since MSP432 is also a Cortex M microcontroller. CMSIS is a standardized hardware abstraction layer for the Cortex M processors. With CMSIS you can leverage the CMSIS header file, the CMSIS intrinsic functions as well as high abstractive libraries such as DSP, RTOS so on and so forth. As an MSP432 user, developers can use a mixture of register access code, driver library code as well as CMSIS libraries.

Software | CMSIS MSP definition CMSIS definition #define WDTCTL \ (HWREG16(0x4000480C)) /* WDTCTL Control Bits */ #define WDTIS0 (0x0001) #define WDTIS1 (0x0002) #define WDTIS2 (0x0004) #define WDTCNTCL (0x0008) #define WDTTMSEL (0x0010) #define WDTSSEL0 (0x0020) #define WDTSSEL1 (0x0040) #define WDTHOLD (0x0080) #define WDTPW (WDTPW_VAL) #define __WDT_BASE__ (0x40004800) typedef struct { uint8_t RESERVED0[12]; union { /* WDT_CTL Register */ __IO uint16_t reg; struct { /* WDT_CTL Bits */ __IO uint16_t IS : 3; __O uint16_t CNTCL : 1; __IO uint16_t TMSEL : 1; __IO uint16_t SSEL : 2; __IO uint16_t HOLD : 1; __IO uint16_t PW : 8; } bit; } CTL; } WDT_Type; #define WDT ((WDT_Type *) __WDT_BASE__) In addition to providing the traditional register access code as well as driver library, MSP432 is fully compliant to the Cortex Microcontroller Software Interface System or CMSIS, since MSP432 is also a Cortex M microcontroller. CMSIS is a standardized hardware abstraction layer for the Cortex M processors. With CMSIS you can leverage the CMSIS header file, the CMSIS intrinsic functions as well as high abstractive libraries such as DSP, RTOS so on and so forth. As an MSP432 user, developers can use a mixture of register access code, driver library code as well as CMSIS libraries.

Software | Libraries & RTOS High-level libraries Graphics Library Capacitive Touch Library IQMath Application-specific libraries NFCLink & TRF7970A NFC Library CC3100 WiFi SimpleLink BLE & Bluetooth And more … RTOS TI-RTOS FreeRTOS Micrium µC/OS And more…. In addition to the low level libraries and header files, MSP432 provides a wide range of high level libraries that developers can leverage to quickly build a robust and efficient base system so that they can focus more energy on a unique application. As mentioned before all of these libraries and examples are all located inside of MSPWare. So you can go inside of MSPWAre to find out more information about these libraries, such as graphics library, capacitive touch library, IQmath. For more application centric libraries such as NFC, CC3100 WiFi Simplelink BLE Bluetooth and so on so forth. For more MSP432 applications that require resource management with multiple components, peripherals and tasks running at parallel, there are also a wide variety of real time operating systems that users can use for the MSP432 . Some of them include TI RTOS, Free RTOS or Micrium uC/OS and there are many more being introduced into the MSP432 software ecosystem. For more information on these libraries, I definitely recommend browsing through MSPWare. Again you can find MSPWare as a standalone download on the TI’s cloud development tool website, inside TI resource explorer. Or inside CCS or Code Composer Studio IDE. In here you can find different MSP432 libraries such as the driverlib, graphics library and so on so forth. You can find more information on the Real Time Operating systems as well as code examples and demo projects that can be used to demonstrate different capabilities with these libraries. With that we have concluded the part number 8 of the MSP432 MCU training series covering software solutions on MSP432. Thanks for watching!