Introduction to MPLAB® Harmony 3 Software Framework for Microchip Technology 32-bit Microprocessor Units (MPUs)

Introduction

This training is for the embedded systems software developer who wishes to use the MPLAB® Harmony 3 Software Framework with Microchip Technology’s 32-bit Microprocessor Units (MPUs) (SAM9x60, SAMA5D2). No prior knowledge of Harmony or MPUs is assumed.

Why Develop with MPLAB Harmony 3 Software Framework for MPUs?

Software developers around the world have diverse requirements. The items on the top of their list are:

  • The ability to quickly, and accurately, develop applications.
  • Software libraries that are modular to choose only what they need.
  • To develop at the level of abstraction of their choice.
  • To choose between bare metal development, state machine model, or Real-Time Operating System (RTOS).
  • To be able to write portable code that can easily be configured and reconfigured for multiple devices and changing requirements.
  • To be maintainable.

The MPLAB Harmony 3 Software Framework strives to achieve each of these goals by providing the software developer with source code libraries and tools to aid in the management, configuration, and generation of source code for microprocessors and microcontrollers. The goal of the Software Framework is to enable developers to develop software applications quickly and accurately. Application examples are supplied as part of the framework to enable the developer to get started quickly.

Subjects covered in this topic:


Development Model

To address the diverse requirements of software developers, the MPLAB Harmony 3 Software Framework is organized in layers. These modules are portable, compatible with each other, and they communicate and exchange data and information with each other. This modular method allows the developer to choose the level of development to suit their application requirements.

dev_model.png
Figure 1

From the lowest to the highest, each successive layer builds on the previous one. The developer can choose to develop basic applications using the lowest layer components (device initialization and peripheral libraries). Alternatively, they can develop more advanced applications using the higher layers (middleware and RTOS) that provide a greater level of abstraction and hardware independence. The major benefits of the higher layers are greater flexibility and portability of source code.

Below is a description of each of the layers, from lowest to highest.

Device Configuration

Device Configuration software libraries allow the software developer to configure and initialize the basic functionality of a device. This layer is useful for the developer who already has their own application framework or operating system and just needs to configure and initialize the device.

dev_model_device_config.png
Figure 2
MPLAB Harmony 3 GitHub Repository Information:

The Device Configuration software libraries are part of the Chip Support Package (CSP) and are dependent on the Device Family Package (dev_packs) for device information.

Peripheral Libraries

Peripheral Libraries (PLIBs) allow the software developer to initialize and control the peripherals of a device. This layer is useful for the developer who requires simple and direct control of peripherals to allow them to write simple applications.

dev_model_plib.png
Figure 3
MPLAB Harmony 3 GitHub Repository Information:

The PLIBs are part of the csp and are dependent on the dev_packs for device information.

Device Drivers

Device Drivers (or simply drivers) provide the software developer with advanced capabilities and a higher level of abstraction when communicating with peripherals. Drivers reduce hardware dependence and support greater portability by providing the same Application Programming Interface (API) across devices. When used in conjunction with System Services (see below) they offer buffer queuing, peripheral and resource sharing, portability, and interoperability.

dev_model_drivers_1.png
Figure 4

Support for multiple clients: Device Drivers allow multiple clients to communicate with a Device Driver instance. For example, there can be multiple application clients to an instance of an I2C device driver having multiple I2C peripherals. I2C peripheral-specific information is all handled by the I2C device driver based on the client that submitted the request.

dev_model_drivers_2.png
Figure 5

Queue support: Device Drivers allow queuing of multiple requests. Each instance of a Device Driver has a dedicated queue. Requests submitted by all of the clients of the instance of the Device Driver are queued in the Device Driver instance queue. Queuing allows the application to submit requests before waiting for the Device Driver to finish the previous requests. For each submitted request, the application can choose to get notified or poll the status of the submitted request using the handle provided by the Device Driver for the submitted request.

Cache management: Device Drivers manage cache-related operations on devices that have cache, thereby simplifying application development.

Device Driver and PLIB Independence: The software developer can choose to write applications that communicate to a device driver and PLIB. As long as the application does not attempt to share one instance of the PLIB and its associated peripheral with a device driver or system service.

For example, (see Figure 6) an application can directly access a FLEXCOM0 PLIB. The application is limited to only one instance of the FLEXCOM0 PLIB. Whereas the application can also access an I2C Driver that communicates with the FLEXCOM1 PLIB. Multiple I2C devices can be accessed through the driver.

dev_model_drivers_3.png
Figure 6
MPLAB Harmony 3 GitHub Repository Information:

Device Drivers are part of the Core Package (core) and are dependent on the csp and dev_packs for device information.

System Services

System Services manage shared resources.

dev_model_services.png
Figure 7

For example, consider a case where multiple clients require timing services. One client requires a delay. A second client requires a notification at a specified interval.

One option would be for each client to use a separate timer peripheral. However, when using this option the software developer would have to ensure each client has exclusive access to each timer peripheral. And if more clients require timing services, there is a real possibility that the developer will run out of timer peripherals.

A better option would be to use the Timer System Service. It manages a shared resource, in this example a timer peripheral. The Timer System Service provides a well-defined interface that protects the shared resource from potential conflicts and manages requests from multiple clients.

system_services_example.png
Figure 8

A System Service manages all communications with a device driver such as opening, registering callbacks, and event handling.

MPLAB Harmony 3 GitHub Repository Information:

System Services are part of the Core Package (core) and are dependent on the csp and dev_packs for device information.

Middleware

Middleware packages provide the software developer with software libraries for communications (TCP/IP networking, USB, Wi-Fi®, Bluetooth®), Internet of Things (IoT) (Amazon Web Services (AWS), MQTT), Security (Cryptographic routines, SSL/TLS), Graphics, Touch, Bootloaders, and Audio.

The Middleware libraries are dependent on Device Drivers and System Services. They provide abstract interfaces that are isolated from hardware details and provide hardware independence and resource sharing. Applications written using middleware libraries are easily ported to different devices.

dev_model_middleware.png
Figure 9
MPLAB Harmony 3 GitHub Repository Information:

Middleware software libraries are individually packaged by function.

Real-Time Operation System (RTOS)

RTOS provides multitasking, real-time scheduling, multi-thread capabilities, inter-task communications, and many more features. They also greatly simplify the development of complex applications. Presently, there are two RTOS’s that are supported for MPUs:

By default, the FreeRTOS RTOS is downloaded by the MPLAB Harmony 3 Content Manager when the Core package is downloaded.

dev_model_rtos.png
Figure 10

Operating System Abstraction Layer (OSAL)

MPLAB Harmony 3 drivers, system services, and middleware software libraries are designed to communicate with the designer’s choice of RTOS through an Operating System Abstraction Layer (OSAL). The OSAL provides a predefined set of functions and types that match common synchronization and communication services that an RTOS typically provides. It is designed to be a lightweight abstraction model and deliberately excludes the much broader depth and breadth of services that a fully-fledged RTOS provides. As such the interface defines only those core functions necessary for the MPLAB Harmony 3 drivers and middleware to operate in a multi-threaded environment.

The OSAL can be used without an RTOS, allowing for bare metal or state machine application development.

MPLAB Harmony 3 GitHub Repository Information:

The OSAL libraries are available for the RTOS of the developer’s choice and can be downloaded using the MPLAB Harmony 3 Configuration Manager (MHCM).

Development Model – Summary

In summary, the modular development model allows software developers to choose the layers that fit the situation. Since the layers build on one another, the developer can add successive layers as requirements change. This model provides flexibility for the developer to scale their project(s) up or down in complexity without extensive rewriting of source code.


Repository

The MPLAB Harmony 3 software libraries are hosted on the MPLAB Harmony 3 GitHub repository and organized in packages (also known as modules). They contain device initialization, peripheral initialization and control, and device drivers. Middleware libraries support displaying graphics, networking capabilities, USB connectivity, audio playback and recording, Bluetooth connectivity, and cryptography. Each of the libraries provides support for RTOS.

The modular organization allows the developer to select only the packages that are needed for a given project. They can be managed using the MPLAB Harmony 3 Content Manager or your favorite Git client.

install_harmony_framework_03.png
Figure 11

Device Family Package (dev_packs)

The dev_packs contains device-specific source code for direct hardware access. The package contains information provided by Microchip Technology and Arm Limited to describe the core and peripherals.

dev_packs Repository

Chip Support Package (CSP)

The CSP contains:

  • Software libraries that perform basic MPU device initialization and startup.
  • PLIBs that perform initialization, setup, operation, and status of peripherals.

The CSP depends on the dev_packs for the selected MPU device.

CSP repository

Chip Support Applications (csp_apps_<device>)

Example applications for the CSP demonstrate the control of peripherals using PLIBs with minimal external dependencies. They are located in separate repositories for each device. The naming convention is: csp_apps_<device>. For example, the CSP application examples for the SAM9X60 are located in the csp_apps_sam_9x60 package.

csp_apps_sam_9x60 repository
csp_apps_sam_a5d2 repository

Core Package (core)

The Core Package (core) contains device driver, system service, OSAL, and third-party software libraries.

The Core Package (core) depends on the csp and dev_packs for the selected MPU device.

By default, the FreeRTOS RTOS is downloaded by the MPLAB Harmony 3 Content Manager when the Core package is downloaded.

Core Package repository

Core Applications (core_apps_<device>)

Example applications for the Core Package (core) demonstrate the control of peripherals using Device Drivers with minimal external dependencies. They are located in separate repositories for each device. The naming convention is: core_apps_<device>. For example, the core application examples for the SAM9X60 are located in the core_apps_sam_9x60 package.

core_apps_sam_9x60 repository
core_apps_sam_a5d2 repository

Board Support Package (BSP)

The BSP contains the defines (names and attributes) of the features (clock configuration, pins, switches, and LEDs) of a selected evaluation kit.

The BSP depends on the csp and dev_packs for the selected MPU device.

BSP repository


Summary

The MPLAB Harmony 3 Software Framework is a comprehensive collection of software libraries and tools for the software developer to manage, configure, and generate source code for Microchip Technology branded MPUs. The developer can choose the level of development that best suits their application. The framework includes many example applications to enable the developer to get started quickly.


What’s Next?

Are you an MCU developer new to MPUs?

Learn more about the MPLAB ecosystem in the following topics:

If you would like to jump right in and get started with MPU Development with MPLAB Harmony 3 Software Framework:

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.