So, way back when I first settled on the PIC32, I knew I needed compiler support for the MIPS architecture. Let alone, it's building a cross compiler which is usually not an easy feat. My purpose with D-DAQ is to give back to the/a community and make sure there is something they can use unencumbered. Right now, thats not completely possible. If I used ARM I wouldn't be having this problem now, but at the same time I don't see a need to change.

Edit: Sorry about the atrocious grammar

First off, I want to give some more light to a controversy that isn't well publicized. Microchip's primary compiler for the PIC32 is XC32; previously it was known as C32 but there were code changes  etc etc which lead to a name change but they're functionally the same and I'll use 'XC32' to refer to both. Like any 'decent' piece of commercial software, there are licenses available for purchase for the functionality of which you choose to use in the product. The controversy that exists though is that if you don't have a license, XC32 will disable/remove GCC's own standard optimizations i.e. -O -O1 -O2 -O3 -Os. Even if you don't explicitly define the levels, most of the individual flags are disabled by the function that currently resides at gcc/gcc/config/pic32/mchp.c:1081 in version 1.31 of the XC32 sources. 

mchp_override_options_after_change

Frankly, this is a bit irksome; being charged for something that is normally free. I'm not the first person to bring this up either. I've known about it for a couple years because some searching yielded a blog post from back in 2009 when it was just the C32 compiler.  About 2 years later it was noted again for the XC32 compiler. It was also briefly discussed on the EEVBlog Forums. Oh, and toss in a final thread on Microchip's forum. However, this is half of my point.

I want people to be able to code for D-DAQ. That cannot happen without proper PIC32 support. ARM is much more prolific because it's toolchain is not encumbered like the PIC32's. If I were looking at just doing some small projects off of a 'beefy' MCU/uC then I'd have no problem with using MPIDE or UECIDE to develop my code on. The problem, though, is that before I can code, or more properly while I code, for D-DAQ I have to make the libraries themselves for complete peripheral support. Why? I'm using both I2C busses, the PMP bus, 3 of the 4 SPI busses, 14 ADC channels, 2 Input capture pins, and even DMA to attempt make this little PIC32 do what I want. The Arduino compatible libraries in the other IDE's do no have support for even half of these peripherals (excluding the ADC).

If I had the time and help, I'd get started on developing proper libraries for the PIC32 for MPIDE and UECIDE. But I have neither the time or help currently unless I pull out of the HaD Prize competition. Frankly if I drop out of the competition, it's unlikely that I'll complete D-DAQ.

What I've decided to do is this: Due to the time constraints, is to develop with MPLAB X. After all I get 60 days of the 'Pro' license. Following the completion of the contest and regardless of outcome, I know I have a helping hand or two who can assist me greatly. From there I look to porting or developing libraries for utilizing all of the PIC32MX's peripherals to more open environments. Microchip already has no problem releasing unencumbered variants of their compiler, look at chipKit, but there just needs to be proper support to keep it up to date.

Footnote: For the apt, it's trivial to bypass the license restrictions. I'm not touching this topic here because that's not within the scope of D-DAQ and I'm not proficient enough in law or ethics to provide advice or recommendations as to the course of action that should be taken. At the same time, I highly encourage this topic to be discussed and documented to free up potential hardware for embedded use. FYI, If we were charged for the optimized libraries instead of generic ones, then I'd have little issue here.