There are four 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 Application Programming Interfaces (APIs).
- Timer instance 1 (not Timer1) is started with DRV_TMR1_Start()
- Timer instance 2 (not Timer2) is started with DRV_TMR2_Start()
- etc…
- The interrupt vector is loaded with an Interrupt Service Routine (ISR) 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, the code must specify the explicit timer being used.
Details for using static timer drivers.
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 the ISR for the particular timer requesting the interrupt.
- The 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 any time.
- 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.
Details for using dynamic timer drivers
Timer System Service
One timer can be set as the system timer using the Harmony System Service. The one system timer can provide the following services:
- Schedule multiple 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.
Details for using Timer System Service
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?
Access Method |
Benefits | Limitation | When is it Used |
---|---|---|---|
Static driver | Easiest to understand and use. Fastest possible interrupt response. |
No hardware (HW) abstraction, the APIs must include Timer number. |
Applications not needing to share timers nor needing HW abstraction. |
Dynamic driver | Allows application code to be hardware independent. 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. |
Timer System Service |
Allows one timer to be shared among many tasks. |
Minimum interrupt period is 1 millisecond. |
Applications with more timer tasks than the number of timers on the PIC 32. |
PLIB | Same as a static driver. | Same as a static driver. | Not commonly used. |