Microchip’s Harmony supplements MPLAB (for PIC32 family)

[andersm]

Feedback to Microchip? You kidding?

They do respond and react to bug reports. On the other hand, not filing reports is a good way to ensure the bugs do not get fixed.

[AlfBaz]

It wasn't that long ago (or maybe it was) when MC support was outsourced (or at least changed) and for the very worse. I wish I had kept transcripts of communications before and after this change. Before it was like you were conversing with an engineer and things got done! After it was like you were talking to an obstinate 10 year old and they would close a ticket as resolved when clearly it wasn't

[dannyf]

I am definitely interested.

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.

What does that mean? How did you do to lead you to conclude that the library was "completly missing"?

One other: PIC32MX795F512H or similar has 6 serial, only the upper 3 did not had the libraries made.

Meaning?

[Rufus]

After it was like you were talking to an obstinate 10 year old and they would close a ticket as resolved when clearly it wasn't

My limited experience with Microchip support has been pretty poor. Like it was hard to tell if they didn't read the ticket or read it and didn't come close to understanding it. That said I have some sympathy for Microchip, judging by the typical drivel that gets posted on the user forums I dread to think of what 90% of their support tickets look like.

I look for one on the first page and someone is asking if he sets the CTMU current source too high for his calibration resistor will it generate enough voltage to damage the chip and that is one of the better dumb questions.

[tszaboo]

I am definitely interested.

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.

What does that mean? How did you do to lead you to conclude that the library was "completly missing"?

One other: PIC32MX795F512H or similar has 6 serial, only the upper 3 did not had the libraries made.

Meaning?

Meaning, that after my code was not working, I dig down, to find that it was writing registers which doesnt exist, and it had configuration options which were completely different. Even the name was wring. This was 3-4 years ago, pardon me if I dont remember correctly.
On PIC32 it was straitforward. You had UARTPRINTF1 2 and 3 (or whatever it was called) but nothing above 4.
As I said, I tryed to talk to them. They said, talk to the local distributor.

[poorchava]

I don't use ready made peripheral libraries in 99% of the cases. Partially the reason is that I work with different controllers (MSP430, AVR, PIC, ARM) and I'd have hard time remembering all the syntaxes and quirks for every particular library.

Other thing is that those libraries very often make code extremly bloated in order for it to look more uniform or comply with some standards (eg. CMSIS).

I do use higher level software libraries (for example DSP stuff and graphics engine) but I write all the hardware layer myself. Especially when using Microchip - I went through days of hair pulling a bit too many times to trust their libraries.

[dannyf]

I find the explaination ("the chip being faulty") not terribly believable in this case and there likely is something else at work.

Meaning, that after my code was not working, I dig down, to find that it was writing registers which doesnt exist, and it had configuration options which were completely different. Even the name was wring. This was 3-4 years ago, pardon me if I dont remember correctly.

First of all, if the registers don't exist, or the names were wrong, you couldn't have compiled the code and you would have never get to assess if it worked or not.

But more importantly, the 4msps "mode" works identically to the 2msps mode in that the registers are exactly the same. The 4msps mode works on chips with 2 adc sars and the 2msps on 1 adc sars. You just need to pick your chip and pick your sampling channels (odd vs. even) and you get the 4msps performance (on those chips with 2 sars and on those channels with simultaneous sampling). No extra registers to fiddle and the plib code for the 2msps mode is identical to the plib code for the 4msps mode.

Your case, quite frankly, sounds like either you didn't read the datasheet to understand how your chip works; or to put it more charitably, you didn't remember the story right.

[dannyf]

he sets the CTMU current

The code examples on CTMU in the Reference Manual are actually incorrect. If one were to follow it, one would have turned off the current source thus rendering the rest of the code in-operable.

[dannyf]

Other thing is that those libraries very often make code extremly bloated in order for it to look more uniform or comply with some standards (eg. CMSIS).

On a minimalistic scale, all CMSIS does is to initialize the system and then call main(). Other than the vector table (which another start-up scheme would need), you get I would suspect no more than 500bytes of extra.

Plus, nowadays, no one offers non-CMSIS start-up code on new ARM chips anymore. I don't see how you can avoid cmsis.

[tszaboo]

I find the explaination ("the chip being faulty") not terribly believable in this case and there likely is something else at work.

Meaning, that after my code was not working, I dig down, to find that it was writing registers which doesnt exist, and it had configuration options which were completely different. Even the name was wring. This was 3-4 years ago, pardon me if I dont remember correctly.

First of all, if the registers don't exist, or the names were wrong, you couldn't have compiled the code and you would have never get to assess if it worked or not.

But more importantly, the 4msps "mode" works identically to the 2msps mode in that the registers are exactly the same. The 4msps mode works on chips with 2 adc sars and the 2msps on 1 adc sars. You just need to pick your chip and pick your sampling channels (odd vs. even) and you get the 4msps performance (on those chips with 2 sars and on those channels with simultaneous sampling). No extra registers to fiddle and the plib code for the 2msps mode is identical to the plib code for the 4msps mode.

Your case, quite frankly, sounds like either you didn't read the datasheet to understand how your chip works; or to put it more charitably, you didn't remember the story right.

You are kidding me, right? The library they put for the GS series chip was the library for other chips. It did not compile, as the code they give me was fucked up. And the GS series is different from the others.
http://www.microchip.com/forums/m430289-print.aspx 2nd post.
I got it working, but it took me much more time to implement, writing directly to registers, flipping bits and magic numbers. And head banging to the wall. Ultimately, the project did not succeed because we run out of time.

[dannyf]

You are kidding me, right?

Not really, particularly the part that I don't think you understood the datasheet and how the adc modules work.

The library they put for the GS series chip was the library for other chips.

I thought that's the purpose of a library.

It did not compile,

It compiled perfectly for me.

as the code they give me was fucked up.

OK, I thought you said earlier that you didn't have the code (easily). Post the code that you got from Microchip and we will see just how "fucked up" it is.

And the GS series is different from the others.

Any series is different from other series, by definition.

[bxs]

..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.

In the past I also used to lost time tracking bugs in mchp libs, I almost always ended up having a patched lib for this project, a patched lib for that project, etc. But enough is enough.

Of course I have libs made by me, but I get a new PIC and here I go updating the libs...
For some projects I simple don't use any lib, do it all the direct way with registers.

Going back to mchp Harmony, just out of curiosity I tested it a bit, and guess what, bugs and more bugs.

I'm also one of those that think the business model of mchp software is simple wrong.

[Harvs]

I gave it a go over the weekend to assess it for a job.  In theory it would have been really good, as it has libraries for all the main components of the product.

However it doesn't really look very finished to me. I just tried to get a project with the parallel port library to compile and there's stuff missing.  Lodged a help request and after a few days it's all quite.

There's always a possibility that I got something wrong, but it's pretty unlikely when functions deep in their libraries are referencing #define'd stuff that a complete search of the Harmony and XC32 libraries reveals nothing.

They probably need a couple of revisions before it's ready to use in anger.

[dannyf]

I usually don't try anything like that, unless they are a few years old and proven.

more so for anything Microchip,

having said that, those things aren't meant to be tried briefly: you need to read a lot if documents and the code base, and lots of examples to see how it is meant to be used.

essentially, lots of investment and commitment. That's why libraries are expensive and highly helpful at the same time.

[Harvs]

Yeah I know, but you need to a do a cull somewhere to narrow down your field of potentials before investing real time.  This didn't make the first cut...