1. 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.

2. 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

3. 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.

4. 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
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.

5. 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 [ 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.

6. 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:

7. 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.

8. 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.

9. Software | CMSIS MSP definition CMSIS definition
#define WDTCTL \ (HWREG16(0x C))
/* WDTCTL Control Bits */
#define WDTIS (0x0001)
#define WDTIS (0x0002) #define WDTIS (0x0004)
#define WDTCNTCL (0x0008)
#define WDTTMSEL (0x0010)
#define WDTSSEL0 (0x0020)
#define WDTSSEL1 (0x0040)
#define WDTHOLD (0x0080)
#define WDTPW (WDTPW_VAL)
#define __WDT_BASE__ (0x )
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.

10. 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!