Where does this return statement return to if it is inside this infinite while(1) loop? More importantly, I had no idea that a while(1) loop could be broken???
void __attribute__((interrupt, no_auto_psv)) _T3Interrupt(void)
{
int count;
IFS0bits.T3IF = 0; // clear Tmr3 interrupt flag
StopMotor();
IEC0bits.ADIE = 0; // disable ADC interrupt
IEC0bits.CNIE = 0; // disable CN interrupt
IEC0bits.T3IE = 0; // disable Tmr3 interrupt
T3CONbits.TON = 1; // restart tmr3
count = 0;
while (1)
{
if (IFS0bits.T3IF)
{
IFS0bits.T3IF = 0; // clear flag
if (count++ >= RESTART_COUNT)
{
IEC0bits.ADIE = 1; // enable ADC interrupt
IEC0bits.CNIE = 1; // enable CN interrupt
T3CONbits.TON = 0; // stop tmr3
IEC0bits.T3IE = 1; // enable Tmr3 interrupt
return;
}
}
}
return;
}
All return statements will return to wherever the function was called from, regardless of where they are located within the function.
For instance, if I wrote:
int main()
{
_iT3Interrupt();
}
Then the return statement in _iT3Interrupt will revert control flow back to main.
Also, any loop can be exited (even if the condition is 1, true, or some equivalent) with any of the following constructs:
break; //exits the loop
return; //exits the function, thus ending the loop
goto <label-outside-loop>; //self-explanatory
exit(); abort(); //exits the program. Bit of a stretch to say that this ends the loop...
And in C++, throw, which will unwind the stack until it reaches a corresponding catch, thus exiting the function. The C setjmp and longjmp functions may also be applicable here, but I don't know enough C to be certain of their usage.
There are multiple ways to get out of a loop with return break goto
with your snippet if IFS0bits.T3IF != 0 then it will eventually break out of the loop when count >= RESET_COUNT. After that it will return to where the function was called from.
To answer your second question, while(1) is more like while(true). Therefore, it keeps on looping until it encounters a break.
When a function is called the address the function (or ISR) is called from is put on the top of the stack.
The execution of return will end the function (or ISR). The programm counter (PC) is updated with this address, so the program flow could continue with the statement following the calling address.
Related
I have been working on a simple project on AVR microcontroller atmega16 on proteus simulation.
The project is:
When I push the push button it increments the seven segment to number 9 and after that if the we pushed the button again it overflows and return again to 0.
When I change the (flag=1;) position at while loop code it gives me different outputs and by this I mean when I push the push button it didn't response after the pushing.
It may require another pushing to the button to increment the seven segment proteus simulation
The only code that worked properly is when set flag=1; before exiting (the second if and else conditions)
So my question is what actually happened when I change the flag=1; statement position at the code.
#include<avr/io.h>
#include<avr/interrupt.h>
char flag=1;
char num=0;
void INT2_Init(void){
DDRB&=~(1<<2);
SREG|=(1<<7);
GICR|=(1<<INT2);
MCUCSR|=(1<<ISC2);
}
ISR(INT2_vect){
flag=0;
GIFR|=(1<<INTF2);
}
int main(void){
DDRC=0x0f;
PORTC=0;
DDRB&=~(1<<2);
INT2_Init();
while(1){
if(flag==0){
if(num>8){
num=0;
PORTC=(PORTC&0xf0)|num;
}
else{
num++;
PORTC=(PORTC&0xf0)|num;
}
}
flag=1;
}
}
If some variable changes in main code and interrupt, you have to mark it volatile. Otherwise, the compiler may decide to cache variable value and omit its reading inside a loop.
volatile char flag=1;
Second, pay attention when and where your flag variables are changed. E.g.:
while(1){
// at this point flag is 0, comparison failed
if(flag==0) {
...
}
// Interrupt happens here, changing flag to 0
// Then flag is immediately reset, thus flag change is missed in the loop
flag=1;
}
Instead consider to use such a pattern:
while (1) {
cli(); // disabling interrupts ensuring no interrupt happens inside
if (flag==0) {
...
}
flag = 1;
sei(); // re-enable interrupts
}
or, in this case, it can be simpler
while (1) {
if (flag==0) {
flag = 1; // Reset flag only if it set, right after comparison
...
}
}
It is not entirely clear to me what you are asking. Do you just struggle to understand the code? Do my comments help?
#include<avr/io.h>
#include<avr/interrupt.h>
char flag=1;
char num=0;
void INT2_Init(void){
DDRB&=~(1<<2);
SREG|=(1<<7);
GICR|=(1<<INT2);
MCUCSR|=(1<<ISC2);
}
// sets flag to 0 on external interrupt (button press)
ISR(INT2_vect){
flag=0;
GIFR|=(1<<INTF2);
}
int main(void){
DDRC=0x0f;
PORTC=0;
DDRB&=~(1<<2);
INT2_Init();
while(1){
// if flag was set to 0 in external interrupt -> increment (or overflow) number on segment display
if(flag==0){
if(num>8){
num=0;
PORTC=(PORTC&0xf0)|num;
}
else{
num++;
PORTC=(PORTC&0xf0)|num;
}
}
// reset the flag to 1 to prevent num from being incremented continuously
flag=1;
}
}
I would suggest to move flag=1; inside the if to make the intent clear that the statement should only execute once with every button press.
while(1) {
// if flag was set to 0 in external interrupt -> increment (or overflow) number on segment display
if(flag==0){
// reset the flag to 1 to prevent num from being incremented continuously
flag=1;
if(num>8){
num=0;
PORTC=(PORTC&0xf0)|num;
}
else{
num++;
PORTC=(PORTC&0xf0)|num;
}
}
}
It is also advisable to use self descriptive variable names. Like buttonWasPressed instead of flag for example. That makes code like that much easier to read.
Using a 8-bit AVR micro, I arrived to a simple situation which might not be that easy to solve.
Consider the following snippet:
static volatile uint8_t counter;
//fires often and I need all the values of the counter.
void isr(void) {
counter++;
}
int main (void) {
while(1) {
send_uart(counter);
counter = 0;
delay_ms(1000); //1 sec pause
}
return 0;
}
1.) It can happen that send_uart is followed by an isr which increases the counter, and then the next statement zeroes it out.
Therefore I'll miss one data from the counter.
2.) If I use ATOMIC_BLOCK(ATOMIC_RESTORESTATE) in the main fn, I can avoid the problems declared in (1), but it can happen that I miss an ISR because in this case INTs are disabled for a short time.
Is there a better way to pass information from the main fn to ISR?
If the counter is sampled rather than reset, there won't be any timing issues. Increments happening while sending will be accounted for in the next iteration. The unsigned data type of the counter variables will guarantee well-defined overflow behavior.
uint8_t cs = 0; // counter sample at time of sending
uint8_t n = 0; // counter as last reported
while (1) {
cs = counter; // sample the counter
send_uart((uint8_t)(cs - n)); // report difference between sample and last time
n = cs; // update last reported value
delay_ms(1000);
}
I'm waiting some time for a real-world event (e.g. push a button for 3 seconds) on an AVR or STM32 MCU, and I have trouble with code like:
#define PRESS_BUTTON
int waiting = 0;
int t_ms = 0; // time counter
//...
int main(void)
{
while(1)
{
waiting = t_ms + 3000; // waiting button 3 sec
while ((t_ms < waiting) && (!PRESS_BUTTON)) // infinite loop
{}
printf("out"); // not printed
waiting = t_ms = 0;
}
}
ISR( TIMER0_OVF_vect ) // timer interrupt
{
t_ms++;
}
But if I add a printf() inside the while loop, it works!
The same thing happens if I use a do...while loop either. What is causing this?
You need to declare t_ms with volatile
volatile int t_ms =0;
Volatile tells the compiler that the variable may be changed due to external factors, and because of this the compiler will never assume it will stay the same.
In other words, it will force the compiler to check every loop to see if t_ms has changed instead of assuming it will never change.
In the code below, I can see that the timer is working normally as the LED is always blinking. But the value of the count variable never changes inside the second while.
I don't know what could possibly go wrong?
// count variable used only in main and TIM2_IRQHandler.
uint8_t count=0;
int main(void)
{
count=0;
SystemInit();
GPIOInit();
NVIC_Configuration();
TIM_Configuration();
init_USART3(115200);
// All initialization is ok.
USART_puts(USART3, "\r\nConnection ok.\r\n");// Working normally
while (1)
{
if(asterixok==1)// No problem. This code if ok ->>process continue next step.
{
GPIO_SetBits(GPIOD , GPIO_Pin_12); // Led on (ok)
count=0;// count going to zero, timer working, must be change in there
while(1)
{
//Led blinking continue
//Timer query working normal led (13) blink.
//There is a problem
if(count>5) // Timer working, count never change in timer interrupt query (WHY)
{
GPIO_SetBits(GPIOD , GPIO_Pin_14); // LED OFFFFFFFFFFFFFFFF
USART_puts(USART3, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\n");
goto nextstate;
}
}
nextstate:
GPIO_SetBits(GPIOD , GPIO_Pin_15); // Led never going on because code step in while loop.
}
}
}
void USART3_IRQHandler(void)
{
if( USART_GetITStatus(USART3, USART_IT_RXNE) )
{
unsigned char t = USART3->DR;
if(t=='*')
{
asterixok=1;
}
}
}
void TIM2_IRQHandler(void)
{
if ( TIM_GetITStatus(TIM2 , TIM_IT_Update) != RESET )
{
TIM_ClearITPendingBit(TIM2 , TIM_FLAG_Update);
count++;
if(count>100)
count=0;
if( display )
{
GPIO_ResetBits(GPIOD , GPIO_Pin_13);
}
else
{
GPIO_SetBits(GPIOD , GPIO_Pin_13);
}
display = ~display;
}
}
I have tried with another Discovery board but the problem continues.
Please help. I'm going crazy!
You should declare count as volatile, as such :
volatile uint8_t count;
While compiling main the compiler was able to prove that count was not modified in the loop body, and so it probably cached its value in a register and maybe even optimized out the if statement. You could verify that by looking at a disassembly. The compiler does not know about interrupts as per the standard and so is permitted to perform such optimizations. Qualifying count as volatile will forbid the compiler from making these optimizations, forcing it to reload the variable from memory each time it is used.
In this simple case volatile will be enough but please be aware that it doesn't guarantee atomicity of operations, and it doesn't prevent the compiler and CPU from reordering instructions around accesses to the variable. It only forces the compiler to generate memory access instructions each time the variable is used. For atomicity you need locks, and to prevent reordering you need memory barriers.
My program contains few global variables , whose values are set during the interrupt service routine (USCI_A0_ISR()) execution.
Once the execution of USCI_A0_ISR() is done , will the global variables hold the value assigned or will be set back to void/0.????
//Global variables
int ptr = 0;
char rxBuffer[16];
int flag = -1;
int check[2];
void __set_flag(void)
{
if (strcmp(rxBuffer,"OK") == 0) flag = 0;
else if (strcmp(rxBuffer,"CONNECT") == 0) flag = 1;
else if (strcmp(rxBuffer,"NO CARRIER") == 0) flag = 3;
else if (strcmp(rxBuffer,"ERROR") == 0) flag = 4;
}
void __GSM_client(void)
{
while (flag == -1);
if (flag == 0) check[0] = buflen(rxBuffer);
}
void main(void)
{
__Buffer_init();
__low_level_init(); //WDT
__UART0_init(); //UART
__bis_SR_register(GIE); //interrupts enabled
__delay_cycles(1000); // wait till UART intial
__GSM_client();
__no_operation(); // For debugger
}
#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void)
{
char byte;
while (!(UCA0IFG&UCTXIFG));
byte= UCA0RXBUF;
UCA0TXBUF = byte;
if (byte == '\r') {
//push_char(byte);
ptr = 0;
__set_flag();
//__Buffer_init();
}
else{
push_char(byte);
}
}
Here is the code snippet of what I am doing. I am setting the "flag" based on the response obtained . When I see the register view in Code Composer Studio , the "flag" value is set correctly , but if try using the value of "flag" elsewhere the value of "flag " is not reflected.
Any pointers over concepts of the interrupt service routine or when loopholes in my coding method appreciated
Thanks in Advance
AK
Within the interrupt, you are directly or indirectly changing several global variables, e.g. ptr, flag, and I'm assuming rxBuffer[?]. They are not declared "volatile" so their value may or may not change when you return from the interrupt. This is a bug because the behavior can change based on where in the execution of the code the interrupt occurs and what the level of optimization is. As a rule of thumb, any variable modified by an interrupt routine should always be declared volatile.
If you're sure that making the shared variables volatile isn't working then I'd suspect you have redefined a global variable as a local variable somewhere. Check the address of the flag variable when you are debugging and make sure it is the same in __set_flag() and outwith the interrupt, where you think it has not been updated.
I also think that the polling loop in your ISR is poor code and you should find a better way to wait for the transmitter to be ready for the next character.
Thanks to all the feedback i got from the members. Well the idea of declaring all the "variables volatile" did the trick . strcmp() uses const var* so i couldn't use it . I had to write my own custom string compare function. All this minor things solved my problems.