Table of Contents Table of Contents
Previous Page  4 / 32 Next Page
Show Menu
Previous Page 4 / 32 Next Page
Page Background

south-east european




Core Independent Peripherals (CIPs) are autonomous, interconnected and

intelligent peripherals.With CIPsthe microcontroller doesn’t 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 doesn’t 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

Figure 2:

CCL LUT 0 Dead Time Generation

Figure 3:

CCL LUT 1 Dead Time Generation

Figure 4: Timing Diagram of Dead Time Generation