feature article
Subscribe Now

Microchip Makes Two Small Firsts

First Dual-Core dsPIC; First Cortex-M23 with TrustZone

“Roses are red / Violets are blue / I’m schizophrenic / And so am I” – Oscar Levant

Two heads are better than one, and everyone’s stuck their head into the multicore business. Even little $1 microcontrollers have dual processor cores now, including those from MCU titan Microchip.
Just this week, Microchip announced two new (and unrelated) devices, both of which can claim a small first in the industry. One, the dsPIC33CH, is the company’s first dsPIC device to have two cores. Previously, all dsPIC chips were single-core only. Over on the other side of the building, the new SAML10 and SAML11 twins are the industry’s first Cortex-M23 devices to have TrustZone. Whew! That feels like enough innovation for one day.

Microchip’s dsPIC family (the name stands for digital signal peripheral interface controller) has a long and storied history. It’s a popular MCU line for those who need a dash of DSP-ness to go with their control code. That makes dsPIC popular for motor controllers, pumps, industrial controls, and physical things that need to move about. They’re also good for digital power supplies, which don’t have moving parts but do need some signal-processing acumen. The dsPIC family is cheap, well supported, and available in a broad range of package types and styles. But they’re also all single-core.

Being monocephalic isn’t a bad thing, per se, but it limits how much you can do. Closed-loop control systems typically need precise and deterministic real-time response, so dsPIC code often consists of tight control loops that you don’t want to be interrupted. (Or tight interrupt handlers that you don’t want interrupted.) If your motor-control MCU also has to do anything else at all, like manage a user interface, serial communications, or the occasional interrupt, it’s all got to happen without jeopardizing the timing of the main control loop.

Most dsPIC programmers leave themselves a generous safety margin, says Microchip, by using only about one-third to two-thirds of the dsPIC’s performance. That way, the MCU won’t be overtaxed by a worst-case confluence of events. It wastes a chunk of your MCU’s potential performance, but at least it’s reliable. Them’s the breaks, kid.

Why not separate the control loop from the ancillary tasks? Microchip’s new dsPIC33CH does just that by physically dividing the device into two separate halves, each with its own dsPIC processor core, memory, and peripherals. The two halves are not quite identical, and it’s clear which one is supposed to run the real-time control code and which handles housekeeping. The former is dubbed the “slave” core, and it’s equipped with multiple PWM outputs, ADCs, analog comparators, and programmable gain amplifiers. It executes out of zero-wait-state SRAM, guaranteeing that it runs at full (and predictable) speed.

The “master” core, in contrast, has a slightly different peripheral mix that includes CAN-FD, fewer PWMs, and only one ADC. (Both sides have the familiar UARTs, I2C, USB, SPI, and so forth.) It also runs entirely out of local flash memory, leaving the slave core’s main memory undisturbed. Oddly, the master runs a bit slower than the slave (90 MHz vs. 100 MHz), simply because the on-chip flash isn’t quite fast enough to keep up with the speedier clock frequency.

Splitting the cores sounds like a great idea, but dual-core programming can be notoriously tricky. Given that there’s never been a dual-core dsPIC before, even the most grizzled dsPIC veteran will have zero dual-dsPIC experience. Multicore programming has tripped up more than a few good code developers. What makes Microchip think its device will be any easier?

In part, it’s because the nature of dsPIC applications maps well onto a split-core design, says the company. Users are already dividing their code into real-time loops and “other.” There’s little inter-process communication, and none of the exotic symmetric multiprocessing (SMP) that you see in high-end CPU architectures. Nobody needs to worry about how Task A will migrate from one core to the other and back again. There’s no core “affinity” to worry about. No extended state information to preserve when tasks are forked by some RTOS. Just decide what goes on the real-time side (the slave core) and what goes on the non-real-time side (the master core) and you’re mostly done. Best of all, your real-time code won’t be interrupted all the time with nonessential tasks. That becomes somebody else’s job. There’s a spiffy YouTube video that shows the slave core happily commutating a motor even while the master core is held in reset.

Microchip also has a little something for those developers who aren’t into rotating masses, power correction, or heavy metal. Two somethings, actually: the SAML10 and SAML11. They’re fraternal twins in the existing SAM product family, with an emphasis on simple touch-sensitive controls. The company’s L10/L11 demonstration shows off their tolerance to water, working perfectly (of course) through wet PC boards.

The L11 is the more interesting variant here because it’s got Arm’s TrustZone security measures baked inside. This gives the L11 the marginal distinction of being the first Cortex-M23–based device to incorporate TrustZone. Security is becoming a bigger issue all the time, of course, so security-enhanced MCUs are now a big part of every vendor’s product catalog.

Microchip chose the somewhat unfortunate example of an inkjet printer cartridge to demonstrate the usefulness of its security-enhanced MCU. An authentic, vendor-approved ink cartridge could include security keys that a SAML11-equipped printer could then query to verify its authenticity, thereby protecting the heinous profit margins of the ink suppliers. Well done, Microchip.

Whatever your intended application, the two SAM twins are certainly affordable, at just over $1 apiece in large quantities. There’s a 10% price premium for TrustZone. Understanding that most of its customers aren’t experienced at writing security software, Microchip offers the usual assortment of prewritten code, as well as third-party layers like Trustonic’s Kinibi-M.
Secure, cheap, dual-core programming was never so easy.

Leave a Reply

featured blogs
Mar 28, 2023
In this user case, Marintek uses Fidelity Fine/Marine and Hexpress for resistance curve prediction of a planning hull and its validation against the model test cases. Team Involved End User: Eloïse Croonenborghs, Research Scientist at MARINTEK, Maritime division, Trondhe...
Mar 23, 2023
Explore AI chip architecture and learn how AI's requirements and applications shape AI optimized hardware design across processors, memory chips, and more. The post Why AI Requires a New Chip Architecture appeared first on New Horizons for Chip Design....
Mar 10, 2023
A proven guide to enable project managers to successfully take over ongoing projects and get the work done!...

featured video

First CXL 2.0 IP Interoperability Demo with Compliance Tests

Sponsored by Synopsys

In this video, Sr. R&D Engineer Rehan Iqbal, will guide you through Synopsys CXL IP passing compliance tests and demonstrating our seamless interoperability with Teladyne LeCroy Z516 Exerciser. This first-of-its-kind interoperability demo is a testament to Synopsys' commitment to delivering reliable IP solutions.

Learn more about Synopsys CXL here

featured chalk talk

How IO-Link® is Enabling Smart Factory Digitization -- Analog Devices and Mouser Electronics
Safety, flexibility and sustainability are cornerstone to today’s smart factories. In this episode of Chalk Talk, Amelia Dalton and Shasta Thomas from Analog Devices discuss how Analog Device’s IO-Link is helping usher in a new era of smart factory automation. They take a closer look at the benefits that IO-Link can bring to an industrial factory environment, the biggest issues facing IO-Link sensor and master designs and how Analog Devices ??can help you with your next industrial design.
Feb 2, 2023
8,034 views