Not to stir things up...

This forum handles questions and discussions concerning MPLAB Harmony integrated firmware framework and all associated Libraries and components.

Not to stir things up...

Postby yubyub » Tue Aug 19, 2014 11:31 am

...but I'm wondering if my experience with Harmony and the Harmony versions of PLIB are what everyone else sees.

Recently, I needed to talk to an RTC via I2C. Something we've all done before, and will do again. Having recently adopted the PIC32MX platform and MPLABX, I decided to give the PLIB interfaces a try (the versions integrated into Harmony).

After spending about 4 hours tearing my hair out using the standard interfaces, yet seeing no transitions on SDA or SCL, I finally went directly to the registers. And within 20 minutes, *poof* - there was my data from the RTC.

The PLIB code I used was many version - examples from the Harmony documentation, examples from forums, examples from .ZIPs from Microchip. Very few of these compiled straight away, and none of them worked.

I've also used routines from the PLIB PORT library, which honestly are _extremely_ complex and offer very little in terms of abstraction or reduction of complexity, which I'd expect from an interface library.

The only useful routines I've found thus far are the USB and FS routines, which honestly seem to have some problems of their own (i.e. all functions return good error codes, so no problems, however opening a file for APPEND doesn't seem to always work, and dis-mounting a filesystem upon a USB device disconnect seems to fail consistently).

So, without meaning to stir too much up, is this a common experience?
yubyub
 
Posts: 10
Joined: Tue Jul 29, 2014 11:36 am
PIC experience: Professional 1+ years with MCHP products

Re: Not to stir things up...

Postby DavidBLit » Tue Aug 19, 2014 1:27 pm

Unfortunately, very. Where is Aussie Susan? The SPI Queen will give a resounding "Toldya so!" and she's absolutely right.

From what I've seen /all/ processor vendor software is highly suspect and should never be relied upon without a thorough line-by-line audit. Treat it as quick-hack demo-ware (until proven otherwise), spend your time in the Data Sheets, and you'll be all the better.
User avatar
DavidBLit
 
Posts: 14
Joined: Fri May 30, 2014 12:37 pm
Location: The Land of Confusion
PIC experience: Professional 5+ years with MCHP products

Re: Not to stir things up...

Postby yubyub » Tue Aug 19, 2014 2:19 pm

True enough about roll your own. For the lower PICs, I have my own library of sane implementations around things commonly used (UART, ADCs, SPI, yada yada).

But for larger things - such as USB and filesystems - re-implementation is non-trivial.

Has anyone thought about creating an open source version of these libraries? Something with a BSD style license?
yubyub
 
Posts: 10
Joined: Tue Jul 29, 2014 11:36 am
PIC experience: Professional 1+ years with MCHP products

Re: Not to stir things up...

Postby Olin Lathrop » Tue Aug 19, 2014 7:02 pm

yubyub wrote:...but I'm wondering if my experience with Harmony and the Harmony versions of PLIB are what everyone else sees.

Not me, since I haven't wanted to risk my code reliability and deal with all the integration issues around using Harmony. Since I've never used it, I haven't run into problems.

What you got should have been no surprise. Yes, I know Microchip tries to tell you to just drink the grape coolaid and all will be fine. However, anyone that's been in the real world for more than a few minutes should really know bettter.

Mircochip makes some great chips, but their example code pretty much sucks. At best it's a demo they can use to show off the capabilities of their hardware. It would be fine if they left it at that, but unfortunately they try to pretend it's more. The few times I've looked at their source code I've always thought "Yucc". Comments are sparse, formatting is all over the place (sloppiness one place invariably indicates sloppiness elsewhere), and the documentation seems to tell you what you need to know at first glance but once you get into the implementation you realize critical details are missing. Examples only show the easy obvious things, not the tricky things where the documentation leaves you wondering.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: Not to stir things up...

Postby Olin Lathrop » Tue Aug 19, 2014 7:22 pm

yubyub wrote:Has anyone thought about creating an open source version of these libraries? Something with a BSD style license?

I think that would run into the same problem Microchip did. Very few people are capable of writing really good code, especially general purpose code that has to work together with other library elements and the customer's specific part of the project. Add to that that you can't afford a lot of runtime layers to provide high level abstractions, and the problem becomes quite difficult.

I do make most of my subsystem parts (they aren't a library and shouldn't be called that) available via free download (http://www.embedinc.com/pic/dload.htm). I rely heavily on build-time customization instead of trying to create lots of runtime layers of abstraction. In a small embedded system it doesn't make sense for the runtime code to carry the burden of configuration options that you know the particular project will never use.

While I've used my generic subsystem pieces in many PIC projects, it's probably difficult for others to do this without embracing my overall PIC development system. Various pieces assume the existance of other pieces. For example, most of the more complicated susbystems, like the USB device code and the network stack, require that my multi-tasking system be used. That's just another subsystem that's easy to add, but that's just one example.

You said you're using a PIC32. I haven't been on one of those yet, so none of my code would be useful to you anyway.

I think it is possible to create a bunch of common subsystems that are carefully designed with sensible interfaces and good documentation. However, I think Microchip is under the illusion they already have that, and worse, that they know how to do this, so this is unlikely to ever get fixed. It takes experience with lots of real world PIC projects that had to do real things for real customers to know how to do this right. Those whos experience is limited to writing one-off demos to show off the company's hardware products need not apply.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: Not to stir things up...

Postby yubyub » Tue Aug 19, 2014 7:42 pm

Olin,

I like the cut of your gib. Specifically, build time customization as opposed to huge amounts of meaningless abstraction and runtime configuration. Indeed, this is they way I cut my code on the PIC 16 and 18's I'm so very used to. A few well placed, well structured #defines along with some straight-to-the-point code keeps things small, efficient, and easy to debug and re-use.

I guess I didn't expect Harmony to be fantastic, but I at least was hoping that there was some logic in its' design. For instance, I don't see a good vision of the design at all - it's as if whomever engineered it had one vision of what the framework might be, then another, then another, and finally one more - and coded all of them into Harmony. As far as any framework goes - light or heavy - it fails to be either consistent or direct. In fact, it fails in so many ways, it's disappointing. Microchip has some really great hardware, and their software is just incredibly lacking. I guess I only saw it when I moved to PIC32s - I've never even considered looking at PLIB or Harmony on the 18 or 16 series, as coding directly to the registers is just so simple and efficient.

So, I'm not surprised. I'm just disappointed.

I'm going to check out that link, just to see what's there. The PIC32s are new and rather "exciting" (wow, >4K of RAM? Jeez, I feel like computing prime numbers and storing them, just because I can), but I still have a lot of stuff on the 18s - they run a ton of my products, and do a great job at it.

Thanks for your comments.
yubyub
 
Posts: 10
Joined: Tue Jul 29, 2014 11:36 am
PIC experience: Professional 1+ years with MCHP products

Re: Not to stir things up...

Postby AussieSusan » Wed Aug 20, 2014 3:47 am

DavidBLit wrote:Where is Aussie Susan? The SPI Queen will give a resounding "Toldya so!" and she's absolutely right.

Right here actually....but I only get on this forum during my lunch times (sad, I know) and I've only just seen this topic.
David, just for you......

Toldya so!

Susan :roll:
AussieSusan
Verified identity
 
Posts: 173
Joined: Mon Jun 16, 2014 4:45 am
PIC experience: Experienced Hobbyist

Re: Not to stir things up...

Postby DavidBLit » Wed Aug 20, 2014 1:51 pm

:lol: 8-)
User avatar
DavidBLit
 
Posts: 14
Joined: Fri May 30, 2014 12:37 pm
Location: The Land of Confusion
PIC experience: Professional 5+ years with MCHP products

Re: Not to stir things up...

Postby JoshuaHartwig » Wed Aug 20, 2014 2:28 pm

There's also been some quirky problems when using MLA/Harmony due to the way MPLab X and the XC compilers deal with absolute paths. All sorts of people have trouble copying, moving, or sometimes even packaging projects for sharing that use those tools.
JoshuaHartwig
 
Posts: 9
Joined: Thu May 29, 2014 10:40 pm
PIC experience: Professional 1+ years with MCHP products


Return to MPLAB Harmony

Who is online

Users browsing this forum: No registered users and 4 guests