I'm considering PIC32MK MC (specifically PIC32MK1024MCF100) for a new product, but I'm a bit nervous. About two years ago we switched to another vendor for our 32-bit MCUs because the general state of Harmony and MPLABX was pretty awful. In fact, whenever we used PIC32 and dsPIC (which we did in several products), we only used old parts supported by MPLAB 8 and the old peripheral libs and MLA code.

I'm looking into this PIC32MK because with its six QEIs, ADC, and DAC it could reduce our component count appreciably, it has the FPU (with single- and double-precision), the errata doesn't look too terrible, and the price is an offer I can't refuse (no horse head necessary). Of course, this means (re-)taking the plunge into the new software tools.

Has anyone worked with this part family? I'm looking for thoughts, experiences, and insights into any undocumented "gotchas!" that we should look out for. Also, has Harmony and MPLABX IDE improved in the last two years?

we only used old parts supported by MPLAB 8 and the old peripheral libs and MLA code.

why? couldn't you write your own drivers?

At this day is would say that official support (read: harmony) for the 32MK is a mess, for parts that were released in 2016 i would like to add.I hope things improve on the harmony side in the next release because it's been one month (some hours here and there in my free time) and for the life of me i can't get the USB host stack to work, you MUST use harmony for USB and it's like it never got out of beta state, and i WANT to use the 32MK for a project because i want to use the two USBs for simultaneous host and device (which harmony support on 32MZ but not on 32MK, really? can't select both at the same time, can't say let USB1 be device and let USB2 be host)

RE: Performance, i would suggest you get a devboard and write some benchmark code because when i was evaluating new micros a year ago in my tests a dsPIC(33EP MU) performed equally or better (thanks to a "better" instruction set, more independent peripherals and overall less latency). By the way I don't use floating point but a lot of fixed point math (so i actually use the DSP engine) and the dsPIC33CH finally put a nail on the subject.

To sums things up, i was in awe when the 32MK was released, thinking it would be the time i finally moved from 16 to 32bits. I was disappointed in the actual performance, with the actual peripherals but now i am trying again to make something out of it.. and i'm failing because the support for its uniquieness (dual USB) isn't there yet

To answer your question, yes we could write our own device drivers. We prefer to avoid that if we can, which is why we used older parts, supported by the older MPLAB8 tools, supported by existing code that we already wrote and tested... But ironically writing our own device drivers is what we'll have to do with the PIC32MK. We are designing our new board with it right now.

Fortunately for us, we are not using USB on this board. As you said, if you use USB you're pretty much stuck with Harmony. (Unless you want to develop a USB stack -- I don't think so!!) Actually, for us it's a waste that this PIC32MK part has two USBs -- and on dedicated pins. We're not utilizing USB and we cannot utilize those pins for other functions. But no matter. When we made the decision to use the PIC32MK, we also made the decision not to use Harmony but to write our own device drivers. Fortunately we're only using the UART, SPI, QEIs, ADCs, DACs, and DMA. The rest of the software is computation (yes, utilizing floating point!). There is no user interaction in this code. So that should make our job much easier than if we needed many more peripherals.

Anyway I've discovered during hardware design that Harmony support for the PIC32MK is indeed lacking. Supposedly the framework recognizes this part but the MHC pin mux does not know anything about the QEIs and probably other peripherals. I say "probably" because when I realized that pin mux doesn't support the QEIs, I stopped using it, created a spreadsheet and made all the pin assignments manually. Having to manually resolve conflicts was a big headache but I got it done.

All of the peripherals you mention are pretty basic so cutting your own code should be straight forward.Some people need a bit of time to come to grips with the ADC, especially if they are making multiple measurements linked to using DMA in some of the more advanced modes - but you would have exactly the same problems with any library code but this way you have full knowledge of what exactly is happening in the code.Susan

The large frameworks have their place. Complicated things like Ethernet and USB have become commodities and customers expect those features in products; if you had to develop those features in-house it would take far too long and cost far too much. In those cases, the large heavy-duty frameworks solve a very big problem and help get products to market. But... when you need the low-level code where exact sequencing of events and timing are crucial, I definitely like to have the simplest possible code and to know exactly what it's doing. It's amazing how much work 1k of efficient code can accomplish! In our current project, the PIC32MK is handling only low-level details so thankfully it won't be necessary to grapple with Harmony. I hope Microchip continues to develop Harmony to make it a better framework. It seems that integrating Atmel into the software tools has taken away a big chunk of engineering time from Harmony development.

Agreed - USB and IP are the two exceptions I make when talking about libraries/pre-defined stacks.It is just that you mentioned UART, SPI, QEI, ADC, DAC and DMA which all fall into the 'basic' category as far as I am concerned.I'm currently playing with some ARM code generated by the STM32CubeMX software to use the STM32 HAL library and it is layer upon layer of code and large structures with lots of variables and values because they have tried to abstract the hardware into a few interface functions. To use a timer in just about any PIC MCU requires about 10 lines of setup - in the HAL it requires about 10 lines to set up the parameters to call the function that goes through several layers to interpret what I've said - and then I have to work out how to set up the interrupt callback!Sometimes the old ways are the best ways!!! (Same reason I'm not a fan of MCC!)Susan (it's Monday so it's 'Grumpy Susan' day!)

The trouble with these libraries is that they do not take away the need to understand the hardware. My experience has been that in order to use a high level library, one must understand MORE, not less, because one must understand both the hardware and the library, in order to understand how to use the library. In a sense, it's easier just to learn the hardware.

I will say however that some level of "portability" is important in software. We use MCU families across several vendors and every time we need a different chip because of some additional peripheral, there is an effort in porting our code to that.

twelve12pm wrote:...I will say however that some level of "portability" is important in software. We use MCU families across several vendors and every time we need a different chip because of some additional peripheral, there is an effort in porting our code to that.

Vendor libraries give you the same portability as writing directly for the hardware - everything changes when you change vendors and often even within a single vendor.