Object counter

So you haven't still solved the problem with count ticking wildly while the light beam is broken?

Didn't you pick up the hint from my previous comment about flank-trigged (also called edge-trigged) and level-trigged events?

What magic thing do happen when the beam gets broken (note the transitional expression "gets broken" as separate from "is broken")?

I even followed up by writing "Why not just count one time and then wait for the light beam to be detected again before you rearm your counter?"

What have you done about it? What do you think "rearm" could mean? What actions do you do when you see the light beam again? Or what actions do you not do?

What would you do, as human being, if someone asks you to count how many times the sun light is blocked by a cloud? Would you count continuously while the sun is blocked? Or would you count just once, and then stop counting and wait until you can see the sun again? Do you really think it makes a difference if it's a microcontroller that counts, or if a human count? Isn't the problem still the same?

Might it help if we write that as "re-arm"?

Another fundamental requirement for a programmer is the ability to analyse a problem.

You need to have done this before you even start to think about coding!

There are many techniques - including flowcharts, etc.

Once you have analysed the problem, you can then start thinking about and then designing a solution to the problem - again, this is before you even start to think about coding!

Finally, once you have a design, you can implement it - which is where the coding starts...

From your hint i understood that I need use interrupt and i have tried using it in my own way and I dont no whether it is correct . Now the count get stop incrementing continuously after led turned off. But the problem is in debugger mode the count increment once when interrupt called but while displaying in lcd it increment twice. i had also tried communicating through serial port it works perfectly. can u give me some solution pls for the below written code.

P3   = 0x00;
        LED1 = 1;
/* LCD initialization */
        InitializeLCD();

        /* Display project titles */
        DisplayProjectTitle();

        *ArrayBasePtr=&UserMessageStorage;

        EA   = 1;
        EX0  = 1;
        IT0  = 1;

        while(True)
        {

/* Serial bit transmissions */
                SerTx(TotalCount[0]);
                SerTx(TotalCount[1]);
                SerTx(TotalCount[2]);

                ArrayBasePtr="  TOTAL OBJECTS  ";
                DisplayLCD(1,0,ArrayBasePtr);
                ArrayBasePtr=&TotalCount[0];
                DisplayLCD(2,5,ArrayBasePtr);
                TimeDelay(850);
                LCD_CLEAR();
void Extint0 (void) interrupt 0
{
//  IE0=0;
  value++;
  Count = value;

                UserMessageStorage[4]= Count/100;
                Count=(Count-(UserMessageStorage[4]*100));
                UserMessageStorage[4]+=0x30;

                UserMessageStorage[5]= Count/10;
                Count=(Count-(UserMessageStorage[5]*10));
                UserMessageStorage[5]+=0x30;

                UserMessageStorage[6]= Count%10;
                UserMessageStorage[6]+=0x30;

                TotalCount[0] =  UserMessageStorage[4];
                TotalCount[1] =  UserMessageStorage[5];
                TotalCount[2] =  UserMessageStorage[6];

                ArrayBasePtr="  TOTAL OBJECTS  ";
                DisplayLCD(1,0,ArrayBasePtr);
                ArrayBasePtr=&TotalCount[0];
                DisplayLCD(2,5,ArrayBasePtr);

                TimeDelay(850);
                LCD_CLEAR();

Thanks in advance

You can use interrupts or you can poll.

Polling requires that a pulse from the sensor is long in "processor time", so you are sure that you never miss catching the pulse because of worst-case loop repetition times.

My hints didn't had anything with interrupts to do, but with thinking about the difference between reacting when you see a specific change in a signal, compared to reacting when you see a signal in a continuous state.

Think about a one-shot flare gun.

You have agreed to signal whenever you see a boat.

So when you see the boat, you shoot the flare gun. Since you only have one shot in it, you only manage one shot. No repetition.

You have then agreed with yourself that you will not reload the gun until the first ship is out of sight.

So next time you see boat/ship you have a loaded gun again, and can shoot a flare.

You, on the other hand, sees your problem as a gatlin gun with infinite ammo. When you see the gun, you press the trigger and shoot and shoot and shoot until the boat is out of visible range.

Would that really be a good way to count boats?

That was what I meant when I talked about arming your logic.

In your case, you have two events (even if you may not be able to get your interrupt to handle both events) possible. One event is that the light gets blocked. One event is the light beam gets detected again.

You should only count when you get one of these two events. You could use any of the events (beam going from detected to not detected, or beam going from not detected to detected), but a professional solution would prefer the use of the second event - when the light beam gets detected again.

The reason for using the second edge/event, is that you can then measure the time the light beam was blocked. Why do that?
1) In case you have a narrow beam, you could interrest a couple of flies that gets buzzing through the beam, producing large numbers of very short pulses.

2) In case the beam fails, you would then be able to detect that the beam has been off for a very long time, so you could generate an alarm, reporting a equipment failure (maybe dead lamp, maybe dead light sensor, maybe stuck belt transporting the goods).