“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.
