Microchip’s Harmony supplements MPLAB  (for PIC32 family) - Page 1
Forum section: electronics / general

author: mariush
author_rank: Super Contributor
timestamp: December 30, 2013, 04:28:17 am
content: 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 ?

author: JTR
author_rank: Regular Contributor
timestamp: December 30, 2013, 05:25:21 am
content: Yeah, it is pretty much all dangerous prototypes posts these days, someone else's blog, app note etc.

author: dannyf
author_rank: Super Contributor
timestamp: December 30, 2013, 02:43:29 pm
content: QuotePretty much a must for today's embedded programmers. However, many people struggle with that, particularly on mcus that are not designed with that.QuoteAnother 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 30, 2013, 03:46:17 pm
content: 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 codeErrors in manufacturer header filesErrors or unclear info in datasheetsCompiler bugsSilicon bugsYou now have in addition :Bugs in the in the library code (been there - NXP CMSIS)Errors in documentation of library codeErrors in your understanding of what the library code can & can't do, or its limitationsYou 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?QuoteBullshit. 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.

author: Rufus
author_rank: Super Contributor
timestamp: December 30, 2013, 03:49:11 pm
content: Quote from: mariush on December 30, 2013, 04:28:17 amI 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.

author: dannyf
author_rank: Super Contributor
timestamp: December 30, 2013, 04:14:59 pm
content: QuoteThrough 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?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 30, 2013, 04:37:58 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: December 31, 2013, 12:39:53 pm
content: Quote from: Rufus on December 30, 2013, 03:49:11 pmI 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?

author: dannyf
author_rank: Super Contributor
timestamp: December 31, 2013, 01:06:07 pm
content: 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.QuoteIt was a 140MB download for me.

author: Rufus
author_rank: Super Contributor
timestamp: December 31, 2013, 03:57:06 pm
content: Quote from: amyk on December 31, 2013, 12:39:53 pmIt 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 26, 2014, 09:03:01 pm
content: ..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...Quotebut this would have been quicker to look up, and actually work.QuoteIf 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.

author: tszaboo
author_rank: Super Contributor
timestamp: January 27, 2014, 10:53:03 am
content: Quote from: mikeselectricstuff on January 26, 2014, 09:03:01 pmHappens 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.

author: notsob
author_rank: Frequent Contributor
timestamp: January 27, 2014, 12:34:39 pm
content: A very interesting comment from gerryhttp://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.

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2014, 09:51:34 pm
content: " 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 27, 2014, 10:07:15 pm
content: Quote from: notsob on January 27, 2014, 12:34:39 pmIf 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)

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2014, 10:28:47 pm
content: "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.

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2014, 10:35:19 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 27, 2014, 10:39:32 pm
content: 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.

author: Rufus
author_rank: Super Contributor
timestamp: January 28, 2014, 12:32:22 am
content: Quote from: mikeselectricstuff on January 27, 2014, 10:07:15 pmI 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 28, 2014, 01:14:04 am
content: I sense some anger management issues somewhere.

author: tszaboo
author_rank: Super Contributor
timestamp: January 28, 2014, 08:58:54 am
content: Quote from: dannyf on January 27, 2014, 09:51:34 pmI'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.

author: dannyf
author_rank: Super Contributor
timestamp: January 28, 2014, 11:41:22 am
content: You lost an easy opportunity to monetize your highly valuable and hugely in-demand skill.

author: Bassman59
author_rank: Super Contributor
timestamp: January 28, 2014, 08:15:09 pm
content: Quote from: dannyf on January 27, 2014, 10:28:47 pmThere 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

author: dannyf
author_rank: Super Contributor
timestamp: January 28, 2014, 10:55:22 pm
content: QuoteEven 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.

author: tszaboo
author_rank: Super Contributor
timestamp: January 28, 2014, 11:41:12 pm
content: Quote from: dannyf on January 28, 2014, 10:55:22 pmFeedback 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.

author: andersm
author_rank: Super Contributor
timestamp: January 28, 2014, 11:53:32 pm
content: Quote from: NANDBlog on January 28, 2014, 11:41:12 pmThey 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: January 29, 2014, 12:03:01 am
content: 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

author: dannyf
author_rank: Super Contributor
timestamp: January 29, 2014, 12:27:48 am
content: I am definitely interested.QuoteWhat does that mean? How did you do to lead you to conclude that the library was "completly missing"?QuoteMeaning?

author: Rufus
author_rank: Super Contributor
timestamp: January 29, 2014, 02:43:14 am
content: Quote from: AlfBaz on January 29, 2014, 12:03:01 amMy 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.

author: tszaboo
author_rank: Super Contributor
timestamp: January 29, 2014, 07:40:58 am
content: Quote from: dannyf on January 29, 2014, 12:27:48 amMeaning, 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.

author: poorchava
author_rank: Super Contributor
timestamp: January 29, 2014, 07:58:30 am
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 29, 2014, 11:04:54 am
content: I find the explaination ("the chip being faulty") not terribly believable in this case and there likely is something else at work.QuoteFirst 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 29, 2014, 11:07:06 am
content: QuoteThe 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 29, 2014, 11:10:49 am
content: QuoteOn 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.

author: tszaboo
author_rank: Super Contributor
timestamp: January 29, 2014, 12:37:11 pm
content: Quote from: dannyf on January 29, 2014, 11:04:54 amYou 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.aspx2nd 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 29, 2014, 01:06:36 pm
content: QuoteNot really, particularly the part that I don't think you understood the datasheet and how the adc modules work.QuoteI thought that's the purpose of a library.QuoteIt compiled perfectly for me.QuoteOK, 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.QuoteAny series is different from other series, by definition.

author: bxs
author_rank: Regular Contributor
timestamp: January 30, 2014, 06:34:49 pm
content: Quote from: mikeselectricstuff on January 26, 2014, 09:03:01 pmIn 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.

author: Harvs
author_rank: Super Contributor
timestamp: February 03, 2014, 12:14:10 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 03, 2014, 01:02:06 pm
content: 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.

author: Harvs
author_rank: Super Contributor
timestamp: February 04, 2014, 02:51:12 am
content: 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...