EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Dooces on September 05, 2014, 04:34:27 pm
-
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.
-
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.
-
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.
-
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.
-
Errata like toggling the I/O pin next to the oscillator pins disrupts the oscillator (http://www.microchip.com/forums/FindPost/818213) (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.
-
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 (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?
-
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.
-
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...
-
PIC32MZ series only work with 'Harmony'
That would be sufficient enough to strike PIC32 off my list of mcus to consider.
-
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.
-
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
-
Errata like toggling the I/O pin next to the oscillator pins disrupts the oscillator (http://www.microchip.com/forums/FindPost/818213) (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.
-
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, :)
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Interesting I was always under the impression that the Java IDE Netbeans is responsible for these issues.
I've used Netbeans and Eclipse-based IDEs and Netbeans is much faster than Eclipse in the examples I've used.
My development machines have 32-64GB of RAM, so speed of the disk or SSD doesn't matter too much once everything is in the cache. The first built of the day takes a little longer, but then everything runs very fast.
The biggest speed differences I see are the code download time and single-stepping times in the debugger. The ICD 3 I use with PIC32 just isn't as fast as J-TAG on the ARM Cortex-M4 parts that I use. Downloading 40K of code to a board is 3-4x slower on the ICD 3.
-
I am on the opposite end - I primarly develop on a Lenovo X120e for some reason with 8GB RAM, and Eclipse is far faster than Netbeans. MPLABX specifically is extremely slow, but Eclipse is managable. Why the slow machine? It's small and I don't have much room to carry anything bigger, and it doesn't take much of a machine to type... When I am home I can work / debug on a faster machine but I am not nearly as available to write code there. (And even when I am I often still use the subnotebook with an E-350 @1.6GHz in it...)
Code load times crawl on this machine with ICD 3; ARM loading is way faster.
-
Eclipse is far faster than Netbeans. MPLABX specifically is extremely slow,
My experience as well. I run a few instances of eclipse (hi-tide, coide, kds and ccs for example) and they are all fairly fast (on my computer). maplab x is a dog in comparison.
-
What disappoints me the most is that the 64 pin version is not the same pinout as the 64 pin version of the PIC24. I was looking forward to swap the PIC24 on my Digilent Atlys board in order to give it USB 2 host.
-
What disappoints me the most is that the 64 pin version is not the same pinout as the 64 pin version of the PIC24. I was looking forward to swap the PIC24 on my Digilent Atlys board in order to give it USB 2 host.
The PIC32MX is only barely compatible with PIC24, due to the much less flexible I/O remapping. You can often make a footprint that will take PIC24 or PIC32MX but you need to be very careful about which pins you use for which peripheral functions.
You're much more likely to get a PIC24 to fit an existing PIC32MX footprint than vice versa, which is unfortunate as you usually want to go up, not down in capability!
-
It was incompatible to the extent that some of the power pins were in different locations. Which means the only way to put in a PIC32 with USB 2 is to hack up the board, at which point I might as well just disable the existing PIC and wire in a small ARM SoC on an additional board attached to the underside.
-
So, a year later, the PIC32MZ EF is available. By the looks of it, they fixed most of the Errata. Do you think it is actually fixed, or they just didnt report all the issues so far? Because I would not dare to touch the old MZ in a hazmat suit?
-
Ill wait a year and see what shakes out of the EF tree ;) My MX projects will stay on MX.
-
So, a year later, the PIC32MZ EF is available. By the looks of it, they fixed most of the Errata. Do you think it is actually fixed, or they just didnt report all the issues so far? Because I would not dare to touch the old MZ in a hazmat suit?
The EF is much better (as in it behaves like you'd expect a microchip PIC to behave - i.e. a few, well documented, but not show-stopping bugs). I haven't bumped into anything which hasn't worked right yet. I'm pretty close to shipping a new product with the EF in it and don't have any microcontroller concerns at this point. The EC, well that was an entirely different story.
-
So, a year later, the PIC32MZ EF is available. By the looks of it, they fixed most of the Errata. Do you think it is actually fixed, or they just didnt report all the issues so far? Because I would not dare to touch the old MZ in a hazmat suit?
The EF is much better (as in it behaves like you'd expect a microchip PIC to behave - i.e. a few, well documented, but not show-stopping bugs). I haven't bumped into anything which hasn't worked right yet. I'm pretty close to shipping a new product with the EF in it and don't have any microcontroller concerns at this point. The EC, well that was an entirely different story.
100% agreed. Assuming you are using Harmony how are you finding it nowadays?
-
With atmel giving end of life notices on some avr32, I assume the pic32 isn't too far behind.
-
With atmel giving end of life notices on some avr32, I assume the pic32 isn't too far behind.
I would not assume that at all. avr32 always felt DOA. pic32 is used lots. I cant see there being EOL on pic32 models.
-
The PIC32MZ fills a gap beneath Atmel's SAMA5. If Microchip actually start exploiting the virtualization extensions in the PIC32MZ EF there's no current corresponding product on the ARM side. The Cortex-M8 and A35 were just recently announced, and the A53 is in a higher performance class.
-
The Cortex-M8 and A35 were just recently announced, and the A53 is in a higher performance class.
Cortex-M8? When was this announced? Do you mean the R8?
-
Cortex-M8? When was this announced?
PIC32 is so good that it is better than some unknown chip to be announced in the future.
Beat that, :)
-
Cortex-M8? When was this announced? Do you mean the R8?
http://www.arm.com/products/processors/instruction-set-architectures/armv8-m-architecture.php (http://www.arm.com/products/processors/instruction-set-architectures/armv8-m-architecture.php)
-
"ARMv8-M Architecture"
If you even had a rudimentary understanding of those chips, you might have realized that there is this tiny difference between arm artechitecture, like armv8-m, and arm core designation, like cortex m4 or the not-yet-exiatent cortex m8.
-
Assuming you are using Harmony how are you finding it nowadays?
Tolerable. Still a few issues, but mostly I'm using it for the TCP/IP stack which I'm familiar with from it's 8 bit legacy.
Still not so sure about some of the implementation choices, such as for timers, and most importantly async serial. I've pretty much written my own interrupt-driven drivers using PLIB for async since I have timing-critical protocols I work with (modbus RTU as an example, among others).
-
With atmel giving end of life notices on some avr32, I assume the pic32 isn't too far behind.
Microchip doesn't EOL anything. Well very much of anything.
The PIC32MZxxxxEF is drop-in compatible with the PIC32MXxxxxEC. I would expect most designs which are in progress would just drop the EF in instead of the EC when timing is appropriate. I do understand that there are some high volume EC applications out there.
From my FAE and others, I understand that those parts of the EC which work, work well. It was just all of the errata issues which affected such a wide variety of peripherals that made the EC relatively useless for many applications.
-forrest
-
With atmel giving end of life notices on some avr32, I assume the pic32 isn't too far behind.
Microchip doesn't EOL anything. Well very much of anything.
Farnell still stock the PIC16C54 - Microchip are one of the few manufacturers that keep stuff in production long term. What they do tend to do is introduce newer (usually pin compatible) parts and increase prices on the older ones.
-
"Microchip doesn't EOL anything. Well very much of anything."
Those are quite contradictory to each other.
Try to get a pic1650, 1654, 1656, 1663, 1664, 1670, etc. From Microchip would be quite difficult, I assume, :)
-
Try to get a pic1650, 1654, 1656, 1663, 1664, 1670
those were never Microchip products. (General Instruments, perhaps?)
-
"Microchip doesn't EOL anything. Well very much of anything."
Those are quite contradictory to each other.
Try to get a pic1650, 1654, 1656, 1663, 1664, 1670, etc. From Microchip would be quite difficult, I assume, :)
Let's try to clarify.
Microchip tends to not 'EOL' any part that they're actually still selling - as opposed to other vendors who discontinue when they aren't selling 'enough'. There are few exceptions, AFAIK usually related to acquisitions and fab capabilities.
Based on my understanding, if they can still make it in their current FAB, you can still order it. You may have to buy a wafer full of the parts, or meet some other minimum order (i.e. if it uses a non-standard leadframe or similar).
If you look at the EOL list at:
http://www.microchip.com/mymicrochip/Reports.aspx?type=eol (http://www.microchip.com/mymicrochip/Reports.aspx?type=eol)
You'll find they almost all fall under the category of:
1) Discontinuation of parts they acquired from someone else and can't make in-house and don't have volume to continue making them.
2) A discontinuation where there is a direct replacement which requires no design changes. For instance, a SPI memory where they're discontinuing the 10Mhz part and only continuing to sell faster parts which are 100% drop in compatible.
3) Discontinuations necessitated by no longer being able to make a given type of part - for instance, some of the rfPIC's were discontinued because the outside fab which were making these for them quit being able to do the RF process that was needed.
I also didn't see a single 'normal' PIC microcontroller on the list as far as I could go back. The only exception was a dsPIC that they said they were going to discontinue, then a couple months later said 'sorry, we changed our minds, and we're going to continue making it'. (I don't count weird things like the dsPIC and the integrated PIC and MEMS accellerometer as 'normal'. I'm talking a normal processor using normal processes).
Compare that with other vendors...
-
"Microchip doesn't EOL anything. Well very much of anything."
Those are quite contradictory to each other.
Try to get a pic1650, 1654, 1656, 1663, 1664, 1670, etc. From Microchip would be quite difficult, I assume, :)
Let's try to clarify.
Microchip tends to not 'EOL' any part that they're actually still selling - as opposed to other vendors who discontinue when they aren't selling 'enough'. There are few exceptions, AFAIK usually related to acquisitions and fab capabilities.
Based on my understanding, if they can still make it in their current FAB, you can still order it. You may have to buy a wafer full of the parts, or meet some other minimum order (i.e. if it uses a non-standard leadframe or similar).
If you look at the EOL list at:
http://www.microchip.com/mymicrochip/Reports.aspx?type=eol (http://www.microchip.com/mymicrochip/Reports.aspx?type=eol)
You'll find they almost all fall under the category of:
1) Discontinuation of parts they acquired from someone else and can't make in-house and don't have volume to continue making them.
2) A discontinuation where there is a direct replacement which requires no design changes. For instance, a SPI memory where they're discontinuing the 10Mhz part and only continuing to sell faster parts which are 100% drop in compatible.
3) Discontinuations necessitated by no longer being able to make a given type of part - for instance, some of the rfPIC's were discontinued because the outside fab which were making these for them quit being able to do the RF process that was needed.
I also didn't see a single 'normal' PIC microcontroller on the list as far as I could go back. The only exception was a dsPIC that they said they were going to discontinue, then a couple months later said 'sorry, we changed our minds, and we're going to continue making it'. (I don't count weird things like the dsPIC and the integrated PIC and MEMS accellerometer as 'normal'. I'm talking a normal processor using normal processes).
Compare that with other vendors...
and then scale based on the number of different parts Microchip make, many of which are pin-compatible and at least very nearly object code compatible.