Getting Started With MPLAB® Harmony v3 Drivers and Middleware on PIC32MZ EF MCUs Using FreeRTOS

Last modified by Microchip on 2023/11/10 11:01

Objective

MPLAB® Harmony v3 is a flexible, fully integrated embedded software development framework for 32-bit microcontrollers (MCUs) and microprocessors (MPUs).

MPLAB Harmony v3 includes MPLAB Code Configurator (MCC) tool, a set of modular peripheral libraries, drivers, system services, middleware, and numerous example applications, all of which are designed to help you quickly and easily develop powerful and efficient embedded software for Microchip’s 32-bit PIC® and SAM devices.

This tutorial shows you how to use MCC to create an application that gets you started in developing applications on PIC32MZ EF MCUs using MPLAB Harmony v3 software framework with FreeRTOS™.

Information

In this tutorial, you will use the Arm® Cortex® Microcontroller Software Interface Standard - Real-Time Operating System (CMSIS-RTOS) adoption of FreeRTOS version 10.2.0. FreeRTOS is a market-leading RTOS for microcontrollers having ports for Microchip’s MCUs. The FreeRTOS kernel is released under the MIT open-source license.

Harmony v3 drivers support Asynchronous and Synchronous modes of operation.

Asynchronous Mode

  • Non-blocking Application Program Interfaces (APIs)
  • Works seamlessly in bare-metal and RTOS environments
  • Interrupt and thread-safe

Synchronous Mode

  • Blocking APIs
  • Suitable for use in an RTOS environment
  • Interrupt and thread-safe
Information
  • Blocking API: It hangs up execution flow until it has performed its function and returns a result.
  • Non-blocking API: It receives the application request and returns immediately without providing the result. The result of the non-blocking API call is provided separately through an asynchronous event. The application verifies the event to take further action.
  • Interrupt-safe: A sequence of code is said to be interrupt-safe when the occurrence of an interrupt(s) doesn't alter the output or functional behavior of the code. To be interrupt-safe, the sequence of code in consideration must be atomic (indivisible and uninterruptible), and the relevant interrupts must be disabled before entering the sequence.
  • Thread-safe: In an RTOS-based environment, it is possible a driver and its clients may each run in its own RTOS thread. If the RTOS is preemptive, then the scheduler may interrupt any of these threads at any time and switch to another. If the other thread happens to also non-atomically access the same shared resource or executes the same critical section of code, that section of code must be guarded and made atomic. The sequence of code with such guards is known as thread-safe code.

In this tutorial, you will use Harmony drivers in the Synchronous mode of operation and Harmony middleware libraries with FreeRTOS.

The application makes use of the Curiosity PIC32MZ EF 2.0 Development Board and I/O1 Xplained Pro Extension Kit (sold separately).

The application reads the current room temperature from the temperature sensor on the I/O1 Xplained Pro Extension Kit. The temperature reading is displayed on a serial console periodically every second. Further, the application writes the temperature readings to EEPROM and to a file in a USB thumb drive whenever the USB thumb drive is connected. Also, an LED (LED1) is toggled every time the temperature is displayed on the serial console and an LED (LED2) is in an ON state when a USB thumb drive is connected.

The application you create will utilize:

  • I²C Synchronous Driver to read the temperature from a temperature sensor and store/retrieve to/from EEPROM.
  • Universal Synchronous Asynchronous Receiver Transmitter (USART) Synchronous Driver to print the temperature values on a COM (serial) port terminal application running on a PC.
  • USB High-Speed Driver, USB Host Middleware, and File System Service libraries to write the temperature readings to a file in a USB thumb drive whenever a USB thumb drive is connected.
  • GPIO Peripheral Library to toggle an LED.
  • FreeRTOS library to create middleware, application threads, and intercommunicate between these threads.

In the process, the lab will also demonstrate the use of callback functions.

Back to Top

Two Ways to Use This Tutorial

  1. Create the project from scratch:
    • Use the provided source files and step-by-step instructions below.
  2. Use the solution project as an example:
    • Build the solution project and download it to the Curiosity PIC32MZ EF 2.0 Development Board to observe the expected behaviour.

Lab Objectives

  1. Create an MPLAB X IDE Harmony v3 project for a PIC32MZ EF microcontroller from scratch.
  2. Use MCC to configure and generate Harmony Synchronous Driver code for the I²C and USART peripherals.
  3. Use MCC to configure and generate Harmony Driver for the High-Speed USB peripheral.
  4. Use MCC to configure and generate Harmony libraries for the USB Host Middleware and File System Service.
  5. Along with the configuration of drivers for the I²C and USART peripherals, use MCC to configure and generate Harmony v3 peripheral libraries for the I²C, Universal Asynchronous Receiver Transmitter (UART), and GPIO peripherals.
  6. Use MCC to configure the application, middleware, and system service threads using FreeRTOS.
  7. Use the Harmony v3 Middleware Libraries, Drivers, Peripheral Library APIs, and FreeRTOS APIs to implement the application.

Back to Top

Materials

Hardware Tools

Information

The Curiosity PIC32MZ EF 2.0 Development Board includes an onboard PICkit On Board 4 (PKOB4). No external tools are necessary to program or debug the PIC32MZ2048EFM144. For programming/debugging, the PKOB4 connects to the host PC through the USB micro-B connector on the Curiosity PIC32MZ EF 2.0 Development Board.

Hardware Connection Setup

Hardware Setup

Figure 1: Hardware Setup

​​

Information

Apart from the hardware tools listed above, the following items are required:

  • USB Type-A male to Micro-B male cable for programming/debugging.

Connection Diagram

The application has the temperature sensor and EEPROM connected to the PIC32MZ EF over the I²C interface and the console (serial terminal) on a PC connected over the USART interface (through USB to USART converter).

Connection Diagram

Figure 2: Connection Diagram

Hardware Modification

Information

IO1 Xplained Pro features Microchip’s AT30TSE758 temperature sensor chip with an 8-kbit serial EEPROM. The temperature sensor has two Two-Wire Interfaces (TWI) addresses, one for the temperature sensor and one for the EEPROM. The A2 address line of TWI must be soldered to zero. This is done to modify the address of the EEPROM on the I/O1 Xplained Pro Extension Kit so that it does not conflict with the address of the EEPROM on the Curiosity PIC32MZ EF 2.0 Development Board. The modification changes the address of the temperature sensor to 0x4B and EEPROM to 0x50. These modified addresses are used in this tutorial.

The hardware modification on the IO1 Xplained Pro is shown in Figure 3.

Hardware Modification

Figure 3: Hardware Modification

Software Tools

Information

This project has been verified to work with the following versions of software tools:

Because we regularly update our tools, occasionally you may discover an issue while using the newer versions. If you suspect that to be the case, we recommend that you double-check and use the same versions that the project was tested with.

For this lab, download the following repositories from GitHub:

  • CSP: The following table shows the summary of contents.

FolderDescription
appsExample applications for CSP library components
archInitialization and starter code templates and data
docsCSP library help documentation
peripheralPeripheral library templates and configuration data
  • DEV_PACKS: The following table shows the summary of contents.
FolderDescription
MicrochipPeripheral register specific definitions
armCore Specific Register Definitions (CMSIS)
  • CORE: The following table shows the summary of contents.
FolderDescription
appsExample applications for core library components
configCore module configuration scripts
docsCore module library help documentation
driverCore module peripheral device drivers
osalMPLAB Harmony Operating System Abstraction Layer
systemMPLAB Harmony system services
templatesApplication and system file templates
  • BSP: The following table shows the summary of contents.
FolderDescription
boardsBSP templates and configuration data
  • USB: The following table shows the summary of contents.
FolderDescription
appsExample applications for USB library components
configUSB module configuration scripts
docsUSB module library help documentation
driverUSB module driver source files
middlewareUSB middleware source files
templatesApplication and system file templates
FolderDescription
CMSISCMSIS-FreeRTOS related files
CMSIS/RTOS2/FreeRTOS/ConfigCMSIS-FreeRTOS configuration file
CMSIS/RTOS2/FreeRTOS/ExamplesCMSIS-FreeRTOS example projects
CMSIS/RTOS2/FreeRTOS/SourceCMSIS-FreeRTOS source code
ConfigFreeRTOS Kernel configuration file
DemoFreeRTOS demo projects
DoxyGenSource of the documentation
LicenseFreeRTOS Kernel license text file
SourceFreeRTOS Kernel source code
UtilitiesUtility programs

Back to Top

Overview

This lab shows you how to create an MPLAB Harmony v3 project from scratch, to configure and generate:

  • Harmony v3 Peripheral Libraries code for the TC, I²C, UART, and GPIO peripherals
  • Harmony v3 Synchronous Driver code for the I²C and USART peripherals
  • Harmony v3 Driver code for the USB High-Speed peripheral
  • Harmony v3 Library code for the USB Host Middleware and File System Service
  • Harmony v3 application, middleware, and system service threads using FreeRTOS

It demonstrates the reading of temperature sensor values from the temperature sensor available on the I/O1 Xplained Pro Extension Kit periodically and displays it on a serial console. It further writes the temperature readings to EEPROM and to a file in a USB thumb drive whenever a USB thumb drive is connected. When a character is entered on the console, the last five written temperature values are read from the EEPROM and displayed on the console. Also, an LED (LED1) is toggled every time the temperature is displayed on the serial console and an LED (LED2) is in an ON state when a USB thumb drive is connected.

The application functionality is divided into the following threads.

Threads to run the system service and middleware tasks:

  1. File System Layer Thread – To maintain and run the File System service tasks and functionalities.
  2. USB High-Speed Driver Thread – To maintain and run the driver's state machine.
  3. USB Host Layer Thread – To maintain and run the USB Host Stack Layer's state machine.

Application Threads:

  1. Sensor Thread – To read and display temperature periodically.
  2. EEPROM Thread – To write the temperature values to EEPROM and display them on the COM (serial) port terminal when requested by the user.
  3. User Input Thread – To read the character entered on the COM (serial) port terminal.
  4. USB Thread - To write temperature readings to a file in a USB thumb drive whenever a USB thumb drive is connected.

Sensor thread, EEPROM thread, USB thread, and the User Input thread run the corresponding application function in an infinite loop. USB High-Speed Driver thread, USB Host Stack Layer thread, and File System Service thread run the corresponding peripheral driver, middleware library, and system service library tasks in an infinite loop.

Following the creation of all these threads is when the FreeRTOS scheduler is invoked. The scheduler performs the preemptive scheduling of these threads based on the waiting, ready, and running state of each of them. You will use MCC to generate the template files for the four application threads. Also, MCC will generate the USB High-Speed driver thread, USB Host Stack Layer, and File System Service thread files.

The Application Threads

Figure 4: The Application Threads

​​​

Once the scheduler is invoked the threads start to run based on the default scheduling method (preemptive).

The File System thread runs the File System Service library task function SYS_FS_Tasks. The SYS_FS_Tasks function runs the underlying File System Service layers to enable media (thumb drive) mount, file opening, and read/write operations on the opened file(s).
The File System thread runs the task function SYS_FS_Tasks for a pass and yields control (blocks) for 10 milliseconds to allow other threads to run.

The USB High-Speed driver thread runs the USB high-speed driver task function DRV_USBHS_Tasks. The DRV_USBHS_Tasks function enables the USB interrupt, soft-reset the USB physical layer, and waits for the USB device to attach and detach actions in Polling mode. Further, it runs the state machine to detect events, read/write data from the USB device. The USB High-Speed driver thread runs the task function DRV_USBHS_Tasks for a pass and yields control (blocks) for 10 milliseconds to allow other threads to run.

The USB Host thread runs the USB host layer task function USB_HOST_Tasks. The USB_HOST_Tasks function enables USB host bus, USB device connection, reads USB device descriptors and maintains the USB Host stack layer state machine. The USB Host thread runs the task function USB_HOST_Tasks for a pass and yields control (blocks) for 10 milliseconds to allow other threads to run.

By default, the sensor thread is blocked and wakes up every time the temperature sampling period gets expired. Once active, the sensor thread reads the latest room temperature value from the temperature sensor and prints the same on the serial terminal. It also notifies the EEPROM thread through the RTOS queue of the availability of the latest temperature value which needs to be stored in the EEPROM. Once notified, the sensor threads block again for the temperature sampling period duration.

By default, the EEPROM thread is waiting for an event to occur. It wakes up when there is an event in the RTOS queue to either write the latest temperature value or read the last five temperature values. Based on the event, the EEPROM thread performs writing or reading and goes back to the waiting state.

By default, the USB thread is waiting for a USB thumb drive connection. It wakes up when there is a USB thumb drive connected to the development board. The USB thread performs writing temperature readings to a file and goes back to the waiting state once after writing is finished.

By default, the user input thread is blocked to receive a character on the UART receive line. Once a character is received, the user input thread becomes active and submits an EEPROM read request to the EEPROM thread through the RTOS queue to read the last five temperature values stored in EEPROM. After serving the user input request, the thread goes back to the blocking state to receive another character on the USART receive line.

The Thread Functioning

Figure 5: The Thread Functioning

Back to Top

Lab Source Files and Solutions

This ZIP file contains the completed solution project for this lab. It also contains the source files needed to perform the lab as per the following step-by-step instructions (see the "Procedure" section on this page).

Information

The contents of this ZIP file need to be placed in the below folder:

<Any directory of your choice>/
(example Directory = C:/microchip/harmony/v3)

Note:

  1. The project location of a Harmony v3 project is independent of the location of the Harmony Framework path (i.e. you need not create or place a Harmony v3 project in a relative path under the Harmony v3 framework folder). The project can be created or placed in any directory of your choice.
  2. The point above is true because when created, a Harmony v3 project generates all the referred source/header files and libraries (if any) under the project folder.
  3. Both points above contrast with Harmony v2 project location. In Harmony v2, the project was supposed to be created in a location under the Harmony framework.

ZIP

Extracting the ZIP file creates the following folders:

  • getting_started_middleware contains the lab solution (in the firmware folder) and source files (in the dev_files folder).
    • dev_files contains subfolder middleware_drivers_freertos_pic32mz_ef_curiosity_v2 containing application source files and other support files (if any) required to perform the lab (see "Procedure" section below).
    • firmware contains the completed lab solution project. It can be directly built and programmed on the hardware to observe expected behavior.

Back to Top

Procedure

Information

You must complete all of these steps before you can build, download, and run the application.

Lab Index

Step 1: Create Project and Configure the PIC32MZ EF

  • Step 1.1 - Create MPLAB Harmony v3 Project using MPLAB X IDE
  • Step 1.2 - Verify Clock Settings
  • Step 1.3 - Configure BSP

Step 2: Configure Synchronous I²C and USART Drivers

  • Step 2.1 - Configure I²C Driver and I²C pins
  • Step 2.2 - Configure USART Driver and UART pins

Step 3: Configure USB High Speed Driver, USB Host Middleware and File System Service

  • Step 3.1 - Configure USB High Speed Driver
  • Step 3.2 - Configure USB Host Middleware and File System Service

Step 4: Configure Application Threads

  • Step 4.1 - Rename the default main file
  • Step 4.2 - Configure Application Threads and FreeRTOS

Step 5: Generate Code
Step 6: Add Application Code to the Project
Step 7: Build, Program, and Observe the Outputs

Back to Top