C18 - unable to locate 'p18cxxx.h'

[futz]

Decided to try out C18 tonight and I've run into a little problem. I get

Error [1027] unable to locate 'p18cxxx.h'

every time I try to compile.

I googled for it a bit and everyone says the same thing, "Just point your include search path to c:\mcc18\h. Well, I'd already done that and it gives the error anyway. Yes, it is the correct path to the h directory.

EDIT: Got it. Apparently you can't change it from Project/Set Language Tool Locations. You have to use Project/Build Options instead. Weird!

 

[futz]

I hit the limit for the demo so I bought a BoostC Full license today. Then instead of continuing with my coding, I installed C18 and started testing it out. So far I like BoostC better, but it will take a lot more use before I really know for sure. Anyway, I can afford BoostC and I cannot afford C18, so that settles that.

 

[blueroomelectronics]

Aside from the optimizations being turned off for the SE version what was wrong with C18?

 

[futz]

Aside from the optimizations being turned off for the SE version what was wrong with C18?

Nothin wrong with it. But if I had to choose between a $500 18F-only compiler and a $75 compiler that works just as well, and includes a 16F and an 18F compiler... It's a no brainer. I bought BoostC. That isn't going to stop me from getting comfy with C18 as well.

I don't like C18's delays.h lib at all, but there's nothing stopping me from writing my own that's easy to use like BoostC's. C18's is probably better for some things. It's likely much more accurate.

BoostC's way of accessing bits is much simpler and takes much less typing than C18's way. There may be shortcuts that I don't yet know about, though. Could probably build some macros that fix it.

 

[3v0]

People should use whatever compiler they are comfortable with (use and pocket). I have not used BoostC but am impressed by the low cost of the non-professional offering.

BoostC does not support unions which forces them to use another method to describe register bits. The nice thing about unions is that they allow you multiple descriptions/names for the same set of bits.

In C18 you see TRISAbits.TRISA0 which is awkward. If you do not like that you can amend the .h file so you could write TRISAbits.b0. The C18 method makes more sense when you use registers where bits or groups of bits have names related to function. It does a lot to make setup code readable.

Including 'p18cxxx.h' picks the .h file based on what processor you are using. Some people feel it is better to specify the processor directly to prevent the compilation of the project for the wrong processor. Try including the specific processor header file, p18F2550.h or such.

 

[Pommie]

Including 'p18cxxx.h' picks the .h file based on what processor you are using. Some people feel it is better to specify the processor directly to prevent the compilation of the project for the wrong processor. Try including the specific processor header file, p18F2550.h or such.

This is really important when people post code on here. If they use 'p18xxx.h' then we have no idea which processor they are using and can't advise that the pins may be analogue or they didn't turn off comparators etc.

I also shy away from typing shortcuts as they invariably lead to bugs. I find 2 seconds typing a longer variable name now saves me 3 hours(+) trying to debug it 3 months later.

[tangent] Does the free C18 compiler without optimisation produce bigger code than BoostC with it?[/tangent]

Mike.

 

[blueroomelectronics]

Well since I'm at the C learning stage I can't realistically make a informed opinion on C18, vs boost C, microC, Hitech C, CCS C etc.
That said I have to pick one (feels like choosing your religion)
I'm sticking with C18 for the moment as

1. I've got it
2. the free SE edition has no limits aside from optimization disable
3. official Microchip 18F compiler
4. Microchips 18F libraries are for C18 eg the TCP/IP stack

PS I don't mind the "bits" part of C18.

 

[3v0]

[tangent] Does the free C18 compiler without optimisation produce bigger code than BoostC with it?[/tangent]

Maybe Futz can look at that. The only other PIC compiler I use is the CCS PCM (midrange).

 

[3v0]

PS I don't mind the "bits" part of C18.

I think the bits part of C18 is actualy better then the variable.bitNum system.

It allows the naming and grouping of bits by function.

Thiis machine does not have a compiler installed so the names I am using may be wrong. Often timers use 3 bits to setup the prescaler. Lets say the control reg is TMR0CON and the prescaler bits are 3,4,and 5.
Intstead of
TMR0CON.3 =1;
TMR0CON.4 =0;
TMR0CON.5 =1;

You could write the union such that you could use
TMROCONbits.prescale = 0x5;

 

[Pommie]

I think the bits part of C18 is actualy better then the variable.bitNum system.

It allows the naming and grouping of bits by function.

Thiis machine does not have a compiler installed so the names I am using may be wrong. Often timers use 3 bits to setup the prescaler. Lets say the control reg is TMR0CON and the prescaler bits are 3,4,and 5.
Intstead of
TMR0CON.3 =1;
TMR0CON.4 =0;
TMR0CON.5 =1;

You could write the union such that you could use
TMROCONbits.prescale = 0x5;

Yes, that would be nice. Unfortunately they didn't bother. I keep thinking of rewriting their .h files.

Mike.

 

[BeeBop]

People should use whatever compiler they are comfortable with (use and pocket). I have not used BoostC but am impressed by the low cost of the non-professional offering.

BoostC does not support unions which forces them to use another method to describe register bits. The nice thing about unions is that they allow you multiple descriptions/names for the same set of bits.

Yes, you have not used it, and are not familiar with it, so why do you feel you must assert this?
From the boost manual:

Support for Data Structures and Unions - Data structures and arrays can be comprised of base data types or other data structures. Arrays of base
data types or data structures can be created.

and

• Single bit - single bit data type for efficient flag storage.
• Fixed address - fixed address data types allow easy access to target device registers.

The compilers all have their quirks and quarks, and sometimes one will work for a particular app, much better than another will. I think, though, the price must figure into the equation if you plan to purchase.

Boost was a great deal, as is CCS (especially if you go the PHAnderson route, and write your own libraries.) The only one which does not feel good to me is mikro - no MPLab integration, absolutely no access to their library source, ....

 

[3v0]

Yes, you have not used it, and are not familiar with it, so why do you feel you must assert this?

Because it says so on their web site!

Futz's statement regarding "accessing bits" caught my attention. I was checking out the boostC website. On the products page I clicked on a link that compared their compiler with another. The comparison clearly showed that they did not support unions or structures!

The comparisons on the boostC product page are based on their old C2C-plus compiler. The comparison links are clearly marked as C2C-plus and had I been paying attention I would have noticed. Should have noticed it was out of date.

It was a honest mistake. I did not badmouth the product.

 

[BeeBop]

Because it says so on their web site!

Futz's statement regarding "accessing bits" caught my attention. I was checking out the boostC website. On the products page I clicked on a link that compared their compiler with another. The comparison clearly showed that they did not support unions or structures!

The comparisons on the boostC product page are based on their old C2C-plus compiler. The comparison links are clearly marked as C2C-plus and had I been paying attention I would have noticed. Should have noticed it was out of date.

It was a honest mistake. I did not badmouth the product.

Ah, I get it, and think those boys ought to update the website!

 

[3v0]

Ah, I get it, and think those boys ought to update the website!

Yes but it was my mistake! Thanks for understanding.