This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

APP Timer and While loop in BLE

Hi,

I am using App Timer for measuring time and at the same time while loop to check if the timer reached particular time.

I have noticed during while loop App Timer event doesn't seems to work. Is this correct?

Regards Siva

Parents
  • In what interrupt priority do you check the timer value in a loop? If it is running in the same or higher priority than the application timer, your timeout event handler will never be called as it must wait for the other (same or higher priority) interrupt handler / event handler to finish first.

  • Do you really need to do so much in an interrupt context? And do you really need those loops waiting for a long time? It tends to give you a complex application where it is difficult to handle what is waiting for what (as you are seeing). Moreover, the CPU will be running for much of the time, causing an unnecessarily high current consumption.

    There are other issues with your code as well. In your Peace_Mask_Active(), where you have for example this loop:

    		while(true)
    		{
    			if(Current_Time_Sec > (Measured_Treatment_Time+20))
    			{
    				break;
    			}
    		}		
    

    you are waiting for Current_Time_Sec to change, which is updated in another event handler (in interrupt context). Even if you make sure that the Current_Time_Sec is updated in an event handler with higher priority (which is a must), it still won't help you unless you disable optimization, as the variable is not volatile and the compiler cannot easily know that it can change. Therefore, with normal optimization, the above loop would be optimized to something like this:

    		while(true)
    		{
    		}	
    

    ...which will continue to do nothing forever. (As long as you are just incrementing and waiting for it to become larger than a limit, making the variable volatile should be sufficient in this case. In other cases you would have to do more in order to make the operation atomic, using for example the CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() macros supplied with the SDK.)

Reply
  • Do you really need to do so much in an interrupt context? And do you really need those loops waiting for a long time? It tends to give you a complex application where it is difficult to handle what is waiting for what (as you are seeing). Moreover, the CPU will be running for much of the time, causing an unnecessarily high current consumption.

    There are other issues with your code as well. In your Peace_Mask_Active(), where you have for example this loop:

    		while(true)
    		{
    			if(Current_Time_Sec > (Measured_Treatment_Time+20))
    			{
    				break;
    			}
    		}		
    

    you are waiting for Current_Time_Sec to change, which is updated in another event handler (in interrupt context). Even if you make sure that the Current_Time_Sec is updated in an event handler with higher priority (which is a must), it still won't help you unless you disable optimization, as the variable is not volatile and the compiler cannot easily know that it can change. Therefore, with normal optimization, the above loop would be optimized to something like this:

    		while(true)
    		{
    		}	
    

    ...which will continue to do nothing forever. (As long as you are just incrementing and waiting for it to become larger than a limit, making the variable volatile should be sufficient in this case. In other cases you would have to do more in order to make the operation atomic, using for example the CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() macros supplied with the SDK.)

Children
No Data
Related