Hi there...
I am trying to count the no of object pass in a conveyor systems and it need to be displayed in a LCD every time a object passes through it. I used IR for this purpose... wen ir detect the Object the led gets turned off and vice versa. Now the problem is wen LED turned off the counter keeps on counting till it get turned on
And also the counter counts only upto value 10 and it gets return to 1...
can any one pls help me.
check the program below
while(True) { if (LED1 == 0) { Count = Count+1; //LED1 = 1; }
// UserMessageStorage[4] = Count; // UserMessageStorage[1]+= 1;
UserMessageStorage[4]= Count/1000; Count=(Count-(UserMessageStorage[4]*100)); UserMessageStorage[4]+=0x30;
UserMessageStorage[5]= Count/100; Count=(Count-(UserMessageStorage[5]*10)); UserMessageStorage[5]+=0x30;
UserMessageStorage[6]= Count%100; UserMessageStorage[6]+=0x30;
TotalCount[0] = UserMessageStorage[4]; TotalCount[1] = UserMessageStorage[5]; TotalCount[2] = UserMessageStorage[6];
// u8Temp = (TotalCount[0] - 0x30) * 100; // u8Temp += (TotalCount[1] - 0x30) * 10; // u8Temp += (TotalCount[2] - 0x30) * 1; //
//TotalCount[0] = UserMessageStorage[1];
// SerTx(TotalCount[0]); // SerTx(TotalCount[1]); // SerTx(TotalCount[2]);
ArrayBasePtr="Total Objects= "; DisplayLCD(1,0,ArrayBasePtr); ArrayBasePtr=&TotalCount[0]; DisplayLCD(2,0,ArrayBasePtr); ArrayBasePtr=" Objects"; DisplayLCD(2,3,ArrayBasePtr); TimeDelay(1000); LCD_CLEAR();
Thanks in advance guys
Post it properly:
www.danlhenry.com/.../keil_code.png
So you have just learned the difference between flank-trigged and level-trigged signal processing.
Why do you let your counter tick constantly when the light beam is blocked? Why not just count one time and then wait for the light beam to be detected again before you rearm your counter?
UserMessageStorage[4]= Count/1000; Count=(Count-(UserMessageStorage[4]*100)); UserMessageStorage[4]+=0x30; UserMessageStorage[5]= Count/100; Count=(Count-(UserMessageStorage[5]*10)); UserMessageStorage[5]+=0x30; UserMessageStorage[6]= Count%100; UserMessageStorage[6]+=0x30;
So what happens if count is 3697 and you do the above?
Count = 3697 UserMessageStorage[4] = 3697/1000 (3) + 0x30. I.e. '3'. Count = 3697 - 3*100 = 3397;
UserMessageStorage[5] = 3397/100 (33) + 0x30. I.e. 'Q'. Count = 3397 - 33*10 = 3067;
UserMessageStorage[6] = 3067%100 (67) + 0x30. I.e. 's'.
So the counter value 3697 should then be represented as '3Qs'. Whas that really what you intended?
And the other thing is that your printout destroys your counter by modifying it. Isn't that quite silly?
The big question that may be a bit embarrasing: Haven't you tried to debug your code? Haven't you tried to give Count a value and then see what would happen, step-by-step? And see if you get a suitable value to print - and that you then get back to the top of your loop with Count still containing a meaningful value?
Well i am sorry for posting in wrong format. I am new to this Embedded Domain and Programming Field. For u guys like pro every thing will be silly, but for me even displaying a single character in LCD is a big think.And moreover I m learning now n i would mind getting embarrassing.
As u said i ve debugged the program and i m now getting the count properly. but i don't how to count only once when the led turned off .
if(LED1 == 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;
SerTx(TotalCount[0]); SerTx(TotalCount[1]); SerTx(TotalCount[2]); LED1 = 1; } Please help me .. thanks for ur information . its really useful MR.Mark
"sorry for posting in wrong format."
But you've done it again!
"I am new to this Embedded Domain and Programming Field"
But choosing the correct format for posting is simply a matter of following simple, clearly stated instructions - as this picture shows you (click the link to see it):
This requires no particular Embedded or Programming skills!
However, Programming does require great attention to detail; you need to carefully study all the available documentation, and pay attention to what you find.
Some people are just not cut out for this, which is fair enough - but it is what you'll need to do if you want to be a programmer.
If you are new to programming, then you may find it easier to learn the 'C' programming language on a PC first. Then, once you have learned the language, you can move on to apply it in the embedded microcontroller field
The following lists some books & training providers: http://www.keil.com/books/ http://www.keil.com/events/links.asp
publications.gbdirect.co.uk/.../
www.eskimo.com/.../
Note that using microcontrollers like this also requires at least a basic understanding of electronics...
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).