Developing Applications with MPLAB® Harmony v3 Software Framework for MPUs
Introduction
MPLAB® Harmony v3 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 microprocessors (MPUs). Developers can choose the level of development that best suits their applications. The framework includes many example applications to enable developers to get started quickly.
Why Develop with MPLAB Harmony v3 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.
MPLAB Harmony v3 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.
Development Model
To address the diverse requirements of software developers, MPLAB Harmony v3 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.
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.
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.
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.
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.
Queue Support
Device Drivers allow the 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 below) 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.
System Services
System Services manage shared resources.
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.
A System Service manages all communications with a device driver such as opening, registering callbacks, and event handling.
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.
- Amazon Web Services (AWS)
- Audio
- Bootloader
- Bluetooth
- Cryptography
- Data Compression (zlib)
- Graphics
- MQTT (Eclipse Paho)
- MQTT (wolfMQTT)
- Networking (TCP/IP)
- SSL/TLS (wolfSSL)
- Touch
- USB
- Wireless (Wi-Fi)
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:
Operating System Abstraction Layer (OSAL)
MPLAB Harmony v3 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 v3 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
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 v3 software libraries are hosted on the MPLAB Harmony v3 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 Code Configurator (MCC) or your favorite Git client.
Device Family Package (dev_packs)
The dev_packs package contains device-specific source code for direct hardware access. The package contains information provided by Microchip Technology and Arm® to describe the core and peripherals.
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.
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.
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.
Summary
The MPLAB Harmony v3 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.
Learn More
- SAMA5D29-Curiosity Development Board
- Read and Write Boot Configuration Word using SAM-BA ISP
- Configure and Build at91bootstrap for a MPLAB® Harmony v3 Project with MPLAB X IDE
- Getting Started with MPLAB® Harmony v3 Development: CSP Application: pio_led_on_off_interrupt
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from SQI™ Flash Memory
- Writing MPLAB® Harmony v3 Application and at91bootstrap to SQI™ Flash Memory using SAM-BA® ISP
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from SD Memory Card
- Copy MPLAB® Harmony v3 Application and at91bootstrap to SD Memory Card
- SAMA7G54-EK Evaluation Kit
- Getting Started with MPLAB Harmony v3 Development: CSP Application: pio_led_on_off_interrupt
- Configure and Build at91bootstrap for a MPLAB® Harmony v3 Project with MPLAB X IDE
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from NOR Flash (QSPI) Memory
- Writing MPLAB® Harmony v3 Application and at91bootstrap to NOR Flash (QSPI) Memory using SAM-BA ISP
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from e.MMC Flash Memory
- Writing MPLAB® Harmony v3 Application and at91bootstrap to e.MMC Flash Memory using SAM-BA ISP
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from SD Memory Card
- Copy MPLAB® Harmony v3 Application and at91bootstrap to SD Memory Card
- SAM9X60-Curiosity Development Board
- Migrating a MPLAB® Harmony v3 Application from the SAM9X60-EK to SAM9X60-Curiosity: rtt_periodic_timeout
- Getting Started with MPLAB® Harmony v3 Development: CSP Application: rtt_periodic_timeout
- Configure and Build at91bootstrap to Load a MPLAB® Harmony v3 Application from NAND Flash Memory
- Writing MPLAB® Harmony v3 Application and at91bootstrap to NAND Flash Memory using SAM-BA® ISP
- SAM9X60-EK Evaluation Kit
- Getting Started with MPLAB® Harmony v3 Development: CSP Application: rtt_periodic_timeout
- Configure and Build at91bootstrap for a MPLAB® Harmony v3 Project with MPLAB X IDE
- Configure and Build at91bootstrap to Load an MPLAB® Harmony v3 Application from NAND Flash Memory
- Writing MPLAB® Harmony 3 Application and at91bootstrap to NAND Flash Memory Using SAM-BA ISP
- Configure and Build at91bootstrap to Load an MPLAB® Harmony v3 Application from NOR Flash (QSPI) Memory
- Writing MPLAB® Harmony 3 Application and at91bootstrap to NOR Flash (QSPI) Memory using SAM-BA ISP
- Configure and Build at91bootstrap to Load an MPLAB® Harmony v3 Application from SD Memory Card
- Copy MPLAB® Harmony 3 Application and at91bootstrap to SD Memory Card