|
|
DriverLib for MSP432 Series has been tested and compiled under a variety of different toolchains. Subsequently, for each toolchain a specific debugger was used for testing validation. Below is a list that contains the supported toolchain and corresponding hardware debugger used.
| Toolchain | Debugger |
| Texas Instruments Code Composer Studio 7.3 | XDS110 (LaunchPad) |
| IAR Embedded Workbench for ARM 8.11.2 | Segger J-LINK |
| GNU C Compiler gcc-arm-none-eabi-6-2017-q1-update | Segger J-LINK |
| Keil Embedded Development Tools for ARM 5.23 | KEIL U-Link Pro |
The DriverLib is meant to provide a "software" layer to the programmer in order to facilitate higher level of programming compared to direct register accesses. Nearly every aspect of a MSP432 device can be configured and driven using the DriverLib APIs. By using the high level software APIs provided by DriverLib, users can create powerful and intuitive code which is highly portable between not only devices within the MSP432 platform, but between different families in the MSP430/MSP432 platforms.
Writing code in DriverLib will make user code more legible and easier to share among a group. For example, examine the following pair of code snippets. Both sets of code set MCLK to be sourced from VLO with a divider of four:
Traditional Register Access
DriverLib Equivalent
As can be seen, the DriverLib API is readable, sensible, and easy to program for the software engineer. Additionally, DriverLib APIs for other platforms such as MSP430 will use very similar (if not identical) APIs giving code written with DriverLib APIs a boost in portability.
Interrupt handlers are also not included with the DriverLib APIs. APIs to manage/enable/disable interrupts are included, however the actual authoring of the interrupt service routine is left up to the programmer. For reference, A typical interrupt handler that takes advantage of DriverLib APIs can be seen in the following code snippet:
Calling the following API alone while MCLK is greater that 128Khz will result in a system error:
This is because the DriverLib module will not account for the overall system frequency of the system. Instead, similar APIs to the following must be called in conjunction:
Cross-module considerations such as these must be taken when programming with DriverLib APIs as DriverLib was not designed to account for high level system requirements.
Accessing Driver Library APIs in ROM is as easy as including the rom.h header file, and then replacing normal API calls with a ROM_ prefix. For example, take the following API from the pcm.c module that changes the power state to PCM_AM_DCDC_VCORE1:
After including the rom.h file, all that would have to be done to switch to the ROM equivalent of the API would be add the ROM_ prefix to the API:
While the majority of DriverLib APIs are available in ROM, due to architectural limitations some APIs are omitted from being included in ROM. In addition, if any bug fixes were added to the API after the device ROM was programmed, it is desirable to use the flash version of the API. An "intelligence" has been created to account for this problem. If the user includes the rom_map.h header file and uses the MAP_ prefix in front of the API, the header file will automatically use preprocessor macros to decide whether to use a ROM or flash version of the API.
To use these legacy APIs, no additional work is needed. All that is needed is to include the header file of the module you want to use and both the old and the new APIs will be available. For example, for WDT_A:
By including this header file, the user is granted access to all of the legacy DriverLib APIs from MSP430 Driver Library verbatim. For additional documentation on the MSP430 implementation of DriverLib, please refer to the MSP430Ware Website.
Many of the APIs were simplified and refactored for the MSP432 version of Driver Library. For example, to halt the watchdog module for a 5xx MSP430 device, the following API is used:
Note that while many Driver Library APIs are shared between MSP430 and MSP432, there are a few underlying differences between the two architectures. Interrupts, for example, are a bit difference on MSP432 compared to MSP430 due to integration with ARM's interrupt controller (the NVIC). While each module will still have individual status (IFG), enable/disable, and clear bits, interrupt service routines now have to be associated with the ARM NVIC before usage.
Getting started using DriverLib for MSP432 Series is very simple regardless of the chosen development environment.
An empty "skeleton" project is provided in the examples directory of the SDK release. This project includes links to the DriverLib library as well as everything that is needed for the programmer to immediately start writing a DriverLib application. A user can import this project in CCS using the TI Resource Explorer, or open the workspace with IAR Embedded Workbench for ARM or KEIL uVision 5. All of the include paths and compiler options are set up to allow the user to seamlessly start development on their MSP432 DriverLib application.
The GNU compiler tools for ARM are fully supported by the MSP432 Series DriverLib. While no IDE in specific is supported, Makefiles are provided for both the library and all of the code examples. Vector table definitions that are compatible with the GCC compiler are also provided for code examples in the startup_gcc.c file for each individual code example. For the GNU tools, separate header files are included in the inc directory of the root installation of DriverLib. These header files are the latest that are available at the time of DriverLib release, however newer header files may be downloaded as a part of the CCS installation.