Core Independent Peripherals (CIPs) are autonomous, interconnected and
intelligent peripherals.With CIPsthe microcontroller doesnt need to interact with
the Central Processing Unit (CPU) to executing tasks. This equals several ad-
vantages for the application.
First, the CPU is not needed for communication between peripheral and pe-
ripheral. The core can sleep and the software flow doesnt need to be interrupt-
ed. Obviously, if the core is in sleep mode and software is not needed then the
current consumption of the application will be lower. The CPU is the part of the
microcontroller which has the highest current consumption. Therefore, using
CIPs reduces power consumption.
Second, CIPs do not cause interrupts which allows for much faster communi-
cation overall. If the CPU core is running software and it has to be interrupted
from the peripheral to accomplish a specific action, it requires a lot of time. The
interrupt needs three clock cycles + two clock cycles for the relative jump and
might use several cycles for the context switch, in order to save the data in the
registers on the stack depending on the application. CIPs allow communication
to be much faster than if the core has to be interrupted.
Third, using CIPs means faster time-to-market. Less software has to be writ-
ten as the hardware can do the task on its own. This reduces the risk of software
errors and less software validation is needed. Therefore, the development time
of the product is shorter than without using CIPs.
microcontrollers (MCUs), all Core Independent Peripherals are con-
nected via the Event System. In the Event System, a multiplexer connects the
event generator and the event user. There are synchronous and asynchronous
events. Asynchronous events need less than one clock cycle and synchronous
events needtwo clock cycles. Many peripherals can be connected to the event
system to be CIPs. These are timers, the Real Time Counter (RTC), Periodic
Interrupt Timer (PIT), the Custom Configurable Logic (CCL), Analog Compara-
tor (AC), Analog-to-Digital Converter (ADC), Universal Synchronous/Asynchro-
nous Receiver/Transmitter (USART) and the General Purpose Input/Outputs
Using the Core Independent Peripherals
Core Independent Peripherals need to be configured once before they are
used. The CPU executes the instruction to do the right initialization of the Event
System and the needed peripherals.
Several applications nowadays still use a button as an input. For every button
a debounce logic or piece of software is needed to get a non-toggling signal. For
the AVR MCU, it is an easy task to do the debouncing as software. This can be
done by delays and/or logic in the software program. The software is not compli-
cated but it uses CPU resources. Whether the button has been pressed or not
can be checked either by polling or via an interrupt from the GPIO controller.
Both need time and CPU usage to do the complete debouncing task.
Debouncing/Delay with the filter of the CCL
With Core Independent Peripherals, completing the debouncing task can be
done without any additional overhead of the CPU. All that is needed is the Cus-
tom Configurable Logic (CCL). The GPIO, where the button is connected is
configured as an asynchronous event generator. The CCL will be the event
user. The signal from the GPIO pin to the CCL input will be transferred with no
delay. The truth table in the CCL is configured so that the output is equal to the
input. The output of the truth table is routed to the filter. For the filter of the CCL,
see Figure 1. It is possible to remove glitches from the input signal and we can
set the delay of the filter to two to five clock cycles (peripheral clock or an alter-
The power of autonomous peripherals:
achieving low-power in real time
native clock) for the output signal. If we use a slow clock of 32 kHz than we have
a delay of 1.5 ms. It is also possible to extend the delay time with a different
clock or with a timer.
Delay with a Timer
For example, Timer/Counter B (TCB) is set up in Single-Shot mode. If the
timer gets an event signal it starts counting until it reaches its programmed max
value and stops it. The output of the TCB is connected to the CCL. In the CCL
the desired combination of the delay signal can be done. This allows for a very
flexible time delay. Every new event to the TCB timer starts the counting again.
Dead Time Generation
Dead time is used in applications where switches (transistor, FET or IGBT)
are in series between power and ground (GND). If both are activated at the
same time there is a short. An example is an H-bridge configuration common-
ly used for motor control drive. Depending on the application the dead-time
will either be between commutations or between the Pulse-Width Modulation
(PWM) pulses. Dead time between PWM pulses is needed, for example, in
sinusoidal drive and between commutations in 1-pole Brushless DC (BLDC)
motors. Dead-time between PWM pulses can be generated with the timer
Time Code Display (TCD).
To generate dead-time between commutations we need two timers, the Cus-
tom Configurable Logic (CCL) and the AC. Figure 2 and Figure 3 represent the
logic of the truth table of the CCL. The timer TCA generates the base PWM
signal for the motor control. The AC is externally connected to the hall sensor of
the motor and internally connected via the event system to timer TCB. Timer
TCB generates the dead time signal if it gets a signal from the AC. The CCL
combines the TCA (PWM), TCB (dead-time) and the AC signal. The input sig-
nals can be selected directly in the CCL configuration and do not need to use
the Event System. There are hardwired connections between these modules.
The CCL then generates two PWMs, see Figure 4 which drives the switches for
Gregor Sunderdiek, Microchip Technology
Figure 1: Filter of the CCL
CCL LUT 0 Dead Time Generation
CCL LUT 1 Dead Time Generation
Figure 4: Timing Diagram of Dead Time Generation