Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Just started with MPLAB XC and am having problems with __delay

Status
Not open for further replies.

si2030

Member
Hi there,

OK I have just downloaded MPLAB XC and have loaded a couple of examples I have found (for this version) and in all cases I get an error on

__delay_us(....);

It says "Unable to resolve identifier".

I built it and it built.

I checked in this project in properties and then compiler to see if Define Macros had:

_XTAL_FREQ=20000000

and it does.

It is probably a global setting I dont know about however I have included both a screen dump and the zip of the program.

Kind Regards

Simon
 

Attachments

  • Screen showing error.jpg
    Screen showing error.jpg
    493.5 KB · Views: 505
  • LCDTest.X.zip
    94.8 KB · Views: 218
"Unable to resolve identifier" is a linker error. Linker is a program that takes all the compiled pieces of code and "mashes" it into one single piece of code that includes all the needed functions etc. It needs to resolve all function calls so that they work properly and that all functions are placed correctly in memory so that they can be called correctly. The problem you are having is that the linker can not find the __delay_us() function anywhere. I have not used MPLAB XC, but there must be a setting somewhere (Linker Files.. maybe) that you can include the correct library to the project so that the linker can find it.
 
Last edited:
Sooo... I found that if I actually included #define __delay_ms(x) and/or #define __delay_us(x) depending on which one or both I am using it ceases giving an error... finickity? one wonders why this isnt an automatic thing as pic.h should automatically be used by the parser....
 
Sooo... I found that if I actually included #define __delay_ms(x) and/or #define __delay_us(x) depending on which one or both I am using it ceases giving an error... finickity? one wonders why this isnt an automatic thing as pic.h should automatically be used by the parser....

I'm not sure what you did to get rid of the error.. Did you define the __delay_ms(x) macro yourself by adding this line to your code:
#define __delay_ms(x)

If you did that, then you re-defined the macro to do nothing. It gets rid of the error, but you are only replacing the original delay call with "nothing".
 
You need to include the macro

_XTAL_FREQ=20000000

In the LCD C file OR before you define it in your main file.. either way before you call a delay function.... BTW I don't think you can use a float in the delay arguments..
 
Hi misterT,

If I understand correctly, by defining this line I have got rid of the parse error but the program wont run.... so is this something I will have to put up with? Its unnerving to see red underline in your program and know that is still works... can anything be done to correct this?

Simon
 
BTW I don't think you can use a float in the delay arguments..

True.. maybe. If the delay is a macro that builds some optimized asm-loop, then the float may work. Like, if the macro translates to " 0.5*100 ", then pre-processor will compute the correct value "50". I have no idea how the delay is defined in the library OP is using.
 
Ian,

should that be an #include or a #define? it errors with #include and says it cant find the include if I change it. I have changed it back to #define. I tried to move it right to the top and then the bottom of the includes and it still shows a parse error. Is this something I am having to live with?
 
Hi misterT,

If I understand correctly, by defining this line I have got rid of the parse error but the program wont run.... so is this something I will have to put up with? Its unnerving to see red underline in your program and know that is still works... can anything be done to correct this?

Simon

The program will run, but the delay will not work because you replaced the original __delay_ms(x) with empty definition. (If you did write the line "#define __delay_ms(x)")
 
You need to include the correct library when you are using functions that are part of the library that comes with the compiler or Integrated Development Environment (IDE) (MPLAB XC).
 
Hi misterT,

Yes I understand that the correct library needs to be included. However this was a finished supposedly fully working MPLAB XC example. I assumed it would have been created with all the correct required includes. I have removed the hacking I did however am I missing an include or is this a parsing issue thats wrong despite a buildable project.... it builds OK.

Simon
 
Ian,

should that be an #include or a #define? it errors with #include and says it cant find the include if I change it. I have changed it back to #define. I tried to move it right to the top and then the bottom of the includes and it still shows a parse error. Is this something I am having to live with?


I'll run it through my simulator.... I'll post the running code back to you highlighting the changes...

I run XC8 professional so you'll have to rebuild..
 
Hi misterT,

Yes I understand that the correct library needs to be included. However this was a finished supposedly fully working MPLAB XC example. I assumed it would have been created with all the correct required includes. I have removed the hacking I did however am I missing an include or is this a parsing issue thats wrong despite a buildable project.... it builds OK.

Simon

I hear this problem all the time when people use C to program PICs. I have no idea what is going on with the tools.. the documentation is crappy, so you can't even try to find out what is wrong. Move on to using AVR. GCC is the best compiler out there.. solely because of the quality of the documentation.
 
solely because of the quality of the documentation.
Yep you got that right. Good doc's mean it all. That's why i keep using mikroC i has doc's just hate there use of librarys
 
Status
Not open for further replies.

Latest threads

Back
Top