Program works under UECIDE but not MPIDE

Created Fri, 19 Sep 2014 03:52:28 +0000 by w5uxh

w5uxh

Fri, 19 Sep 2014 03:52:28 +0000

I am sending a program developed with UECIDE to a friend and wanted to make sure it is compatible with MPIDE, just in case he wants to start with that IDE.

The program compiles, and MPIDE reports "Done uploading" with no signs of problems, but the Max32 program does not run when compiled and uploaded with MPIDE, but runs fine under UECIDE.

I will investigate tomorrow, blindly trying things, but I wanted to ask, just on the slight chance: is anyone aware of something simple and dumb that could be IDE dependent with this symptom of not running in one of the two IDEs?

The program uses a typical 4x20 LCD. I have a simple test program that only tests the LCD interface and verified it still runs under MPIDE, so tomorrow I will try to tear apart the larger program (10 source files plus a Timer library) and hopefully will stumble across something.

I hope my friend will go directly to UECIDE, I have strongly encouraged it, but since he has used Arduino, he may want to start with a more familiar environment. And it just seems like I should not accept the situation unless there is a very good reason.

majenko

Fri, 19 Sep 2014 09:12:35 +0000

It could be the fault of the compiler. Which version of MPIDE are you working with?

w5uxh

Fri, 19 Sep 2014 12:54:15 +0000

Thanks for the hint. The dmg file was mpide-0023-macosx-20140316.dmg. Your question of course led me to look for a newer version so I found and downloaded mpide-0023-macosx-20140821.dmg.

This one at least led me to an error in the .cpp file that the IDE generated from the .ino file. Then a google search led me to a forum post where I learned about holding down the shift key to find the .cpp file and determine the offending line was this:

#include <string>

producing a "no such file" failure

I found this #include does not seem to be needed when compiling under UECIDE. BUT, my next compile led me to the next offending #include under MPIDE:

#include <queue>

This one is apparently needed under UECIDE. Both of these were things I had used based on examples found on the web when I was getting started.

Summary: I have more information now, but have not been able to get beyond the queue problem so far this morning. I have to leave now for a few hours, and will keep at it when I return.

(The new MPIDE version seems to be about 10 times larger than the older one???).

I certainly am happy that you provided UECIDE. It is so much nicer to use.

majenko

Fri, 19 Sep 2014 14:58:49 +0000

The latest version of MPIDE contains support for the MZ chips. Because of that the compiler is massive compared to the older versions. I think it also uses a different c library which may not have things like stream and queue in it. You should try with the last of the smaller versions of MPIDE.

UECIDE is still using that older version as its default. The newer version is available as chipKIT-Git and pic32-tools-MZ. I will be keeping the older version even when the new version becomes the default - probably as chipKIT-Legacy.

w5uxh

Fri, 19 Sep 2014 18:13:41 +0000

You should try with the last of the smaller versions of MPIDE.

The mpide-0023-macosx-20140316 version I had used originally was a smaller one, and it apparently did not like queue, which was one of my original problems.

I think it also uses a different c library which may not have things like stream and queue in it.

I take it this would mean the queue class would not be available in a newer UECIDE? Is there replacement class that one would normally migrate to? Or should I use my own? I am pretty sure I wrote one for a MBED project a few years ago, so I should be able to pull it in. I will look into doing this since I would prefer to not freeze with older versions this early in my "ChipKit life".

majenko

Fri, 19 Sep 2014 20:08:03 +0000

I'd go the roll your own route. Lose the crutch and embrace the linked list ;)

I can conform that there is no queue or vector in the MZ compiler's C++ library, but there is in the older MX-only version.

It seems that we're one of the few that doesn't have queue and vector now - seems like a step backwards to me...

matt@dell:~/.uecide/compilers$ find -name queue
./arm-sam-gcc/arm-none-eabi/include/c++/4.4.1/queue
./arm-eabi-lm4f/arm-none-eabi/include/c++/4.7.1/queue
./arm-maple-gcc/arm-none-eabi/include/c++/4.4.1/queue
./mips-openwrt-linux-uclibc/mips-openwrt-linux-uclibc/include/c++/4.8.3/queue
./pic32-tools/pic32mx/include/c++/4.5.1/queue
./gcc-linaro-arm-linux-gnueabihf-raspbian/arm-linux-gnueabihf/include/c++/4.8.3/queue

w5uxh

Fri, 19 Sep 2014 21:07:25 +0000

Ok, thanks. I am trying to port my old one now. It was my very first attempt at writing a class, and I have never done much more than that since with C++. OOP has always been black magic to me, but I can at least appreciate many of the features I have been exposed to in the past few years.