Microchip’s Harmony supplements MPLAB (for PIC32 family)

[mariush]

Saw this on Dangerous Prototypes blog:




MPLAB Harmony is a new process for software design, development, testing and documentation. It consists of a set of peripheral libraries, drivers, system services, middleware, and third-party code that will make it easier to create all types of applications. It comes with examples that show proper abstraction and use of the new software tools, such as device drivers, that is new to the Microchip software development platform. The code is written in a highly reusable format, MPLAB Harmony will save everyone using it significant time and effort. As a direct result of the MPLAB Harmony process, users now have the capability of running more than one stack or more than one instance of a stack interface at a time. MPLAB Harmony also creates standard Application Programmer Interfaces (APIs), and naming conventions to improve consistency and ease of use. MPLAB Harmony implements an Operating System Abstraction Layer (OSAL), which allows seamless integration of commercial RTOS such as FreeRTOS, Micrium and others.


All PIC32 families will be supported with Beta MPLAB Harmony for Nov’13 release. Full production support for all PIC32 families will be with MPLAB Harmony v1.00. Note that this is not open source software. With regard to licensing, Microchip states,

Microchip’s standard USB, GFX, TCP/IP, and peripheral driver support for MPLAB Harmony will be available free of charge in the same way as MLA, In some cases, new capabilities or features may not be offered for free. MPLAB Harmony will run without a RTOS; however, if a user chooses to include a RTOS, they will need to address those costs separately. For example, freeRTOS is available as part of install package, but users needing OpenRTOS will have to purchase the license from microchipDIRECT.

Your thoughts, opinions ?

[JTR]

Yeah, it is pretty much all dangerous prototypes posts these days, someone else's blog, app note etc.

[dannyf]

proper abstraction

Pretty much a must for today's embedded programmers. However, many people struggle with that, particularly on mcus that are not designed with that.

The code is written in a highly reusable format

Another must for today's embedded software development. You essentially trade off performance for quicker development time and more reliable code (and lower development cost).

Both are where embedded coding is headed.

[mikeselectricstuff]

meh.

Ok I don't generally get involved in highly complex, big project stuff, for which this may be appropriate, however I've often found it way too much hassle to learn a big pile of library stuff instead of just talking to the hardware.

The problem with abstraction is it's yet another layer to wade through when trying to find bugs, as well as a significant increase in the possibilities for bugs to get there, as it adds to the normal list of possibilities, so instead of the typical causes (in typical order of likelihood) :
Bugs in your code
Errors in manufacturer header files
Errors or unclear info in datasheets
Compiler bugs
Silicon bugs

You now have in addition :
Bugs in the in the library code (been there - NXP CMSIS)
Errors in documentation of library code
Errors in your understanding of what the library code can & can't do, or its limitations

You can also get all sorts of subtle issues as libraries grow over time to support new devices with subtle differences that the library writer may not have noticed.

I hate it when even simple examples are wrapped up in all this sort of stuff, so instead of a simple single-file source to demonstrate a feature, you have to dig through a mountain of header files to see where things are defined.

In some cases, this sort of thing can certainly be the way to go, but to claim it as a universal panacea is nonsense.

I also think the whole portability thing is overstated - how often do you actually move a big project to a platform that's different enough to be an issue?
 

MPLAB Harmony will save everyone using it significant time and effort

Bullshit. Someone using it for an inappropriate application will waste a lot of learning-curve time. Like all tools, the main trick is to decide when you need to use it.

The stuff about "The code is tested, known to work, trusted" misses out a hugely important aspect- it can only ever be tested for specific combinations, environments, loads etc. and anyone who believes thay can just plug it all together and have a working product is likely to get a bad shock somewhere down the line.

IMO it's also at least partly about vendor lock-in, and a "me too" response to ARM CMSIS - learn the Microchip libarries & you're less likely to move to ARM & vice versa.

[Rufus]

Your thoughts, opinions ?

I think they have put a lot of work into this (the install is about 880MB of files) and it is free while their compilers and support are frankly shitty, cost money, expect you to take out maintenance subscriptions, and have a very obnoxious (and recently buggy) licensing and online activation scheme.

I like some Microchip parts and I am set up to develop with them, their shitty unprofessional compiler offering turns me off Microchip far more than Harmony will ever turn me on. They obviously have money to invest in supporting their product and choose to spend it on Harmony (and MPLABX) while their compilers are lacking, their support is poor, and the online forum is just an embarrassing joke.

As for Harmony being any good I won't know until/if I use it to develop a real product, I suspect it will be a pain in the arse. 

[dannyf]

their compilers are lacking, their support is poor, and the online forum is just an embarrassing joke.

Through the IDEs in there as well. MPLAB was usable, in ancient way. MPLABX is a joke - that whole team should be fired and a new approach taken.

I actually love PIC24F - resource rich and well thought out. If only they could get the tools right...

Their lower-end stuff is also quite good. However, I try my best to avoid PIC18 / C18 - thank god C18 is dead now - where were they thinking?

[mikeselectricstuff]

Yes - I'd certainly rather have seen the money go into improving the core tools like compiler and linker - still significantly behind where IAR were a few years ago.
Microchip have got so many things right, from silicon features and package options to good availability and a cheap priogramming service, it's a shame that their tools are lagging behind.

[amyk]

I think they have put a lot of work into this (the install is about 880MB of files)

I wonder how they managed to produce 880MB of anything for something intended for small microcontrollers. Is it basically a bundle of source code to do practically anything and everything with them?

[dannyf]

The video talks about a lot of things that resonate with me and my experience: reusable / portable and modular code base, quick to market, smooth development process and lower development cost.

Looking at what I do personally, I use an almost identical approach across a wide range of hardware (ARM from multiple vendors, 8051, AVR and PIC), with a proprietary layer that is called from my code to perform identical functions on those cihps: pin operations, timers, adc, uart, etc. So when I write code, I focus on the application of those little modules rather than those little modules themselves. The resulting application can be easily ported to multiple platforms, without too much worry and additional debugging.

For example, a simple blinky for me starts with fuse settings (that ranges from ~50kb on some platforms to nothing on others), a module to reset the mcu (from a few statements to an empty one), a module that manages port operations (from 30kb on some to a hundred bytes on others), a delay module (from a few lines of software delays to a few kb of timer/systick based delays on others). Some implementations of the above may also require additional support (like on the ST and NXP or TI platforms).

The application itself is just a couple of lines (flip a pin and then waste some time) and it remains the same from chip to chip. Setting up a project is a big undertaking for me - it is not uncommon for me to copy 20 - 30 modules of my own into a project folder. However, getting a project to run and debug it is a breeze.

produce 880MB of

It was a 140MB download for me.

[Rufus]

I think they have put a lot of work into this (the install is about 880MB of files)

I wonder how they managed to produce 880MB of anything for something intended for small microcontrollers. Is it basically a bundle of source code to do practically anything and everything with them?

It is the follow on from their application libraries which include TCPIP and USB stacks, file system, graphics, RTOS support and processor peripheral libraries. Then add MPLABX plugins for application configuration and project generation etc.

880MB is the installed size. The peripheral library (object code) files for all the PIC32 variants make 220MB of that 880.

I played with it briefly but as I said you won't know if it is any good till you try to make a real world product with it.

[mikeselectricstuff]

..and once again I got bitten by another library bug & wasted another couple of hours.
 
Microchip PLIB this time - an incorrect value somewhere in the library writes interrupt priority bits to the wrong register.

OK This may be slightly more readable, once you've dug through the docs to find the right syntax...

INTSetVectorPriority(INT_SPI_2_VECTOR, INT_PRIORITY_LEVEL_2);

but this would have been quicker to look up, and actually work.

IPC9bits.SPI2IP=2;

If I hadn't already got SPI1 working and just found this when swapping to SPI2, I hate to think how much longer it would have taken to track down.

[tszaboo]

..and once again I got bitten by another library bug & wasted another couple of hours.
 
Microchip PLIB this time - an incorrect value somewhere in the library writes interrupt priority bits to the wrong register.

OK This may be slightly more readable, once you've dug through the docs to find the right syntax...

Now they
INTSetVectorPriority(INT_SPI_2_VECTOR, INT_PRIORITY_LEVEL_2);

but this would have been quicker to look up, and actually work.

IPC9bits.SPI2IP=2;

If I hadn't already got SPI1 working and just found this when swapping to SPI2, I hate to think how much longer it would have taken to track down.

Happens every fking times with microchip. I did not have a single project, where the code they supplied would "just work". I had at least 3-4 project, where they completely forgot to write the library for a certain peripherial built into the microcontroller. My favorite two example is the dsPIC33: it has a 1 MSPS 10 bit ADC, which makes it unique among the 16 bit PICs, and there is no library for it. PIC32: There is 6 serial ports on the high-end chips, they did not write the library for 4-5-6. Not to mention if they have an errata for something, expect the supplied library completely doing opposite of that.
Now they have a big ZIP with a name on the not working code. Excellent.

[notsob]

A very interesting comment from gerry
http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/

I have to agree, if microchip doesn't see that their compiler needs to support their silicon sales and not be a profit centre by itself, it's about time their heads came out of wherever they are and looked around at the real world.

[dannyf]

" did not have a single project, where the code they supplied would "just work". "

You seem to have thus highly valuable and extremely uncanny ability to spot poorly supported chips from miles away.

Maybe for your next assignment, you should instead pick that you didn't pick.

[mikeselectricstuff]

A very interesting comment from gerry
http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/

I have to agree, if microchip doesn't see that their compiler needs to support their silicon sales and not be a profit centre by itself, it's about time their heads came out of wherever they are and looked around at the real world.

If you look at how trivial  the "protection" is on the Microchip compilers, it is clear they are only paying lip-service to the concept of charging for tools.

Something else to note is that although the free version of the 8-bit compiler is pretty poor and appears to actively pad code with useless junk, this is far from being the case for the 16 and 32-bit ones, which IME only give typically 10-20% improvement in code size or speed (YMMV, obviously)

[dannyf]

"A  very interesting comment from gerry"

I am not sure about that.

His central assumption is that Microchip wants to be in the arduino business.

The amaturer mkt is tiny and the arduino mkt is even smaller. Even if the arduino mkt is 1000x bigger than it is now, it woulD still be a rounding error.

If you argue that the true value of arduino to the chip makers is that those arduino users become engineers who tend to favor chips they are more familiar (aka arduino sales = samples), ask yourself when was last time you design an arduino into a real product: arduno is designed by and for non-engineer types.

Microchip's problem isn't that it didn't get into the arduino business - arduino will not save atmel from dying. Microchip's problem is that they don't have a viable 32-bit strategy.

[dannyf]

If I were to design an arduino like product, I wouldn't pick 8-bit pics for two reasons:

1) Lack of vectored interrupts,
2) Too fragmented offering: PICs are designed for an era where hardware is expensive and software is cheap. Unfortunately we live in a total different world and the lack of consistency from chip to chip means porting code is difficult. Atmel has made a conscious efforts to maintain a high degree of similarities.

The one product where Microchip did everything right is the pic24. Except that they spend little marketing that, probably for fear that it would kill their 8-bit business.

Too bad for them.

[dannyf]

On paying compilers: I don't know of one firm that altered its chip choices due to high purchase prices for the compiler.

And there are many chip cendors charging lots of money for their compilers.

It may be an issue for a student / ammaturer, however.

[Rufus]

If you look at how trivial  the "protection" is on the Microchip compilers, it is clear they are only paying lip-service to the concept of charging for tools.

I can't read it that way. They are not trying very hard to stop people using them for free. They are trying quite hard to restrict and make licensing and activation a pain in the arse for people who buy it because they won't use it for free.

It is as a bad a case of rights management causing more pain to paying customers than 'pirates' as I have come across. I think I already posted in this thread that I can not fathom how they can invest so much in MPLAB X and now Harmony while being so anal about compilers.

The protection on Hi-Tech compilers was much more robust (but still cracked) the licensing and activation was as painful. Hi-Tech had the expensive HPA maintenance scheme and Microchip seemed to inherit it all and apply it to their compilers. All Microchip got from the Hi-Tech acquisition was PIC 8 bit compilers and their own runtime library (which the dumb bastards still won't distribute source for) and the licensing and HPA crap. Whoever is in charge of the Microchip compiler 'program' is an idiot. Whoever is responsible for their online forums likewise.

[dannyf]

I sense some anger management issues somewhere.

[tszaboo]

Maybe for your next assignment, you should instead pick that you didn't pick.

I've stopped writing code, and become purely hardware guy. Thus this is not my problem anymore. Nor do I use PICs, which is their loss.

[dannyf]

You lost an easy opportunity to monetize your highly valuable and hugely in-demand skill.

[Bassman59]

If you argue that the true value of arduino to the chip makers is that those arduino users become engineers who tend to favor chips they are more familiar (aka arduino sales = samples), ask yourself when was last time you design an arduino into a real product: arduno is designed by and for non-engineer types.

There is this theory that a student or amateur will learn something like an Arduino (or a PIC, or a whatever), get hired, and then will somehow convince the rest of the engineering team that they should all switch to Arduino (or PIC, or whatever). (This applies to choice of FPGA vendor, CAD tools, etc.)

Of course that's complete bullshit; the newbie will use whatever processor (or FPGA, or whatever) family already in use by the employer, for all sorts of really good and obvious reasons.

(Obviously a good engineering team will always evaluate new things coming down the pike, but there needs to be compelling reasons to change from processor family X to Y.)

-a

[dannyf]

Thus this is not my problem anymore.

Even if you don't intend to benefit financially from  your knowledge, you can still share with us what specific chips have those deficiencies so 1) we can avoid them; and 2) Microchip may be able to fix them to bring you back to boost their PIC sales.

Everyone loses if you bury that piece of knowledge.

[tszaboo]

Thus this is not my problem anymore.

Even if you don't intend to benefit financially from  your knowledge, you can still share with us what specific chips have those deficiencies so 1) we can avoid them; and 2) Microchip may be able to fix them to bring you back to boost their PIC sales.

Everyone loses if you bury that piece of knowledge.

Feedback to Microchip? You kidding?
Manufacturers seems to be more interested how their website looks like, rather than how their datasheets, application notes or code. They really don't care. If the firmware programmer has problem with something, that is at the very end of a chain. The design is made, management approved it, manufacturing working on it... The best they would do is to point you to the local sales office, what they did to me.
Even big players like TI hangs up on you nowadays. TI pointed me to their E2E "community" for technical support.

But if you are really interested, the dsPIC33xxxGSxxx 10 bit 4 MSPS ADC library was completly missing, and the dsPIC3 10-bit, 1.1 Msps ADC library was in place. Completly different ADC architecture and registers.
One other: PIC32MX795F512H or similar has 6 serial, only the upper 3 did not had the libraries made. It wasn't that much of an issue, I could write it, but their peripheral library supposed to cover everything. I had so much trouble with them, they've gone to the blacklist. Right next to Maxim.