Why LED is not turning OFF - 8051 Timers

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
I will not be able to continue for 3 days. because I am going outside with my family I will not have a laptop so I will not be able to simulate or test code. I will come back
 

djsfantasi

Joined Apr 11, 2010
6,804
BTW, you have several data points for the input to your wait() function and the resultant delay in ms. You should be able to derive a linear equation for any input value and the resultant delay. Either you can use this equation to calculate the input value for any given delay... Or modify your function to input a delay in ms and calculate the number of iterations for your loop to obtain that delay.

I’d provide that function, but you can code it yourself since it’s my bedtime and I’m half-asleep.
 

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
In line 26 you want to wait until button is first time pressed, this means that you dont want to toggle LED until button is not pressed and you must write in line 26:

while(Button != 0); // wait until button pressed
I would like to apologize for being too late because I had some family issues due to which I could not come back but I'm ready now to move forward

C:
#include<reg51.h>

sbit LED = P1^0;
sbit Button = P0^7;

void Wait (long unsigned  int DelayTime)    /* Function to generate delay time */
{
    unsigned long int Count = 0;

    for (Count = 0; Count < DelayTime; Count++)
    {
        /* Do nothing */
    }
}

void main (void)
{
    P0 =0x80;
    P3 =0x00;
    P1 =0x00;
    P2 =0x00;
 

  while(1) //infinite loop
  {
    while(Button != 0); // wait until button pressed

    LED =~ LED;
          
    Wait(450); //debounce 24ms
          
    while(Button == 0); //If Button pressed
 
    Wait(450); //debounce 24ms

  }
}
When I hold button down continuously , LED doesn't change state that's what we want
 

trebla

Joined Jun 29, 2019
209
Ok, now we want the button debounce routine that is not blocking because in real time systems we have multiple processes who need to be checked too. In ideal case we want to be waste processor time for checking state changes only and not waiting after some event happening.

In the above code (#163) we are waiting and blocking another code to run:
1.until button pressed
2.after button press in debounce delay
3.until button released
4.after button release in debounce delay

The first waiting task can be eliminated with wrapping this debounce routine to if() statement body as you did at the beginning this tread but we cannot eliminate another blocking components (2, 3 and 4) in debounce routine this way.

If we want make non-blocking debounce routine, we must make these componets independently checkable, this means we must remember in which current state our button debounce routine is. Button has two states but button checking/debouncing routine has more states.

You can try to figure out these states.
 

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
Ok, now we want the button debounce routine that is not blocking because in real time systems we have multiple processes who need to be checked too. In ideal case we want to be waste processor time for checking state changes only and not waiting after some event happening.

You can try to figure out these states.
In this routine I am checking the status of button
C:
 int Button_Check()
{
     int status = Button_Not_Pressed;
    
     if(Button == 0 ) //If Button pressed
    {
       Wait(450); //debounce 40ms
            
         if(Button == 0) //If Button pressed again
            {       
              return Button_Pressed;
            }   
     }
        return Button_Not_Pressed;
 }
 

jpanhalt

Joined Jan 18, 2008
10,227
A push button SPST switch, resistor, and LED will so the same thing. No microcontroller required -- in reference to your new thread on sensors.
 

trebla

Joined Jun 29, 2019
209
If you start writing code without correct program flow or state diagram you ended up with big mess. Try to draw state diagram for debounce routines point of view.
 

trebla

Joined Jun 29, 2019
209
Try to imagine MCUs perception for outside events. You are sitting in the dark and count your heartbeats. Suddenly you see light on one port, you mark this event, toggle predetermined output pin and set goal for next count. Light flashes rapidly at the beginning (your perception rate is million times per second) and then later stays steady on for a while. But you are doing other things now, until noticed the counting goal is reached, marked this event and checked is the light still on, if yes, then you do again some other things, if not then you mark this event and set goal for next count. You are doing other things again and meanwhile noticed the counting goal is reached (again), marked light event to be cleared until you see it again.

For our debounce routine, these 'light' events are possible system states and for handling button debounce we need remember the current state. Try to draw state diagram with all the above mentioned states.
 

trebla

Joined Jun 29, 2019
209
Your state diagram represents two system states, one for LED not toggling if button not pressed and second for LED toggling continuosly if button pressed and waiting button to pressed same time, which can never happen in same time. This state diagram presents fully blocking routine which has no output.

We need real time processing system without any waiting states. We have input events caused by the outside world and we need process them, LED toggling is an output for debounce routine, instead LED we can set signal for another process input. Just think in which state is our debounce routine before button press and during debounce processing. Hint: i see at least 5 states.
 

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
We need real time processing system without any waiting states. We have input events caused by the outside world and we need process them, LED toggling is an output for debounce routine, instead LED we can set signal for another process input. Just think in which state is our debounce routine before button press and during debounce processing. Hint: i see at least 5 states.
Ok here is my new state diagram with button state
 

Attachments

trebla

Joined Jun 29, 2019
209
You focus on the button, button has only two states but for reading this button without errors we need debounce routine and this routine has at least 5 states. LED toggling is a different process or signal to another routine. You can derive these states from the flowchart you posted in #83. Focus on the debounce routine states and take the button as the input signal for this routine.
 

trebla

Joined Jun 29, 2019
209
I see following five possible states: button release debounce active, button press acknowledged, idle, button press debounce active, button press debounced.
Draw these states and try figure out which kind of transitions (or dependencies) are between different states. You can add output signal (LED toggle) as connection to another process but keep in mind that "toggling a LED" is transition between states not a state itself.
 

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
I see following five possible states: button release debounce active, button press acknowledged, idle, button press debounce active, button press debounced.
I do not understand how your states will work. Button has only two states, button is pressed and button is released.

Button release debounc activate state :
We can check if button is released and wait for debounce period

Button pressed debounc activate state :
We can check if button is pressed and wait for debounce period debounced mean?

What is debounce active mean?
What is button press acknowledged mean
What is button press debounced?
 

trebla

Joined Jun 29, 2019
209
I suggested you to imagine how MCU works. I try explain again and you try to imagine this:

MCU in our embedded system has many external connections to drive in real time and periodically check. One of inputs is our button. For this purpose we have one function (call it "button function") which is called periodically.
If button is not pressed a while, this function marks its state to "idle" and the MCU deals with other processes.
If button is suddenly pressed then our function marks its state to "button acknowledged", this state sends output signal for another process (like "toggle LED") and debounce timer.
Debounce timer starts an changes state to "button press debounce active ". Meanwhile MCU manages again with other tasks.
If debounce timer runs out then it changes state to "button press debounced".
If MCU reaches again the "button function" then it looks the current state and checks button input. If button is released, function sends signal to debounce routine and this marks state to "button release debounce active ".
If button still pressed then state remains unchanged and MCU can deal with other tasks until reaches the "button function" again. But in "button release debounce active " state, if debounce timer runs out it marks state back to "idle".
I believe you can now draw the state diagram.
 

Thread Starter

Djsarakar

Joined Jul 26, 2020
317
I suggested you to imagine how MCU works. I try explain again and you try to imagine this:
@trebla I am trying my best to understand I took many time to figure out myself but I still do not understand your states.

My guess is that you want to use the timer interrupt for the debounce routine. Set the time interrupt for small interval ie. 1ms and if button is pressed, increment counter and when count will equal to 40 counts and button is still pressed it confirmed button has been pressed

I am sorry , i don't really know what you thought
 

trebla

Joined Jun 29, 2019
209
For debounce timer we can use interrupt routine or just poll the timer interrupt flag regularly. Interrupt gives more precise timing than software polling. In the other hand, if we have some other tasks that require specific strict sequence and timing then we must dealing with disabling interrupts temporarily or use software polling instead. As button debouncing does not need precise timing we can just poll the timer interrupt flag in convient place in our software. Our priority is waste minimum time for checking debounce states. One possible solution for debounce timer routine is setting a timer for 1 ms period and activate timing by loading a countdown variable. Then we can poll timer interrupt flag in regular basis and if 1 ms is passed, decrement the countdown value until zero or let the interrupt based routine make same thing. If countdown variable reaches zero then the debounce timer routine changes debounce state as described in #178.

As you see now, there will be more than one functions are needed to be complete button debounce task in non-blocking mode. Therefore is reasonable create a state diagram before writing the code or even drawing the flowchart.
 
Top