chipKIT® Development Platform

Inspired by Arduino™

Chipkit's Libraries compatibility with plib.h

Created Thu, 13 Feb 2014 03:27:42 +0000 by hdphilip

hdphilip

Thu, 13 Feb 2014 03:27:42 +0000

Here the problem i'm having, when I add #include <plib.h> to most examples, a couple of pages of errors will result. Has anyone else ran into this problem? I'm using mpide 20140121

This works fine

#include <DSPI.h> [color=#007F00]//#include <plib.h>[/color] [color=#FF0000]void[/color] [color=#FF8000]setup/color {} [color=#FF0000]void[/color] [color=#FF8000]loop/color {}

massive errors

#include <DSPI.h> #include <plib.h> [color=#FF0000]void[/color] [color=#FF8000]setup/color {} [color=#FF0000]void[/color] [color=#FF8000]loop/color {}

This works fine

#include <[color=#FF0000]SD[/color].h> [color=#007F00]//#include <plib.h>[/color] [color=#FF0000]void[/color] [color=#FF8000]setup/color {} [color=#FF0000]void[/color] [color=#FF8000]loop/color {}

massive errors

#include <[color=#FF0000]SD[/color].h> #include <plib.h> [color=#FF0000]void[/color] [color=#FF8000]setup/color {} [color=#FF0000]void[/color] [color=#FF8000]loop/color {}

This work fine

#include <plib.h> #include <[color=#FF0000]LiquidCrystal[/color].h> [color=#FF0000]LiquidCrystal[/color] lcd(12, 11, 5, 4, 3, 2); [color=#FF0000]void[/color] [color=#FF8000]setup/color {} [color=#FF0000]void[/color] [color=#FF8000]loop/color {}

also the LCD5110 works fine, most all of the networking have trouble. so far none of the tft displays will work. maybe someone else could try my examples.

Thanks

Philip

Jacob Christ

Thu, 13 Feb 2014 07:44:35 +0000

This is an aside, but why are you including plib?

Jacob

hdphilip

Thu, 13 Feb 2014 13:46:22 +0000

hi Jacob,

I like to use the macros for the timers, interrupts, I/O.

Philip

Ian_B

Fri, 14 Feb 2014 18:49:08 +0000

Hi Philip,

I've used plib.h a bit in MPIDE, mainly for the same functions as you, along with some more direct register manipulation. I always included plib.h before any other libraries, and it works fine. I never tried putting it after the other libraries, but now that I do I see the same problem you described. I'd suggest always including it at the very beginning of your code

Here's something that compiles fine for me:

#include &lt;plib.h&gt;

#include &lt;WiFiShieldOrPmodWiFi_G.h&gt;
#include &lt;DNETcK.h&gt;
#include &lt;DWIFIcK.h&gt;
#include &lt;SD.h&gt;

majenko

Fri, 14 Feb 2014 23:11:14 +0000

Basically the problem here is a conflict between usages of a word.

For some strange reason Microchip decided they should define their own types for common variable types. One of which is the variable type BYTE:

typedef unsigned char           BYTE;                           /* 8-bit unsigned  */

Now, what's wrong with "unsigned char", or "uint8_t" I have no idea. I really hate it when people create completely pointless typedefs and give them stupid names like that. "byte_t", yes, that would be fine, but not "BYTE".

In the Arduino world BYTE is a #define macro equating to 0. It is used for print() and maybe a few other situations, to tell it you're working with byte data.

So, the upshot is, what you end up with is

typedef unsigned char           0;                           /* 8-bit unsigned  */

after the preprocessor has run. That's obviously not going to work at all.

There may be other similar instances throughout the system as well...

So no, you're not going to get plib.h and the chipKIT system to work together at all. Not without re-writing one or the other.

You'd be much better off writing a library to provide the functionality you want, and then maybe sharing it with the rest of us.

hdphilip

Sat, 15 Feb 2014 01:54:39 +0000

Thanks Ian and Majenko,

The example did compile fine, i didn't realize the importance of the order of "#include"

to Majenkjo's point, on libraries, i might have to "de" library a library, make the functions work, and then perhaps put it back together in a modified library. I've done this in the past. A lot of times I'll put the .h and the .cpp in the sketch folder to make changes to a library.

here's what i'm playing with right now, it's a 8x8 grid-eye IR sensor, also on board is a color sensor, light sensor, humidly sensor, pressure sensor, temp sensor.

I think sometimes seeing the results from programming is the best teacher

[attachment=0]P1010093.JPG[/attachment]

The flash of the camera didn't have much effect on the IR picture... how cool.... but it did on the color sensor. Philip

edit

#include <plib.h> #include <[color=#FF8000]Wire[/color].h> #include <TMP102.h> #include <ChipKit_BMP085.h> #include <DSPI.h> #include <GFX.h> #include <[color=#0066FF]ST7735[/color].h> [color=#007F00]//#include <ST7735B.h>[/color]    [color=#007F00]// #include <p32xxxx.h> /* this gives all the CPU/hardware definitions */[/color]    [color=#007F00]// #include <plib.h> [/color] [color=#007F00]//#include <Math.h>[/color]

this also compiles......yahooo!!

Jacob Christ

Sat, 15 Feb 2014 14:53:42 +0000

So the other day I found this amazing project that I'm kicking myself for not noticing before and am dumb founded that its not more active called demitasse that is a port of TeaCup from Arduino. The project was created 3 years ago!

So the point of tacking this on this thread is that it appears to make heavy use of plib.h and when I try to compile I simply get these errors:

C:/Users/jacob/Desktop/mpide-0023-windows-20130715/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: MPIDE Version not specfied correctly
C:/Users/jacob/Desktop/mpide-0023-windows-20130715/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: MPIDE Version not specfied correctly
collect2: ld returned 1 exit status

I tried to make plib.h the first include in the demitasse.pde file but no such luck and I'm trying to hunt down the cause right now.

Jacob

Jacob Christ

Sat, 15 Feb 2014 16:18:31 +0000

I've narrowed down the issue. Demitasse uses main() and not setup() and loop().

So this code compiles without error:

#include &lt;plib.h&gt;

void setup() {                
}

void loop() {
}

And this code does compiles with the link error mentioned above:

#include &lt;plib.h&gt;

int main(void)
{
  return 0;
}

error:

C:/Users/jacob/Desktop/mpide-0023-windows-20130715/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: MPIDE Version not specfied correctly
C:/Users/jacob/Desktop/mpide-0023-windows-20130715/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: MPIDE Version not specfied correctly
collect2: ld returned 1 exit status

EDIT: I tried both with UECIDE and neither work...

Jacob Christ

Sun, 16 Feb 2014 03:30:31 +0000

As an added note, demitasse compiles under MPIDE 20120903

majenko

Sun, 16 Feb 2014 15:51:24 +0000

When you use your own main (at least, in UECIDE), the optimizations seem to knock out a whole lot of the core that is no longer used. One of the things that it seems to knock out is the .mpide_version definition variable (it's at the top of wiring.c). As a result things just don't compile.

I still don't understand why we have that in there, what it's for, and why not specifying it should be a fatal error like it is...

Still, adding

extern const uint32_t __attribute__((section(".mpide_version"))) _verMPIDE_Stub = MPIDEVER;

at the top of your sketch fixes that.

It doesn't fix the fact that plib.h and the Arduino-esque API are incompatible with each other, and always will be until one or the other gets re-written. The Arduino API can't be changed, as that would break compatibility. Plib can't be changed as that's owned by Microchip, and they ain't gonna change nuffink for the likes of us ;)

So, the simple answer is: don't use plib.h

There is no reason to use plib.h - it doesn't provide anything you can't do yourself with a little direct register manipulation. I myself have never used plib.h in the whole history of using PICs, and I've been doing that for a while now.

Jacob Christ

Sun, 16 Feb 2014 19:59:04 +0000

It doesn't fix the fact that plib.h and the Arduino-esque API are incompatible with each other, and always will be until one or the other gets re-written. The Arduino API can't be changed, as that would break compatibility. Plib can't be changed as that's owned by Microchip, and they ain't gonna change nuffink for the likes of us ;) So, the simple answer is: don't use plib.h

Okay, I guess I am kind of slow. This is what I thought you were implying in a previous post but now that you hit me over the head I can see the light.

There is no reason to use plib.h - it doesn't provide anything you can't do yourself with a little direct register manipulation. I myself have never used plib.h in the whole history of using PICs, and I've been doing that for a while now.

Well, if you just want to get a project up and running fast that was written using plib.h then this is a reason. Otherwise I'm with you. I've been using PIC's forever (probably over 20 years now) and have had nothing but frustration whenever I tried to use any application code provided by Microchip.

So short term use an older version of MPIDE to compile demitasse and long term eradicate plib.h. I would even go a step further and try to abstract out any specific processor requirements so that code is cross chip compatible.

Jacob

hdphilip

Thu, 20 Feb 2014 04:11:39 +0000

I don't think getting rid of the Plib.h would be such a good idea, The Plib.h library give some of us less experienced programmers a chance to try out some of the hardware functions of the Pic32 chip with out the transition to MPLAB. and if we do make the transition, we have some tools ready to go.

Philip