There are 4 methods of accessing a PIC32 timer with the MPLAB® Harmony Framework:
- Static Driver
- Dynamic Driver
- Timer System Service
- Peripheral Library (PLIB) Interface
Each of these methods has benefits and drawbacks. This page explains when each access method is best used. It may be useful for the reader to become familiar with the implementation of Static and Dynamic Timer Drivers as well as Timer System Services before continuing with this tutorial.
Static Timer Driver
Most users will recognize the static timer driver approach as the implementation frequently used in classic MCU applications. Static timers offer an easy to understand interface with low-latency interrupt response.
Static Timer Drivers have the following characteristics:
- Each timer is accessed with a unique set of APIs.
- Timer instance 1 (not Timer1) is started with DRV_TMR1_Start()
- Timer instance 2 (not Timer2) is started with DRV_TMR2_Start()
- The interrupt vector is loaded with your interrupt service routine when the project is built. This ISR cannot be changed at run-time. The ISR is executed immediately upon an interrupt.
- In order to access a timer, your code must specify the explicit timer being used.
Dynamic Timer Driver
When a timer is configured with a Dynamic Driver, the interrupt response and API access differ from those of Static Drivers.
Dynamic Timer Drivers have the following characteristics:
- All interrupts go to a shared interrupt vector which performs some error checking, then calls your interrupt service routine (ISR) for the particular timer requesting the interrupt.
- Your ISRs are assigned at run-time to the timer with a function call.
- The application program can change the ISR assigned for a timer at anytime.
- Program access to the timer is through the use of pointers (called handles).
- An application must OPEN a timer to obtain a handle.
- Once obtained, the handle is used as a parameter to all API functions for accessing timers.
- Using handles provides a layer of hardware abstraction allowing the user to write hardware independent and re-entrant code.
- Dynamic Drivers have a slower interrupt latency than Static Drivers due to the shared interrupt vector pre-processing.
- Dynamic Drivers provide the ability for the developer to create re-usable code.
Timer System Service
One timer can be set as the system timer using Harmony System Service. The one system timer can provide the following services:
- Schedule multiple interrupt service routines (ISRs) at separate time intervals based on the single System Timer.
- Initiate ISRs as either a one-shot or continuous events.
- Disable or Enable timer ISRs at run-time.
- Establish a system clock allowing:
- Non-blocking "delays" in the application code
- The measurement of timer intervals by the program
Timer PLIB Interface
For completeness, this site provides the APIs for the peripheral library (PLIB) function calls. All PLIB functions have corresponding static driver functions. It is highly unlikely application developers will find a need to used direct PLIB function calls.
Which Timer Library Should You Use?
|Benefits||Limitation||When is it Used|
|Static Driver||Easiest to understand and use.
Fastest possible interrupt response.
|No Hardware abstraction, the APIs
must include Timer number
|Applications not needing to share timers nor needing Hardware Abstraction|
|Dynamic Driver||Allows application code to be
ISRs can be changed at run-time.
|Interrupts have a longer latency
than Static Timers
|Applications requiring HW abstraction or have the need to dynamically change a timer's ISR|
|Allows one timer to be shared among
|Minimum interrupt period is
|Applications with more timer tasks than the number of timers on the PIC32|
|PLIB||Same as Static Driver||Same as Static Driver||Not Commonly Used|