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(); }
}

Parents Reply Children
  • "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.

  • 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.