Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] breaking out of loop with delay_ms

Status
Not open for further replies.

mershi

Newbie level 2
Joined
Oct 12, 2017
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
25
I am writing a code in mikroc,

Can someone explain as to why it is difficult to break out of loop.. if the loop contains a high delay_ms()?


say if i have a button.. and if i press the button once.. it should break out of the loop..

say for example i have a code:

HTML:
while(btn1==1){
  
  
       PORTC.f0 ==1;
       delay_ms(300);
       PORTC.f0 ==0;
       delay_ms(300);
       

        
        
        if (Button(&PORTA, 1, 1, 1)) {


         btn1 = 0;
         previous2 = 1;

       }
        

  }

if (previous2 && Button(&PORTA, 1, 1, 0)) {
  

    PORTC.f0 ==0;
    previous2 = 0;

  }

this causes problem.. sometimes it works but sometimes i need to hold the button for 2 seconds and release to break out of the loop..

this problem does not happen if i have a delay of.. say.. delay_ms(10); (with smaller delay_ms, i can just push the button once and it breaks out of the loop everytime)


What should i do to solve the issue? and still retaining a delay_ms(300) or higher..
 
Last edited:

In the shown code, key input is at least ignored for a dead time 600 ms. When you say it's even 2 seconds, then there's probably more succeeding dead time without port test.

This behavior is simply by design of the code. Waiting for 600 ms (or more) and wanting to detect key presses in between can't work this way.

There are many ways to make it differently. Personally I would get rid of long delays with delay_ms statement. Instead have an interrupt based tic timer and perform any long delays by counting tics and performing all necessary housekeeping like key tests meanwhile. Or shift the key input to an interrupt routine and set a flag for the key press. Or use interrupt on change for the keyboard input.
 

In the shown code, key input is at least ignored for a dead time 600 ms. When you say it's even 2 seconds, then there's probably more succeeding dead time without port test.

This behavior is simply by design of the code. Waiting for 600 ms (or more) and wanting to detect key presses in between can't work this way.


Makes sense.. thank you for the explanation.. I can't quite grasp the concept of interrupt on change though..

can you help me understand using a simple code or alternative to delay_ms() ?? How do i interrupt between instructions?

because for example, i can't do this:


HTML:
while(state==0){

  txt = "one";
  delay_ms(300);
  txt = "two";
  delay_ms(300);
  txt = "three";
  delay_ms(300);

  if(button pressed){

  state = 1;

  }

}

 LCD_OUT(1,1,txt);

since "three" will always be displayed.. regardless of the timing.

among all the list you mentioned.. what is the easiest way to display the value of txt accurately when getting out of the loop.
 

instead of
Code:
delay_ms(300);
you can e.g. write
Code:
for (i=0;i<30;i++)
{
  delay_ms(10);
  if(button pressed)
    return;
}

return statement is just as an example of how the code sequence can be left. Depends on what should happen on key press.
 

(Thought invoked by FvM's connect about using interrupts)
I don't know what 'btn1' is (i.e. a variable that is set by some other code or a macro that expands to a port pin reference) but, if it is driven by a mechanical button or switch, then it needs to be debounced. Contact bounce is one of the reasons why it is almost never a good idea to connect a switch/button to an interrupt source directly.
Susan
 

Contact bounce is one of the reasons why it is almost never a good idea to connect a switch/button to an interrupt source directly.

Agreed. My usual options are
- scan the switch in timer interrupt with a period > bounce time.
- use hardware interrupt, e.g. PIC port change with a dead time after first occurrence.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top