PIC18FxxQ43 , XC8 , ( Curiosity Nano )

[granddad]

Just sharing a bug I found in the MC XC8 2.32. also 2.40 .
Symptoms .. PIC18F57Q43 code complied but with many errors and warnings . check the #include <xc.h> line. [ The PORTE didn't work ]
Fix.. the plib file was missing from the XC8 directory, I took a guess and copied and renamed the lib file into the 2.40 include directory as plib . Code compiles now without the ‘red weed ‘of errors. ( fix is right picture ) .
( I'm running linux.mint 20 . MPLABX 6.0)

.

 

[Nigel Goodwin]

Wasn't the plib library discontinued a VERY long time ago, so hasn't been supplied with XC8 for a good few years.

So it's not a 'bug' it's working exactly as intended, which isn't to compile ancient code

Here's the faq

MPLAB® XC32 Compiling Error - Cannot Find plib.h - Developer Help

microchipdeveloper.com

 

[granddad]

Tell MC that ... there is something amiss xc.h is looking for plib. As i posted lots of warnings and errors an PIC not working, although it complied, till I changed the file ...

 

[Pommie]

Seems there's a conversation about XC8 and XC32.

Mike.

 

[Ian Rogers]

Tell MC that ... there is something amiss xc.h is looking for plib. As i posted lots of warnings and errors an PIC not working, although it complied, till I changed the file ...
View attachment 138828

It will only look for the PLIB if your code references it.. When you "install" the PLIB, the XCx.H is updated.

I do not suffer these issues as I write my own libraries.. I'm sorry I cannot shed more light as I haven't the need for the Q series as yet. Still phaffing with the K and J at the mo..

 

[granddad]

It will only look for the PLIB if your code references it

From my investigations #include <xc.h> eventually references plib (dir) , as it has the pic18f57q43 .inc and .h files. and a hundred others !
Just to repeat the code compiled even with all the red errors,and didnt go away ( porte didnt work ) untill i moved and renamed the lib to( could have been proc i hacked not lib ) ( I copied the directory as it had the inc and h files ) xc was complaining about .

The Q series is well stuffed with devices , the curiosity nano has a 48 pin PIC , I seem to be using them all !

 

[Nigel Goodwin]

What code are you trying to compile?, can you post it?.

 

[granddad]

What code are you trying to compile?, can you post it?.

Not trying ? My code (C) compiles fine now , since I fixed xc.h looking for the PIC18F57Q43.inc . ( see the warning against the #include <xc.h> line . post 3

 

[Nigel Goodwin]

Not trying ? My code (C) compiles fine now , since I fixed xc.h looking for the PIC18F57Q43.inc . ( see the warning against the #include <xc.h> line . post 3

You're rather missing the point, I wanted to see if you're using plib functions in your code?.

 

[granddad]

This was a new project with the Q series, so i was checking the config and mainly the clocking possibilities, so the code only had #include <xc.h> and was just a few lines getting the reference clock to output on PORTE ( Should have but failed ).. Originally there was no plib directory under the v2.40/pic/include/ directory. the v2.40/pic/lib directory has or HAD 100s of PIC device .h and .inc files , and as xc.h was eventually looking for v2.40/pic/include/plib directory , I gave it one ...so yes my code did need a pic18f57q43.inc (.h) within a plib directory. Should say i have since found out I'm not the only person who hit this bug..

 

[granddad]

further .. far as i can tell plib should not be part of the xc2.40 file structure . but my project would not 'function' until i added it !
still investigating .....
edit, I removed the plib i created all the red errors and warnings came back ...

Conclusion .. project builds no errors with my plib directory. think i am chasing stuff way beyond my skills.

 

[tumbleweed]

the v2.40/pic/lib directory has or HAD 100s of PIC device .h and .inc files
...
I took a guess and copied and renamed the lib file into the 2.40 include directory as plib . Code compiles now without the ‘red weed ‘of errors. ( fix is right picture )

Just fyi -
On my installation, there are no .h or .inc device files under v2.40/pic/lib.
All the device files are located under the pic/include/proc folder

 

[tumbleweed]

... and don't confuse the red-squigglies in the brain-dead MPLABX IDE with actual problems.
The only sure-fire way to know if you have a problem is to compile it and see if the compiler barfs.
If it compiles you're good to go.

This is purely an IDE issue that mchip don't seem to be able to fix. Better men have tried and failed. You'll be changing your moniker to 'great granddad' before this is (possibly) ever resolved.

 

[granddad]

Just fyi -

Thanks, I had and have the same v2.40 .... pic/include/proc and yes it did hold 3400 inc and h files, but xc.h wasn't accessing them them , without my plib ??

 

[Ian Rogers]

It seems like the compiler, when updated, has included the previous version . Which is weird as the new versions are in separate directories.

 

[Ian Rogers]

One thing I will say... MPLABX isn't the best tool out there... I really cant stand all the little digs and "non" conformity issues it has.. I get sooo many warnings which are trivial.. It would appear that they don't really coexist with the compilers very well atall..

If you have seen some of my issues, I normally use Proteus VSM ide for my compilation, and I get minimal warnings.. The same code in MPLABX is phenomenal.. even if I set warnings to minimal.

This tells me that its not always the XC8 compiler.. The linker is the one that needs to find object code and it gets its information from the IDE..

 

[granddad]

Over the years I too have got used to the warning errors etc, i can see why people stick with old versions of MC sw . But having got a Q pic that would not play until i had latest updates. then my paper chase started. Its difficult to know if its is something ' you ' did or just one of MC's many bugs . The Curiosity nano is working fine now , ( other than the green led not solid after a build ) , I even sorted the complex interrupt code . maybe .. with X its a bit like that 24/7. I am only playing with a PIC and Z80 hybrid . as Z80 was my first dip of my toe in the techie water back in the 70's.

 

[Pommie]

MPLABX V6.0 is the buggiest piece of software I have ever had the (unpleasant) experience to use. Absolute piece of garbage and not fit for purpose. You definitely get what you pay for.

Mike.
Edit, actually any version.

 

[Ian Rogers]

When I ran into issues two months back.. Proteus was giving me and issue.. Ran the compiler on MPLABX and it ran nice I thought Proteus was faulty.... no nO NO The problem was my code.. On proteus it didn't work in sim OR real... MPLAB compiled the code and it ran on hardware, but the issue was still there but masked.
I had two buffer underrun issues, So... I couldn't understand why one IDE ran it and one didn't..

 

[granddad]

I had not realized how crucial the #include <xc.h> was , back in the day i would #include <p16Fxxxx> for instance , pick the wrong device .inc and it didn't compile .. so where does xc.h get its device info from , must be the IDE config .. but with my project, xc.h failing to locate the .inc file X still complied and ran allbeit 'not ran '..Seems its an X IDE mac and linux thing MC have had a support ticket for 2 years.