MPLAB® Harmony Flexibility

Libraries are only useful to you if they are flexible enough to be used to solve your design problems. MPLAB® Harmony libraries are flexible enough to support the variety of different environments that may be required.

Supported Configurations:


Super-Loop Polled

In a Super-Loop Polled system, all active state machines, including the peripheral drivers, must periodically poll for the events important to their job. An event is signaled when a flag is set by hardware using a peripheral interrupt event (interrupt events can be flagged without interrupts enabled), or by software.

polled.jpg
Click image to enlarge.

Interrupt-Driven

In an Interrupt-Driven system, a peripheral driver state machine uses its associated peripheral interrupt service routines (ISRs) to respond to events. These events are immediately processed by the ISR as they occur (no polling required).

The interrupt configuration file (system_interrupt.c) implements the raw ISR “vector function” that calls an interrupt driven module’s state machine or “Tasks” function. As long as the tasks function is carefully implemented so as to be interrupt safe, it does the same thing whether it is polled or interrupt driven. The only logical difference is whether or not the driver enables the interrupt.

interrupt.jpg
Click image to enlarge.

A peripheral driver is made interrupt-driven by setting its "interrupt mode" to "true". This is done in the “system_config.h” file. (example: #define DRV_TMR_INTERRUPT_MODE true)

In this example, the Timer 1 interrupt service routine (ISR) stub calls the timer driver’s “Tasks” function. In a polled system, the timer driver’s tasks would be called by the super-loop (implemented by the “SYS_Tasks()” function). Since “SYS_Tasks” and the ISR stub are both implemented as part of the system configuration, the library code stays the same in both cases. As long as it checks the flag first, it can be polled or interrupt driven. The library is designed to be flexible enough to do either.

code3.jpg

Less flexible, more optimized implementations are possible, but this example illustrates the concept.


RTOS Based

This same sort of flexibility extends to RTOS (Real-Time Operating System) support. In an RTOS environment, instead of having a single main loop, the configuration will have multiple “deamon” threads, each with its own loop. Most of the time, you will still want drivers to be interrupt driven. Interrupts usually support the best real-time response latency and hardware usually provides mechanisms for setting interrupt priorities. And, an RTOS usually provides the ability to prioritize the threads that would otherwise be polled.

MPLAB® Harmony libraries are RTOS safe. The Operating System Abstraction Layer (OSAL) will help you integrate the RTOS of your choice with these libraries.

rtos.jpg

To view the following video full screen, click on the video title (view on YouTube).

The Operating System Abstraction Layer (OSAL) is a lightweight OS Compatibility layer. It supports a minimal feature set extracted from many different RTOS products to enable maximal RTOS compatibility. Its focus is on providing mechanisms for safe operation of libraries in a multi-threaded environment.

The primary mechanisms used to provide thread safe operation are:

  • Mutexes
  • Semaphores
  • Critical Sections
  • Memory allocation

Static or Dynamic Drivers

An MPLAB® Harmony driver may control a single instance of a hardware peripheral (static driver) or may control multiple instances of a peripheral (dynamic driver).

In a static driver implementation, each peripheral instance is controlled by its own dedicated driver. For example, you cannot use the USART 2 driver to control USART 1. Note that each instance of a specific static driver requires a certain amount of program memory to implement the driver. In other words, two static drivers for a specific peripheral consume twice as much program memory as one static driver for that peripheral.

static.jpg
Click image to enlarge.

In a dynamic driver implementation, many peripheral instances can be controlled by the same driver. This capability obviously makes a dynamic driver bigger (consumes more program memory) than its associated static driver, but only one “copy” of it is needed (not one driver for each instance).

dynamic.jpg
Click image to enlarge.

When only one peripheral instance is needed, a static implementation is appropriate. When multiple instances are needed, a dynamic implementation may be a better choice because it may use less program memory than multiple static implementations.

MPLAB® Harmony peripheral driver libraries will provide just a static implementation, just a dynamic implementation, or both types depending on the specific peripheral. In any case, the API for static and dynamic drivers will be similar if not the same.

Dynamic driver example:… DRV_USART_ReadByte()
Static driver example:……. DRV_USART0_ReadByte()


Single-Client or Multi-Client Drivers

You might have a need for multiple "client" modules to use the same instance of a peripheral at the same time. To manage this need, MPLAB® Harmony has driver implementations that are intelligent enough to manage requests from multiple clients. This is particularly useful for “bus” type peripherals such as UARTs, I2C and SPI. However, writing a driver that can support multiple clients requires additional resources (code and data) and has implications on the API. To make multi-client support possible at all, the API must be designed to be multi-client and must be common across all implementations.

dynamic_multi.jpg
static_multi.jpg
Click image to enlarge.

On the other hand, your needs may be simpler than that. Single client drivers are also available to help reduce the amount of code and data storage needed for your system.

static_single.jpg
Click image to enlarge.

To view the following video full screen, click on the video title (view on YouTube).

20th Annual
Microchip MASTERs Conference 2016
Register now - Deadline: July 29

JW Marriott Desert Ridge Resort-Phoenix, AZ

© 2016 Microchip Technology, Inc.
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.