What is a Core Independent Peripheral?

Core Independent Peripherals (CIPs) are peripherals that have been designed with additional capabilities to handle a variety of tasks without the need for intervention from the Central Processing Unit (CPU). Any time the CPU is needed to make a change to the embedded system (or handle a task of some sort), it will rely on instructions that you have written and will then be downloaded into the microcontroller’s program memory to tell the CPU exactly what to do.

CIPs automatically maintain some tasks within the system freeing the CPU to simply supervise the system, handle some other task in parallel or go into a lower power mode.

Microchip Technology has developed many 8-bit and 16-bit devices with CIPs. All of the currently available CIPs for 8-bit PIC^® and AVR^® microcontrollers are shown below in color code by peripheral category:

Each peripheral will have its own section with an overview and associated tutorials elsewhere in this wiki. At this point, we will concentrate only on the concept of "core independence".

The following example will be used to develop this concept.

A Simple Application Example Solved Two Ways

Let’s consider a very simple application where a single pin on a microcontroller is toggled HIGH/LOW.

This will essentially generate a square wave on the output pin of the microcontroller. Since there is no requirement to modify the duty cycle for this square wave, the task is handled in software by toggling the particular pin each time through a loop.

Now consider what would happen if a second task is added. In this case, every time an analog voltage connected to one of the microcontroller pins exceeds 1.1 V then a 2 ms pulse on another pin is generated. Here, a potentiometer connected to one of the microcontroller pins is used to control the analog voltage.

This additional task can be handled in a number of ways. We present two solutions. The first relies on user software implementing interrupts and the second uses CIPs.

Solution A: A Software Approach

Many microcontrollers feature some fundamental peripherals like a comparator that is used to determine when the input voltage exceeds 1.1 V and a timer that is used to time the output pulse. You would then write some code that would look like the image below.

In the image above, the software routine behaves as follows:

1. An interrupt is generated whenever the comparator input exceeds 1.1 V.
2. A software routine is used to check the priority of the interrupt and ensure that an interrupt with higher priority hasn’t occurred at the same time.
3. An interrupt service routine (ISR) associated with the comparator interrupt is then executed to:
   • Reset the Timer peripheral.
   • Load the Timer with a value that is based on the system’s main clock speed, which will cause the Timer to overflow at 2 ms.
   • The output pin is then driven HIGH to start the output pulse.
4. Once the Timer overflows at 2 ms, another interrupt is generated.
5. The software routine is used to check the priority of the interrupt and ensure that an interrupt with higher priority hasn’t occurred at the same time.
6. The Timer ISR is then called to:
   • Clear the Timer.
   • The output pin is then driven LOW to end the pulse.

The following image is an oscilloscope capture of the output from a microcontroller running the above software-based solution.

In the above image, the orange capture is the output when the input analog voltage exceeds 1.1 V and the blue signal is the toggling pin.
Note that the blue signal stops toggling at two points in and around the rising and falling edges of the orange signal. When the comparator input exceeds 1.1 V at point A, the first interrupt is generated. The CPU stops its current task (which in this case is toggling the output pin) and then enters the interrupt prioritization and ISR for the comparator. When the CPU returns from the ISR, it resumes toggling the output pin as shown by the single pulse at point B. At point C, the Timer overflows at 2 ms and generates the second interrupt. The CPU again stops toggling the output pin to enter the interrupt prioritization routine and then the Timer ISR. When the CPU returns from the Timer ISR, it again resumes toggling the output pin shown as point D.

Toggling an output pin is a very basic application and the interruption created may seem insignificant. However, imagine that the toggling pin is instead a more important task like sensing a user input, like a pushbutton press, or a sensor signal indicating an overcurrent situation, or possibly another interrupt that indicates a system critical event.

The system could be made more responsive by bench testing and modifying different parameters of the application like the system clock speed but there will always be some level of jitter using this type of solution.
Let’s instead consider a different approach to this application using CIPs.

Solution B: The CIP Approach

Many 8-bit microcontrollers from Microchip Technology feature the ability to interconnect signals within the device, which brings many advantages. Not only does this minimize the amount of noisy space-consuming external connections but these signals can be rerouted to interact with other peripherals. To this point, the comparator peripheral on many devices is able to interconnect with the Timer 2 with Hardware Limit Timer (HLT) peripheral.

The Timer 2 with HLT is a timer designed to count up to a user-specified value and then reset. The HLT capability adds an additional signal that can be connected to a number of sources such as an onboard clock, some peripherals, and even one of the pins on the microcontroller. This additional signal is used to START/STOP the timer increment. This Timer also features a number of modes of operation including the Monostable mode. The monostable mode can generate an output pulse for a defined period of time whenever triggered by this additional signal that can be connected to the on-chip comparator output.

Therefore, returning to our application, the analog input signal is routed into the comparator and then the output of the comparator is routed to the Timer 2 with HLT configured in Monostable mode. When the output of the comparator goes HIGH, indicating that the input voltage exceeds 1.1 V, Timer 2 with HLT will generate an output pulse that you have configured to last 2 ms.
This implementation is depicted below:

Note that the output of the Timer 2 with HLT is routed through a third peripheral called the Configurable Logic Cell (CLC). The CLC has many capabilities that are explained elsewhere including the ability to route signals to microcontroller pins. The Timer 2 with HLT output does not naturally connect to any pins and therefore requires the use of the CLC.
The above application is downloaded in the microcontroller and the resulting waveforms are captured:

Since the CIPs automatically handle the detection of the 1.1 V crossing through to the generation of the 2 ms output pulse in hardware, the CPU is free to continue handling the toggling output in parallel. Therefore, the toggling output is uninterrupted during the 2 ms output pulse in contrast to the output signals generated by the previous software-based implementation.

So What Does This All Mean?

Using the CIPs to replace the interrupt-driven software solution not only eliminates the jitter on the toggling output pin but does so without increasing the system clock speed, which would raise application power consumption. An additional benefit is noticeable when we observe both the software-based and CIP solution waveforms together.

Notice how the output pulse for the software-based solution is wider/longer than the output pulse for the CIP solution. When measured, the software-based solution output pulse is actually closer to 7 ms. Although the timer has been configured to overflow at 2 ms, latencies introduced by software have added additional time delaying how fast the output pulse actually gets driven. Again, this is correctable to some degree by increasing the operating speed of the system, which also increases power consumption. Conversely, the CIP solution output pulse is exactly 2 ms without any change to the system clock.

Summary

Core Independent Peripherals have been developed to provide customers with the ability to utilize a lower-cost microcontroller with the additional cost-savings of minimizing the time spent writing and then, of course, validating code to handle simple tasks. CIPs are already validated by Microchip Technology. Additionally, the CIP solution for the simple application example shown above further minimizes power consumption by improving system response without increasing the system clock. This improved response could have dramatic effects on systems that must respond quickly to signals from sensors or user interface components.