Core independent peripherals have zero dependence on CPUs…really?

The Core Independent Peripheral (CIP) is a term coined by Microchip Technology to describe an unusual control scheme whereby peripherals do not rely upon input from the Central Processing Unit (CPU). Microchip claims that these self-sustaining peripherals free up the CPU, increase power savings, reduce development time and are easily configured with Microchip graphical programming tools.

Both Microchip’s PIC and AVR microcontroller architectures offer an abundance of peripherals. Microchip is well-known for a wide range of MCUs that offer flexibility in how they can be applied. This leads to more creative control for developers, but what’s this CIPs function, and how does it work? Will CIP interfere with flexibility, or add to it?

 

Keep in mind that microcontrollers (MCUs) are different from microprocessors (MPUs). One of the main differences is that MCUs have a single core and do not handle multiple simultaneous threads. MCUs run only one control loop at a time. An MCU that’s servicing several control loops can miss an interrupt if it’s already handling another interrupt (i.e., a competing input signal) at the same time. While what most people call MCUs do not have fancy multi-core processors, they can be loaded with ready-to-connect peripherals, built-in analog-to-digital converters, and multiple interfaces from the humble USART serial input to sophisticated interfaces like modern USB. With MCUs, the various combinations of I/O, peripherals, timers, ready-made software-generated functions, and interfaces and their protocols are nearly infinite.

CIPs offer a somewhat pre-packaged means of programming events based on peripherals. Something called the Event System can trigger events based on General Purpose Input/Output (GPIO). This is where the Microchip terminology gets a bit confusing because I wouldn’t call the Event System a peripheral, but this is how Microchip refers to it in this context.

The Event  System for the ATTTINT817 offers the input options of generating an event based on a timer/counter, an ADC, comparator, an external port, or a system clock. (Note that other MCUs may offer a different or additional choice of triggers.)  An event generated somewhere on the MCU can also be used to trigger another event on the same microcontroller. Again, this side-steps the processor, which is busy running control loops and monitoring for interrupts.

The CIP can be used to manage IF-THEN functions using peripherals as input/output, for lack of a better way to explain it. For example, let’s say that a voltage connected to a comparator input pin on the MCU goes beyond a specified threshold and the output of the comparator is set to go high. We can use the Event System to take the comparator output and trigger an A-to-D conversion of a voltage on another pin somewhere else on the same MCU.

CIP control is based on hardware and does not affect the MCU’s processor. Microchip has designed some rather complex control possibilities that side-step software programming in the usual sense. This is where Microchip’s claim of saving time with reduced programming requirements comes from. CIP timer-based control and measurement of internal or external events can include pulse width modulation (PWM), single-shot generation, periodic interrupt, input capture on event, time and frequency measurements of digital signals, and noise-canceling capability.

CIPs are meant to automate tasks that have customarily been executed by the processor based on software code that a developer has to write, debug, test, and integrate into the entire scheme (or system) that the MCU services.

Does an MCU with CIPs lead to more creative control for developers? Yes. MCUs with CIPs should be investigated before you move up to an MPU, which can be more complicated than an MCU. CIPs allow you to keep it simple a little longer as the product application matures and adds more features.

Do CIPs interfere with design flexibility, or add to that flexibility? Microchip has done it again, extending the capability of MCUs without requiring multiple threads (which requires an operating system on a single core). MCUs with CIPs might allow you to avoid upgrading to multiple cores. MCUs with CIPs offer a little more allowance to let you sleep at night without worrying about control schemes with the potential for competing interrupts where one goes ignored. MCUs with CIPs can reduce the amount of software and interrupts that can tie up the core. And perhaps the operating frequency can be lowered to reduce power requirements. The Event System can eliminate latency by bypassing interrupts altogether because it doesn’t use the processor. CIPs are Microchip’s solution to executing events in parallel with a single core MCU.

If you want to dig deeper into the details, Microchip has an excellent video that explains how CIPs work using examples and timing diagrams that visibly demonstrate the benefits. (You might want to reduce the speed of the video to 0.75 in YouTube settings. The video seems a bit like Khan Academy— but in a good way.) It’s apparent that we have just scratched the surface regarding CIPs here, but it’s definitely worth taking a look at: Microchip MCUs with CIPs.