To compete with the rest of the 32-bit market， Microchip Technology
designed its 32-bit offering around the MIPS architecture. The
PIC32 combines Microchip‘s in-house MCU know-how with MIPS
Technology's extensive IP， software， and tool library. Expect to
see PIC32s for a long time to come.
Thanks to the popularity of their venerable PIC chips and the
robust 8/16-bit MCU market， Microchip Technology remains one of the
world‘s top MCU suppliers. There is no doubt that the number of
"sockets" filled by PIC chips is impressive. Indeed，Microchip just
announced the sale of their six-billionth PIC.[1] But when I say
"popular，" I'm not just talking about the volume of chips sold.
When it comes to market momentum and staying power， it‘s the number
of"seats" （i.e.， designers） that really matters. With an aggressive
"mass marketing" approach， Microchip has filled the seats on their
PIC bandwagon with legions of true believers.
It all sounds rosy， but of late， there's been a bit of a problem.
Everyone knows the 32-bit MCU market is taking off，fueled with a
powerful mix of high-performance，yet practical （e.g.， cost，
power，and size）， parts from industry heavyweights with proven track
records.
It seems like the competition was giving a 32-bit MCU party and
Microchip wasn‘t invited. So they invited themselves. The PIC32 is
what Microchip calls their 32-bit gate crasher. It's a big deal， so
let‘s get this party started （see Figure 1）。
点击查看Figure 1
ROCK AND A HARD CHIP
As I reported at the time of its announcement （"More Bits， Less
Filling，" Circuit Cellar 212， 2008）， the headline news for the
PIC32 is adoption of the MIPS architecture. Does that make sense？
Let‘s imagine the thought process the Microchip crew might have
gone through.
The first fork in the architectural road would have been the
decision of whether to "make" a new architecture or "buy" an
existing one. Of course，ask a computer architect which option
they'd prefer and the answer is obvious. It‘s always possible （and
fun！） to come up with a "new and improved"architecture. Plus，
beyond any technical advantages， a proprietary architecture offers
the potential of "locking"
customers in. This is something everyone in the chip business
knows，including Microchip judging by the legal slap downs they‘ve
dealt to would-be PIC cloners over the years.
"Lifetime Employment Act for Computer Architects" aside， there are
some gotchas. In the past， creating a new architecture was largely
a matter of fixing the apparent-in-hindsight mistakes of existing
ones. But at this point， competitive architectures are highly
refined， so there aren't a lot of obvious upgrades on the table.
Short of a radical departure， a "new and improved" architecture
would likely end up looking pretty much the same as all of the
rest.
And there is a bit of a problem with engineering cost and
time-to-market. Remember that defining and implementing the
architecture is one thing，but there‘s also the small matter of
coming up with gigabytes of software tools-"C" compiler，
simulator，RTOS， TCP/IP， and on， and on （see Photo 1）。 And once you
cobble together a few chips and tools， potential customers will
invariably start asking about an "upgrade path" or "ASIC option."
No single issue by itself seems insurmountable， but all of the
problems together are pretty much a showstopper for the "roll your
own" idea.
So， let‘s turn to the "buy" alternative. Licensing an ARM core
would be an obvious solution. But perhaps that's the problem （i.e.，
it‘s too obvious）。Major 32-bit MCU players like Atmel， NXP
Semiconductors， and STMicroelectronics are already far down that
fork in the road. So， how about making a deal with one of the other
32-bit MCU contenders such as Freescale Semiconductor （Coldfire） or
Renesas Technology （SuperH）？Unfortunately， history shows
such"second-source" deals have a poor track record once the
honeymoon is over. Indeed， in their former lives，Freescale and
Renesas （then Motorola and Hitachi） had a second-source deal that
infamously crashed and burned leaving no one （except the lawyers）
better off. Even if Microchip was interested， chances are neither
Freescale nor Renesas would be.
That doesn‘t leave many options does it？ In fact， I can think of
about two， namely MIPS and IBM PowerPC. Without speculating
further，suffice it to say， Microchip chose the former. Maybe MIPS
was more willing， because the deal fills a huge gap in their
strategy （i.e.， lack of a standard MCU supplier） relative to ARM，
their major competitor in the "Architectures-R-Us" biz.
This is a good deal for Microchip. They get a seasoned and proven
design without having to type one line of HDL. Right out of the
gate， the PIC32 is supported with decades worth of tools，
marketing， and support. The architecture has plenty of IP
accessories（i.e.， peripherals and software）and headroom to support
anyone‘s onward and upward performance aspirations. Feel like you
need the flexibility to ultimately move to an ASIC？Well， a
custom-chip focus is MIPSbread and butter, so they've got you
covered.
Yes, the PIC32 is a good deal for Microchip. And it's a good deal
for MIPS. The question is： Is it a good deal for you？
IT‘S A SMALL WORLD AFTER ALLFirst a little history. The MIPS architecture was born in the early
1980s under the direction of John Hennessy， then a professor at
Stanford University， who was in a race against a similar effort
underway at cross-bay rival University of California，Berkeley，
under the tutelage of Professor David Patterson. This marked the
start of the RISC revolution. Later， Hennessy and Patterson put
aside their collegiate rivalry to author Computer Architecture： A
Quantitative Approach， one of the single best tomes on the
subject.[2] By the way， Hennessy is now the president of Stanford
University， so who says there's no career path for engineers beyond
the lab？ Things are looking up for us techies. See you at
the"Nerd-Pride Parade."[3]
The fundamental premise of RISC was to keep it simple， and thereby
make it faster. Instead of the baroque instruction sets found on
the minicomputers（e.g.， DEC and VAX） and micros （e.g.， ‘86 and 68K）
of the time，the instruction set for a RISC was basically defined as
those instructions，and only those instructions， that could be
executed quickly. The original MIPS processor， known as the R2000，
didn't even have a multiply instruction！
Of course， like hemlines， architectural fashion waxes and wanes.
Today‘s RISCs are hardly "reduced"by any means. But because the
PIC32 is based on the simplest core MIPS offers， it‘s lean and mean
enough for blue-collar MCU apps （see Figure 2）。
You can still see vestiges of the oldtimey RISCs including a
classic fivestage pipeline， 32 × 32-bit register file， and a
relatively terse load/store instruction set.
There were a lot of gotchas with the original RISCs that MIPS and
Microchip （and all the other 32-bit MCU suppliers） have fixed by
now. Retro-RISCs could barely toggle a bit，something the PIC32 can
handle easily with atomic bit manipulation capability for
peripherals. In the old days， an "interrupt" was a rare event and
"real time" meant something like 60 Hz. Today， the PIC32 features a
shadow register set and a built-in priority interrupt controller
for speedy interrupt response. The 32-bit fixed instruction length
dogma of yore resulted in bloaty code （i.e.， poor code density），
but the PIC32 includes the 16-bit MIPS16e code-compression scheme
（a la ARM‘s Thumb） to cut the fat. Developing RISC software （not to
mention debugging it） was hard， but after all of these years， the
tools （e.g.，compilers， libraries， RTOS， etc.） have been refined and
optimized to the nth degree. And of course， there is now a multiply
instruction， and a fast one at that （32 × 16 in one clock， 32 × 32
in two）.
WHERE SILICON MEETS THE ROADBeyond a decent architecture， when it comes time to actually build
something，it‘s the chip implementation，tools， and support that
matter most to designers. "Core Wars" aside， here's the stuff I
would look for when choosing a 32-bit MCU.
Faced with cries for evermore MIPS and megahertz， a 32-bit MCU
eventually runs into the dreaded "flash bottleneck."Unfortunately，
it seems as though flash technology is always playing catch up and
just can‘t keep pace as clock rates approach triple digits （up to
80 MHz for the PIC32）。A core may be able to execute an instruction
in a single clock， but what good is that if it takes two clocks （or
three or four...） to grab it from flash memory？
The flash memory access time for the PIC32 is 50 ns. That means
wait states enter the picture at just 20 MHz and become a real drag
at 40 MHz and beyond. Microchip‘s solution is a minime 256-byte
instruction cache （see Figure 3）。 It's pretty simple， really little
more than a fancy prefetch buffer，but one with a few nifty
embellishments. Any or all of the 16 lines（each 128 bits （i.e.，
four 32-bit instructions）） can be individually locked for
high-speed predictable response. Up to four lines can be allocated
for read-only data （e.g.， filter coefficients） stored in flash
memory. An address mask feature allows multiple copies of the same
code in memory （e.g.， prelude common to all interrupt handlers） to
use a single cache line.
Here are a couple of possible lowpower tweaks to keep in mind. Even
if you‘re running at less than 20 MHz， it can make sense to run
code from the cache （do turn off the prefetch feature）because
accessing the cache RAM consumes less power than accessing the
flash memory. The PIC32 can also execute code from on-chip RAM，
likely another path to performance and power optimization.
Speaking of low power， that‘s high on the shopping list for anybody
making a battery-powered gadget. The last thing designers need is
some porky bloat chip wasting watts like there‘s no tomorrow （we
have PCs for that）。Indeed， if you consider the billions of MCUs at
work 24/7， saving just a few milliamps adds up. That‘s a lot of
energy that we don't have to scrounge up somewhere else.
Now I won‘t try to kid you. In typical operation， you can figure
the PIC32 is going to consume about 1 mA per 1 MHz， which doesn't
sound too bad. But that does add up to 75 mA at 80 MHz，or 0.25 W at
3.3 V.
Obviously， the PIC32 isn‘t an oh-sogreen 8/16-bit MCU， but it does
have a number of power-saving features you should exploit. There
are the usual IDLE and SLEEP modes plus the ability to individually
turn off each peripheral function or leave it on. That's a nice
touch because it means you can power only the peripheral（s） your
application needs to serve as wake-up sources and turn off the
rest.
Dynamically reducing the CPU clock rate to the minimum necessary to
meet instantaneous performance demand is the best solution. For
instance， you can still get plenty of MIPS （and zero wait states）
running at 20 MHz， which drops power consumption to under 25 mA
typical. Similarly， you can dynamically divide the peripheral bus
clock down， keeping in mind the possible need to adjust peripheral
settings（e.g.， UART data rates）accordingly.
Taking clock scaling to the extreme， you can run the PIC32 off its
low-speed on-chip 31-kHz RC clock. Yeah， you‘ll have only KIPS， not
MIPS， to play with （call it "GROGGY Mode"）， but power consumption
drops into the microamps（e.g.， 125 μA typical at 25°C）。
Putting the chip to SLEEP is the final power-saving straw. At these
low levels，the actual power consumption varies greatly depending on
two factors. One is which， if any， of the ancillary functions you
choose to keep powered up， typically to provide a subsequent
wake-up call. The watchdog timer or real-time clock are good
choices because they consume only a dozen microamps or so while the
ADC is a pricey keep-alive option at fully 1 mA. The other factor
affecting power consumption is temperature and its impact is
nontrivial. For instance， SLEEPING at room temperature （25°C） with
just the watchdog enabled consumes around 40 μA. Run the same setup
at the maximum rated temperature （85°C）and you‘re talking more than
300 μA.
MORE BITS， LESS FILLING
It takes more than a good core to get the job done. The PIC32 has
a lot of other stuff built-in， enough to fill a 626-page datasheet.
Needless to say， I can‘t cover everything in detail， but here are
some of the highlights.
Major drivetrain components close to the core complete the PIC32's
personality shift from "computer" to"controller." Let‘s start with
the clock generator. Make that "generators" plural because there
are four clocks to play with. In addition to the expected
connection for the high-speed clock （e.g.， 4- to 5-MHz crystal
feeding the on-chip PLL）， there is a separate 32-kHz input for the
real-time clock and other keep-alive logic. Onchip，there are both
fast （8 MHz） and slow （31 kHz） RC clocks， which can replace the
external clock entirely for applications that don't need
superaccurate timing. And even if an external clock is used， the
on-chip clocks are useful for low-power throttle down， two-speed
fast wake up （start executing using RC while crystal
stabilizes），and clock-fail detect with automatic switchover.
In the early days， MIPS chips weren‘t very interrupt savvy. They'd
pretty much treat every interrupt the same and just leave a few
crumbs （e.g.，"Cause" code） for software， which otherwise had to
deal with all of the gory details like context switching，nesting，
priority， and such. By contrast，the PIC32 has a full-featured
priority vector interrupt controller that does all of the juggling
in hardware（see Figure 4）。
I noticed that the interrupt controller has an interesting
"coalescing"feature I hadn‘t seen before. It's easy to understand
with a metaphorical example. Let‘s say you're having a dinner party
tonight and need to gather the ingredients for large salad， a main
course， and dessert. So， at 10 A.M.，you drive to the market and buy
the salad fixings. Then， at 2 P.M.，you drive a second time to buy
the ingredients for the main course. Finally， at 4 P.M.， you go yet
again to pick up dessert.
This is obviously a wasteful scenario， even if it "meets the
schedule." And if an unexpected delay should arise， the overhead
and latency could have your starving guests pounding the table.
Larger embedded apps can face a similar scenario. They may， for
example，spend 80% of their time handling the main application and
the remaining 20% handling miscellaneous lowpriority chores. But
just as with the example of driving to the market three times，
dealing with each chore（i.e.， interrupt） separately is wasteful.
The extra overhead （e.g.， context switches） burns power and， in the
worst case， may even put the schedule at risk.
The PIC32 interrupt coalescing feature is a scheme that holds off
background（i.e.， intermittent and low-priority）"chore" type
interrupts for efficient batch processing （i.e.， like driving to
the market just once）。 That way， a single invocation of the handler
can deal with all of the chores at one time with just a single
context switch. This is kind of like using a timer to generate a
periodic "chore"-type interrupt and then polling to see what needs
to be done， but more efficient.
Speaking of driving， a four-channel DMA controller provides the
equivalent of high-speed mass transit. It can be assigned to work
with different peripherals or interrupts and has lots of whizzy
features like "chaining"（multi-channel sequence of
transfers），pattern matching termination， and configurable CRC
generation and checking. That‘s all cool， but I was also pleased to
see how well the DMAC handles byteoriented stuff （i.e.，unaligned
transfers）。 The original computer-oriented RISCs had a bit of
a"What， me worry？" attitude about lowly bytes，but the PIC32 DMAC
understands that， at least for embedded applications，bytes still
matter.
Vestiges of MIPS computer- oriented roots remain in the form of a
User/Kernel protection model and virtual memory address
translation. But in the PIC32， these big-ticket software （e.g.，
WinCE，Linux， and RTOS） features are hidden behind a simple
fixed-memory map. At least for now， but I wouldn't be surprised to
see a future PIC32 with the full-featured MMU.
When it comes to peripherals， the PIC32 has all of the usual
suspects and then some. There are up to 16 channels of 10-bit，
500-kHz A/D， two analog comparators with programmable onchip
reference， five 16-bit timers （can be paired to work as 32 bits），
and a full complement of serial I/O including I2C， SPI， and UARTs.
I did notice one I/O extra that stands out a bit from the MCU
crowd. While the chip doesn‘t have an external bus interface per
se， it does include a "Parallel Master Port" （16-bit address， 8- or
16-bit data）that provides fast and easy connection to external
devices such as memory and I/O chips， another MCU， FPGA，and more.
（see Table 1）。
EASY DOES ITIt must have been 20-plus years ago or so that I was working on a
MIPS R3000-based SBC. It was a board as big as this magazine that
consumed amps of power and cost thousands of dollars. I remember I
had a devil of a time getting the finicky multiphase clock
generator and "double pumped" memory interface （data transferred on
both edges of the clock） to work. Good times.
Today， for just a few bucks （from $2.95 for 32-KB flash/8-KB RAM to
$5.30 for 512-KB/32-KB in 10K volume），you get a PIC32
"controller"that‘s equivalent to a top-of-the-line"computer" from
yesteryear. And it's a heck of a lot easier to design in （see Photo
2）。
But you‘ve heard me say it before： A good chip is just necessary，
not sufficient，to guarantee success. It takes a lot of tools，
support， and a full catalog of parts to stay in the game. Whatever
you think of the PIC32， no one can deny Microchip knows what it
takes to sell MCUs. Combining their own in-house PIC know-how with
MIPS extensive IP， software， and tool library，no doubt we'll see
plenty of new PIC32s joining the line-up soon. In fact， taking
advantage of MIPS existing IP， Microchip has already announced a
version of the PIC32 with built-in USB.
When it comes to supplier competition and choices for designers，
the more the merrier， I say. OK Microchip，bring it on！
Tom Cantrell has been working on chip， board， and systems design
and marketing for several years. You may reach him by e-mail at
tom.cantrell@ circuitcellar.com.
REFERENCES
[1] Microchip Technology, "Microchip Technology Delivers Six
Billionth PIC Microcontroller," Press Release,February 27, 2008, www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en534302.
[2] J. Hennessy and D. Patterson,Computer Architecture: A
Quantitative Approach, Morgan Kaufmann, San Francisco, CA, 2006.
[3] D. Christiansen, "Nerdiness," IEEEUSA Today's Engineer
Online,December 2007/January 2008.
SOURCE
PIC32 Microcontroller
Microchip Technology, Inc.
www.microchip.com
;){kind=link}