To become more familiar with the TI ecosystem and explain how to best get started with MSPM0, this section describes the step-by-step migration process of a basic application.

To demonstrate the process of porting from Microchip to MSPM0, this description includes the steps to port a basic low-power UART application from a Microchip 8-bit device to an MSPM0 device using an existing UART example as the starting point. This example starts with a USART example for Microchip ATtiny and ATmega devices with a USART module.

1. Chose the right MSPM0 MCU.

   The first step of migration is to choose the correct MSPM0 device for the application. To do this, the portfolio section of this guide can be used to choose a MSPM0 family. To narrow down to a specific device using the product selection tool. When choosing a replacement for a Microchip ATtiny or ATmega part, MSPM0 devices can match just about any functionality, so long as the correct replacement device is selected. It is important to ensure that the MSPM0 that you have selected has the peripheral set available for the code you want to migrate over. MSPM0 also offers many pin-to-pin scalable options, providing the ability to easily scale to larger or smaller memory devices without changing anything else in the system.

   For purposes of this example, we have chosen the MSPM0C1104 as the best fit for his application.

2. Select hardware and order an EVM.

   Using an evaluation module (EVM) can expedite the migration process. For the MSPM0 MCUs, a LaunchPad kit is the easiest hardware to begin on. LaunchPad kits are easy to use because they come with a built-in programmer and are designed to enable rapid development.

   The MSPM0C1104 has a LaunchPad development kit (LP-MSPM0C1104) that can be used for porting the software.

3. Setup software IDE and SDK.

   Before the software can be ported, a software development environment must be chosen and setup. Section 2.1 shows all of the IDEs supported by MSPM0. The migration and porting process is similar for any IDE that is chosen. The latest version of the MSPM0 SDK should be used.

   For this example, TI's CCS-Theia is the chosen IDE.

   Figure 2-5 Code Composer Studio IDE
4. Software porting.

   When the environment is ready, start using the MSPM0 SDK. As mentioned, the MSPM0 SDK is similar to the MPLAB Harmony software package. The MSPM0 SDK offers different layers for software development. For equivalents to Microchip's device drivers, take a look at MSPM0's TI Drivers and Driverlib support. Most MSPM0 users find DriverLib level software is the best fit for their applications, so most MSPM0 software examples are also DriverLib based. This example uses DriverLib.

   One option when porting a project is to try to replace each section of code with equivalent MSPM0 DriverLib APIs, but this is not generally the easiest path. Generally, it is best to first understand the application code being ported. Then start with the closest MSPM0 example project and modify it to match the original code functionality. This process is going to be shown below using a low-power UART example from MPLAB Discover. For more complex projects using many peripherals, this process is typically repeated for each peripheral.

   1. Understand the application.

      The following description is from the example project from Microchip's 'Getting Started with USART user guide.

      The following code continually sends the string “Hello World!”. A string is sent character by character. The ‘USART0_sendString’ function calls the ‘USART0_sendCharacter’ function for each character in “Hello Word!” string. Before sending each character, the ‘USART0_sendChar’ function waits for the previous character transmission to be completed. This is done by polling the status register, until the data register empty flag, STATUS.DREIF, is set.

      The first step is to understand the main settings for the MCU. This is generally clock speeds and power policies. In this example, the general clock frequency is not specified because the only important setting is that the UART works in low power Stop0 mode. It states the low power UART clock is based on the 'HIS' or high-speed internal oscillator meaning there is no external crystal being used. The UART runs at 9600 baud, 8 data bits, 1 start and stop bit, no parity. No hardware flow control is used. The application side checks for an 'S' or 's' to be received and blinks an LED.

   2. Find the closest MSPM0 example.

      Next step is to understand any differences between the UART modules for ATmega/ATtiny and MSPM0 and then find the closest example in the MSPM0 SDK. This is easily accomplished by referring to the UART section in Section 4. This section highlights differences between the UART modules and links to the UART-related MSPM0 SDK code examples. The closest example in the SDK for this example is probably uart_echo_interrupts_standby where the "UART RX/TX echos using interrupts while device is in STANDBY mode".

      This MSPM0 example is similar, but not identical to the being ported. This example simply echoes the data received back on the device's TX pin. A small adjustment to the C code will allow us to match the original example.

   3. Import and modify the example.

      Once a similar example is found, Open CCS and import the code example by going to Project > Import CCS Projects... and navigate it to the MSPM0 SDK example folder. Import the example. Here is the uart_echo_interrupts_standby example imported. This is a SysConfig project, so the main C file is simple. It first calls the SysConfig driverlib initialization which is a function autogenerated by SysConfig to configures the device. Then it enables the UART interrupt. Finally it goes to sleep waiting for any UART transaction. If it receives a UART transaction, it responds with "Hello World!".

      Figure 2-6 uart_echo_interrupts_standby

      To see the SysConfig configuration, open the .syscfg file, which opens on the SYSCTL tab by default. For detailed guide on using SysConfig, see the SysConfig Guide in the in the MSPM0 SDK.

      This example already has the UART peripheral set up, so there is no need to change any of the configurations found in this file. If desirable, it is possible to change the settings like the clock source, clock divider, the target baud rate, or others. For this migration demonstration, the configuration will be left the same.

      Figure 2-7 Sysconfig UART Tab

      This example also utilizes some GPIOs that are not featured in the Microchip example. These GPIOs are simply used for debugging purposes, and one of them drives and LED. These can be left in for the sake of the demonstration, or removed if this is preferable.

      Figure 2-8 Sysconfig GPIO Tab

      When the project is saved and rebuilt, SysConfig updates the ti_msp_dl_config.c and ti_msp_dl_config.h files for the example. At this point, the example hardware configuration has been modified to match the full functionality of the original software being ported. The only remaining effort is application-level software to check for incoming UART bytes totoggle the LED and respond with "Hello World!". This is accomplished by editing a small amount of code in the uart_echo_interrupts_standby.c file.

      Figure 2-9 uart_echo_interrupts_standby.c

      Two changes are made to the application code. First, the message array must be initialized so the device can respond to UART messages properly. For this, the following line is inserted below the initialization of gEchoData:

      static uint8_t gMessage[12] = {'H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'};

      The second step actually processes the data send using a for loop and a blocking version of the UART transmit function, so only one character is sent at a time and there is no data collision in the Tx buffer. This is accomplished by adding the below code to the UART RX ISR:

      for(int i = 0; i < 12; i++){
                      DL_UART_Main_transmitDataBlocking(UART_0_INST, gMessage[i]);
      }

5. Debug and verify.

   The following figures demonstrate the correct functionality of the code example. As shown in the first image, when a UART character is sent to the LP-MSPM0C1104 using a terminal program on a PC, the device responds with "Hello World!".

   In the second image, logic analyzer captures show the device's RX and TX line, showing the incoming character, then the outgoing "Hello World!".

   With each received character, the on-board LED will toggle on and off.

   Figure 2-10 Logic Analyzer Capture
   Figure 2-11 Serial Terminal

   The software has successfully been ported! If this was just the first peripheral of many, continue to repeat this process and use SysConfig to combine each block.