This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

linking error in the program . can not find the solution

I am a newbee in Microcontroller programing . the code I have written in C was from a book and it is giving linker error. please help me to solve the problem.
I am sending the code:

/*reading pwm waveform and calculation of frequency using microcontroller*/
#include<reg52.h>
sbit RS=P2^0;
sbit RW=P2^1;
sbit EN=P2^2;

sbit IN=P2^4;

void delay(void);
void INIT(void);
void ENABLE(void);
void LINE(int);

int ONTIME(int);
int offtime(int);
/*declaration of functions complete*/
//
void LINE(int i)
{ if(i==1) { RS=0; RW=0; P1=0x80; ENABLE(); RS=1; } else { RS=0; RW=0; P1=0xC0; ENABLE(); RS=1; }
}

/*dealy subroutine*/

void delay(void)
{ int i,j; for(j=0;j<10;j++) { for(i=0;i<100;i++); }
}

/*delay complete*/

/*Enable subroutine*/
void ENABLE(void)
{ EN=1; delay(); EN=0; delay();
}

/*initialisation of LCD giving proper command*/

void INIT(void)
{ RS=0; RW=0; EN=0; P1=0x38;// 2 Lines and 5*7 matrix LCD ENABLE(); ENABLE(); ENABLE(); P1=0x06; // Shift cursor to left ENABLE(); P1=0x0E; //display on, cursor blinking ENABLE(); P1=0x01; //clear display screen ENABLE();
} /* measuring ontime*/
int ONTIME(int m)
{ if(m==1) { IN=1; /*input to 8051 is from 555 osc*/ TMOD=0x01; TR0=0; TF0=0; TL0=0x00; TH0=0x00; while(IN); /*check for rising edge*/ while(!IN); TR0=1; while(IN); TR0=0; }

/* TO MEASURE OFFTIME*/

if(m==2) { IN=1; TMOD=0x01; TR0=0; TF0=0; TL0=0x00; TH0=0x00;

while(!IN); // check for falling edge while(IN); TR0=1; while(!IN); // CHECK FOR RISING EDGE TR0=0; } return((TH0*256)+TL0);
}

void main(void)
{ int unit, tens, hundred, thousand, tenthou, x; char code dis3[]="Fre in HZ="; char *p; int i,j,k,freq,l; while(1) { for(x=1;x<=3;x++) { if(x==1) { i=ONTIME(x); k=i; }

if(x==2) { i=offtime(x); l=i; } if(x==3) { freq=k+1; i=1/freq; } }

unit=(i%10); tens=(i/10)%10; hundred=(i/100)%10; thousand=(i/1000)%10; tenthou=(i/1000)%10; unit=unit+0x30; tens=tens+0x30; hundred=hundred+0x30; thousand=thousand+0x30; tenthou=tenthou+0x30; INIT(); LINE(0);

p=&dis3;

for(j=0;j<8;j++) { P1=*p++; ENABLE(); }

LINE(2); P1=tenthou; ENABLE(); P1=thousand; ENABLE(); P1=hundred; ENABLE(); P1=unit; ENABLE(); }
}

  • "Especially with embedded code, it does tend to be so very specific to a particular target & environment that expecting any random piece of cut-&-paste code to "just work" is wishful thinking in the extreme!"

    exaggerated truth is a lie.

    sure, there is a degree of hardware dependency in any code, more in embedded than others. but that does not mean one piece of code written for one target cannot work for another hardware, unmodified or slightly modified (to use different header files for example).

    this is particularly true if your code is written with a logic structure and with portability in mind.

  • "Do not rely on 'for' loops - or, indeed, any othe HLL construct - for timing!"

    it depends on what the timing requirements are.

    sometimes, you don't need precise timing, or allow for large timing errors in one direction, it makes perfect sense to use simple delay loops in those cases.

    again, it is impossible to lay down a general rule, other than that you need to look into the specific applications to determine what is the best / better approach.

  • But there is this one general rule: An incorrectly written for-loop delay can be totally removed by the compiler resulting in zero delay.

    The posted code is without side effects so the OP is throwing a dice.

    You are missing out on an important ghing. When debating with beginners, it's way better to start with absolutes. Special cases are better debated at a later time, when the person have enough experience and knowledge to fully understand the details. Doing it your way means that the unexperienced developer will very, very often think: "But my code is probably so special, so I should be fine going the alternative route." And the person whill be much more hurt than first getting a truth in absolute terms and years later receiving a more modulated answer.

    If you had spent any real time reading enough thousands of threads, you would have noticed the number of people who are constantly burned by software delays just because they are too often seeing software delays and too often hearing people talking about software delays.

  • "An incorrectly written for-loop delay can be totally removed by the compiler resulting in zero delay."

    but that's not the issue with the delay loop itself: it is an issue with documentation or user education.

    it is very much like electricity: incorrectly used, it can kill you. But that doesn't mean that you don't use electricity. instead, you put warning signs on the sockets and you educate the users.

    the same thing here.

    and the issue (of documentation / education) exists with any approach. You can write a piece of code using any approach you like and I can tweak the rest of the code to mess it up.

  • No, it doesn't.

    The timing associated with HLL constructs can never be relied upon.

  • "No, it doesn't."

    what doesn't what?

    "The timing associated with HLL constructs can never be relied upon."

    the only thing that cannot be relied upon is a stupid blanket statement made by people with tunnel vision, like the above.

  • Look Ashely, Andy certainly does not require my help with this, but if you were referring to what he posted than you:
    1. have a potty mouth (so do I from time to time, that's true).
    2. you're way out of your league - an observation.
    3. "The timing associated with HLL constructs can never be relied upon." Are you seriously contending this statement? If so, please provide evidence.

  • "the only thing that cannot be relied upon is a stupid blanket statement made by people with tunnel vision, like the above"

    OK, then - to what extent, exaclty, can the timing associated with HLL constructs be relied upon?

  • "OK, then - to what extent, exaclty, can the timing associated with HLL constructs be relied upon?"

    I have provided some examples in this very thread. all it takes is for you to spend time to read, rather than to make grandiose statements that have no meaning.

  • "the only thing that cannot be relied upon is a stupid blanket statement made by people with tunnel vision, like the above."

    let me elaborate a little bit, now that I have more time.

    what works and what doesn't work is highly circumstantial. a simple delay loop may not have worked for you before, but that experience doesn't mean it will never work for you or somebody else some other time.

    the beauty of the internet is so we can learn from each others' experience so we don't make the same mistakes. to learn from your experience, we would need you to provide more details as to how you come to that conclusion.

    to that extent, a conclusion without the background has no meaning: for all I could tell, you could have made that statement because you didn't like your co-workers who loved that approach; etc.

    if you had said the delay loop approach doesn't work because ..., we would have had a chance to evaluate how relevant your conclusion is to our specific applications and decide for or against it.

    Otherwise, making such grandiose statement without anything else is just like elementary school kids insisting that Michael Jordan is the best player, Period, because he couldn't articulate why.

    You don't want that to be the perception of you, anywhere.

  • Guys;
    Do you really like arguing with a sign post?

    Bradford

  • I have provided some examples in this very thread.

    I call bullshit on that one. The only example of anything you've provided here is the exact same thing you've been accusing others of: blanket statements without any supporting arguments whatsoever.

  • but that's not the issue with the delay loop itself: it is an issue with documentation or user education.

    I think I've told you the same in another thread, but it looks like you need a repeat lesson: you're making quite an effort only to prove you have no idea what you're talking about.

    That for loop delay shown by the OP won't work, and yes, that's an issue with that code itself. Your statement that this were a problem with documentation or user education just goes to show you don't even understand the problem.

  • what works and what doesn't work is highly circumstantial. a simple delay loop may not have worked for you before, but that experience doesn't mean it will never work for you or somebody else some other time.

    I see.
    Are you saying such delays loop do belong in production code, given different circumstances?
    You remind me of the kooks that claim that if you go far enough in the universe, the lays of physics change. Well - they don't, nor does the invalidity of the above code.

  • vicfitnessacademy.com.au/fitness-courses.html

    That is an awfully astounding column you've posted.Thanks a lot for that a fantastically amazing post!