PIC32MZ available

[Dooces]

Just thought id let everyone here know that the PIC32MZ is "available" (well, more so than in the past), though it does not look like much of the errata has been addressed, I have been waiting to play around with them since getting my hands on the "leaked" chinese datasheet in Feb 2013.

[dannyf]

What's the selling point?

I was enthusiastic about those chips, until I realized that they have to used with Mplab/Mplab X, C32/XC32, and plib/Harmoney. At that point, I gave up on those chips.

[andersm]

have to

If you want to use third-party tools there's eg. Green Hills (compiler, IDE, debugger) or Viosoft's Arriba (Eclipse integration for Microchip's tools). And you're always free to roll your own.

The real problem with the PIC32MZ is that it's a buggy, broken design. Rumour is that there will be a full metal-layer redesign next year, which may include floating-point support. Unless Microchip manage to completely balls up that as well, it will be a much more interesting product. Of course before that's out, the competition will have moved onwards and it may end up being completely irrelevant. One can only hope Microchip took a long, hard look at what's wrong with their development and testing process that a dud like the MZ could make it through.

[mikeselectricstuff]

For me, on paper (including a quick skim of the errata) at least it looks very interesting, as it's the only part I've found with a buttload of RAM in a small QFP package.

[andersm]

Errata like toggling the I/O pin next to the oscillator pins disrupts the oscillator (not included yet in the rev D errata sheet) should be enough to strike fear into any designer. It'll soon be a year since the PIC32MZ was officially launched, and bugs of this nature are still being discovered.

[Carrington]

The Arriba IDE is an Eclipse based IDE for the PIC32 family. Arriba is fully integrated with Microchip XC32 compiler and debug tools, providing managed build capabilities for a wide range of applications including standalone PIC32 apps as well as applications based on popular RTOS.

And Harmony.

If 'Arriba' is XC32 dependent, then you have the same problem that with MPLAB X, ie 'PLIB functions and macros in this file will be removed from the MPLAB XC32 C/C++ Compiler in future releases', plus 371.40€ on your bill.

http://microchip.wikidot.com/arriba:start

To me, so far, 'Arriba' does not seem better than others. No idea about 'Green Hills'.

If I'm not mistaken, PIC32MZ series only work with 'Harmony', right?

[tszaboo]

For me, on paper (including a quick skim of the errata) at least it looks very interesting, as it's the only part I've found with a buttload of RAM in a small QFP package.

Looks like Microchip is again very generous on the memories and the number of peripherals.

These compete with the LPC4300 series in everything, except floating point. I expect FP to be there but totally broken. Honestly, I dont feel like making a fool of myself (in front of my bosses) and designing something broken with it.
So I guess I'll try to convince them to send me devboard, and maybe think about it a year from now when the next revision is out?

mod: and my opinion changes very quickly if they make USB audio 2.0 or just 192Khz/24 bit working with it.

[westfw]

I expect FP to be there but totally broken.

Why?  Isn't FP part of the MIPS Intellectual Property, rather than something that is likely to be screwed up in the implementation?  MIPS has been doing FP for a long time...

[dannyf]

PIC32MZ series only work with 'Harmony'

That would be sufficient enough to strike PIC32 off my list of mcus to consider.

[forrestc]

PIC32MZ series only work with 'Harmony'

That would be sufficient enough to strike PIC32 off my list of mcus to consider.

The underlying statement is blatently false.

Harmony only works with the PIC32 series of parts, but you don't have to use Harmony to use PIC32MZ.   Just like you don't have to use the Microchip MLA to use a 8 or 16 bit part.   

All Harmony is is a set of libraries for the PIC32 family which includes such things as a USB stack, full TCP/IP stack (with numerous protocols supported), interface with RToS'es etc.   You don't have to use Harmony if you don't want to.

You also don't have to use the microchip toolchain.  Or at least won't have to soon. I know of at least 2-3 tool vendors who are in the process of updating their toolchain for the PIC32MZ.  Heck, if you're an Ardunio fan, you can go buy a ChipKit Wi-Fire to get started, and use ardunio tools to program the PIC32MZ.  Personally I like MPLABX, find the compilers for the PIC32 be not bad at all, especially for free.  Harmony is maturing, and is a good spot to get a jumpstart on a bigger, professional, project which is what it was intended for. 

Having had some heart-to-heart discussion with PIC32MZ design team members I know that they've had some challenges along the way.  This is Microchip's first part on a new, smaller process, and things have definitely not gone as smoothly as they would have liked.   Some of the early errata was just ugly.   The ones that remain are actually pretty typical of a newer part, and aren't show stoppers for many applications.  Compare the severity of the current errata with the first release of almost any other 32 bit MCU and you'll find a similarly sized list of similar severity issues.

Honestly, the PIC32MZ is a big, fast, low power consumption MIPS core MCU.  If you need something which runs at 200Mhz, has 2MB program flash and 512K of RAM and numerous onboard peripherals, this is worth considering.   

[mikeselectricstuff]

Honestly, the PIC32MZ is a big, fast, low power consumption MIPS core MCU.  If you need something which runs at 200Mhz, has 2MB program flash and 512K of RAM and numerous onboard peripherals,

..and comes in  QFP/QFN packages down to 64 pin, so useable on a 2 layer PCB

[Psi]

Errata like toggling the I/O pin next to the oscillator pins disrupts the oscillator (not included yet in the rev D errata sheet) should be enough to strike fear into any designer.

i'm running away, you cant see my legs, they are moving too fast.

[dannyf]

Honestly,

That's a bad way to start a sentence, especially when you are honest. Reminds me of car salesmen: when they say that, you know it is time to clutch to your wallets.

i'm running away

I am not, as I was never there,

[Sal Ammoniac]

I have a board with the PIC32MZ and have been using it for a while now, so I can offer some opinions.

Overall, it's a nice part, with lots of memory and decent peripherals. At 200 MHz, it's fast, and rivals the fastest parts from NXP and ST. It does have an errata list that's a mile long, however, and Microchip doesn't plan on releasing a part that corrects the bugs until sometime in 2015. With the announcement of the Cortex-M7 by ARM a few days ago, the PIC32MZ may be too little, too late to keep Microchip in the 32-bit game.

The biggest disappoint (for me) is the broken ADC. It was originally supposed to be a 12-bit ADC, and then it got down-spec'd to a 10-bit, and five of the six sample and hold units don't work.

What I like about it:

• It's fast
• Lots of SRAM (512 KB) and FLASH (2 MB)
• The SRAM is 512 KB contiguous and not broken into pieces like on many other MCUs
• The peripherals are simple and consistent
• Excellent documentation

What I don't like:

• The errata list is long and scary, with fixes not available until 2015 at the earliest
• No built-in hardware floating point
• No battery backup for the RTC
• Seriously broken ADC

[dannyf]

It is a good experience trying out a new chip.

But lately my approach has been: why should I try a new chip? What does it bring to me that other chips don't?

PIC32s (as well as AVR32s) fail miserably under those tests.

[marshallh]

Everybody I know who's attempted to use the pic32mz has described it as a trainwreck.
The specs are good but implementation falls over.

Wait for the kinks to get ironed out with new silicon.

[Sal Ammoniac]

why should I try a new chip? What does it bring to me that other chips don't?

PIC32s (as well as AVR32s) fail miserably under those tests.

I like trying new chips, especially if they have an interesting architecture. Although I'm a hobbyist, my primary interest is real-time operating systems. I've written them for Cortex-M3/4, PIC32, and AVR32. Why? Just because I like to.

Of the three above, the Cortex-M3/4 was the easiest to implement an RTOS on, followed by the PIC32. The AVR32 was a quirky nightmare.

The PIC32 has good hardware and development support, both from Microchip and 3rd parties (MikroElektronika, Digilent, etc.) It's relatively easy to set up a PIC32 development environment using Microchip's MPLAB X and XC32, an ICD3, and a board from MikroElektronika or Digilent. It's all plug-n-play and it just works.

ARM is a little more difficult as there are so many disparate pieces to put together. Sure, there are plug-n-play solutions, but most of them are costly, or quirky.

The AVR32 gets no love from Atmel, really, and has no 3rd party support, so I wouldn't recommend that anyone bother with it.

[gocemk]

The biggest disappoint (for me) is the broken ADC. It was originally supposed to be a 12-bit ADC, and then it got down-spec'd to a 10-bit, and five of the six sample and hold units don't work.

I totally agree. Currently this is my biggest problem with the PIC32MX series. Yes, the core is fast and on par with the Cortex M3, but why 10-bit ADC with only 1MSPS?!?!. Hell ,they have a 12-bit ADC on their dsPIC30F4013-30I in DIP40 package, and they have PIC24 parts with 5 MSPS!

The PIC32 has good hardware and development support, both from Microchip and 3rd parties (MikroElektronika, Digilent, etc.) It's relatively easy to set up a PIC32 development environment using Microchip's MPLAB X and XC32, an ICD3, and a board from MikroElektronika or Digilent. It's all plug-n-play and it just works

At the moment that's about the only reason why i'm still using mostly Microchip PIC parts (Pickit 3 + EasyPIC 7 and EasyPIC Fusion).

But with the ST Discovery boards i'm really starting to lean towards the ST ARM Cortex chips.

I was really excited about the PIC32MZ and it's new microAptiv M14K core, but as it currently stands it is really inferior compared to the STM32F3 range, and not to mention the STM32F4 line. Microchip really, really needs to step up it's game if it wants to stay in the (growing) 32-bit market. With the announcement of the Cortex M7, things have gone from bad to worse for them.

[dannyf]

Microchip's MPLAB X

I have a (almost) ten year old dual quad-core Xeon, 12 GB of ram. The "refreshing" of my workspace on MPLAB X start-up must be like 30 - 45 seconds and no way to avoid it.

Everytime I press rebuild, the computer thinks about it for a few seconds and then action takes place.

MPLAB, for its 1980s look, has none of those issues.

I still use Microchip chips (PIC16 under a PICC IDE and PIC24 under emBlocks). No PIC18 due to no suitable environment.

If they cannot figure out a viable 32-bit strategy, I would question their viability 5 - 10 years from now.

[Sal Ammoniac]

Microchip's MPLAB X

I have a (almost) ten year old dual quad-core Xeon, 12 GB of ram. The "refreshing" of my workspace on MPLAB X start-up must be like 30 - 45 seconds and no way to avoid it.

Upgrade to a new machine, if you can.

My development machine is a Haswell Core i7 with 32G of RAM and an SSD. MPLAB X starts in 1-2 seconds and a full build of my RTOS+application (30 files) takes 2-3 seconds.

[tszaboo]

It is a good experience trying out a new chip.

But lately my approach has been: why should I try a new chip? What does it bring to me that other chips don't?

PIC32s (as well as AVR32s) fail miserably under those tests.

It has high speed USB PHY, and slave I2S. It can revolutionize the home-made DAC market if they make an USB Audio class 2 stack for it. Even if nothing else works on it. I really hope they realise that they could have the upper hand on this.

[dannyf]

A 2xX5460 would likely outrun most i7s without much sweating.

MPLAB X starts in 1-2 seconds and a full build of my RTOS+application (30 files) takes 2-3 seconds.

Those are impressive numbers. I looked into putting mplab x on a ramdisk but in the end ran out of time. Still, even those my machine is old, other IDEs I have run just fine on bigger workspace / complex projects.

You shouldn't need a Cray to compile for PICs.

[neslekkim]

I have an dual quadcore xeon from 2008 myself they are more than capable for this work, just swap over the disks to SSD, it makes all the difference..

Set up an new computer now, mostly because I got tired of the fan noise from the xeon computer (Dell precision T7400), and have haswell i7, 32gb ram, 512GB SSD etc, superfast, but I guess disk is the most important part. I had 56GB ram on the previous also, so ram have newer been the issue.

[nctnico]

Build speeds depends greatly on the OS you are using. Linux works much faster for compiling big projects and the speed doesn't depend on how fast or slow the hard drive is. Every now and then I compile an embedded Linux image on a quad core Intel. The speed difference between a (low noise!) 5200rpm hard drive and an SSD is 0.

[diyaudio]

Build speeds depends greatly on the OS you are using. Linux works much faster for compiling big projects and the speed doesn't depend on how fast or slow the hard drive is. Every now and then I compile an embedded Linux image on a quad core Intel. The speed difference between a (low noise!) 5200rpm hard drive and an SSD is 0.

Interesting I was always under the impression that the Java IDE Netbeans is responsible for these issues.