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:
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.
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 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 (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 (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 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.
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 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)
- Data Compression (zlib)
- MQTT (Eclipse Paho)
- MQTT (wolfMQTT)
- Networking (TCP/IP)
- SSL/TLS (wolfSSL)
- Wireless (Wi-Fi)
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:
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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:
- Install MPLAB Harmony 3 Launcher
- Install MPLAB Harmony 3 Framework for MPU Development
- SAM9X60-EK and MPLAB Harmony 3 Development
- ATSAMA5D27-SOM1-EK1 and Harmony 3 Development