PIC32 and Harmony - Page 1
Forum section: electronics / general

author: engineer_in_shorts
author_rank: Regular Contributor
timestamp: July 09, 2014, 06:14:39 pm
content: Hi,I know this has been discussed before somewhere.In my company we are a "microchip house", using PIC16/18 almost exclusively. The application area is not demanding in low power or speed and the companies products are low volume, high value stuff with product life cycles in the 10-20year mark. Due to Microchip policy on stock and discontinuation, PICs have always been available and very useable.On newer projects we have started to use PIC32. We did check out some ARM parts (ST Cortex) but the availability to us in 2010/2011 particularly for smaller orders put us off.So anyhow, the first product based on PIC32 is about to have it's first final (product) release and while poking around with firmware for hardware test binaries I was interested in the newer v1.32 of the XC32 compiler. I have noted that they have added this in the PLIB:Code:#ifndef _SUPPRESS_PLIB_WARNING#warning The PLIB functions and macros in this file will be removed from the MPLAB XC32 C/C++ Compiler in future releases#endifIn general whenever we make make firmware changes to a model in current production we try to build in the latest version of the tools and run tests.So we are being told to start using Harmony as PLIB is phased out (before it is actually matured into a stable base). I have to take note of that for the current projects but the more I look at Harmony the more I groan. My gut instinct is that the learning curve is just not worth it, but i do not know that until i am 1/4 along that curve.So for current projects do we change the driver modules for:1. Direct manipulation of SFRs?2. Control access via Harmony?Bear in mind we already good separation and encapsulation of the driver layer - who doesn't. I am not sure harmony benefits us at all. Using PLIB already felt a bit 'bloaty' but for the most part it was only macros for the lazy.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 09, 2014, 06:37:43 pm
content: im refusing to upgrade from plib to harmony. plib at least ships with the ide/compilers, harmony does not. harmony is still NOT 1.0 ready. lots of shit broken in the current 0.8something release. right now, harmony really sucks ass. plib works (for the most part lol!)they dont even have all the 32MX chips in harmony right now, so if you fire up a new project and depending on which chip you pic, nothing will work at all and just give you unsupported chip errors.you can stick to the v1.31 compilers and you wont have this issue with plib pop up.

author: dannyf
author_rank: Super Contributor
timestamp: July 09, 2014, 08:04:13 pm
content: QuoteThat's quite rare these days,Code:#ifndef _SUPPRESS_PLIB_WARNING#warning The PLIB functions and macros in this file will be removed from the MPLAB XC32 C/C++ Compiler in future releases#endif1. it is only a warning;2. as long as your parts are supported by plib, it doesn't matter.QuoteYou aren't alone. Forcing people to migrate from a mature product to an inmature product isn't good for business.

author: engineer_in_shorts
author_rank: Regular Contributor
timestamp: July 09, 2014, 08:14:18 pm
content: I just did a build and passed initial testing with v1.32. So I think I will put _SUPPRESS_PLIB_WARNING into the pre-processor for all build configurations, get the guys to run all the tests tomorrow. If that passes we will move production to v1.32 next time we have a patch to do.In the mean time, it leaves me wondering on the way forward for other projects. I suppose i should revise my options list:1. Direct manipulation of SFRs.2. Use PLIB3. Control access via Harmony?The way i see it, PIC32/Harmony is Microchips now actually understanding the ARM/Cortex marketplace and after glimpsing at larger projects with an RTOS, realising they should promote code encapsulation for large code base, thread safety for RTOS and it also allows application portability. However all of this has always been done by the RTOS vendor, not the chip vendor, as they are financially independent of the silicon choice. Why would you want greater portability with PIC32 and Harmony if your only choice is another PIC32(MZ or whatever). Hmmmmm.For the record, our projects are not even complex on communication and therefore not feeling the need for an RTOS.....

author: dannyf
author_rank: Super Contributor
timestamp: July 09, 2014, 09:13:17 pm
content: QuoteIt doesn't have to be one of the two (or three). For example, you can mix 1 and 2 for some functions, as long as you retain the common interface. I do that via a set of middleware that allows me to switch between oem libraries and my own.QuotePlib is really 1980s coding. Today's libraries tend to be coded different and Harmony is Microchip's efforts to remain relevant.

author: boz
author_rank: Regular Contributor
timestamp: August 19, 2014, 09:06:17 am
content: Microchip may depreciate plib but it will not remove it from the compiler for any time in the foreseeable future for the simple reason you could not compile hello world into a PIC32MX110 using harmony.

author: Wilksey
author_rank: Super Contributor
timestamp: August 19, 2014, 10:31:43 am
content: We are muchly a Microchip company also, started out with AVR, then moved along to the PIC range, not 100% sure the reasoning why now.Anyway,One thing I have learnt from the past 'n' number of years I have been working with Microchip and their toolchains is that whenever you build a project for a particular product, keep the installation binaries for the compiler.I had a case where I downloaded the same compiler version from the Microchip website as I had compiled with and they had changed something so I2C didn't work any more, I can't remember exactly what the issue was but doing a diff on the dev machine and my machine showed about 20 differences in files, and I know (because I installed it and wrote the firmware) that the dev machine has the original installation files untouched on it., it was a year or so after the original build, and it isn't the first time this has happened either.I am not quite sure what they do to their ICD's either, I have a pickit2, pickit3, PM3, and an ICD3, the ICD3 is the only one that keeps crashing! I was tempted by the ICE, but never had a "real" need for it so far. I bought the ICD3 from Farnell and they have so far replaced it 3 times, 4th time lucky? It's been a year now with no signs of death (and occasional lock up), thats got to be good, right?