I have an LED set up to blink each time the ISR fires, and I can see that I can stop the ISR from firing reliably with the first 'T' input, but I can't reliably restart it with the second 'T' command, even though I can tell from the printouts that the proper piece of code executed, like in the following output Opening portĬhecking for MPU6050 IMU at I2C Addr 0圆9ĭMP ready! Waiting for MPU6050 drift rate to settle. MySerial.printf("TIMSK5 = %x\n", TIMSK5) Serial.println(F("Toggle TIMER5 Enable/Disable")) I have a 'CheckForUserInput()' routine which allows me to input commands from the keyboard, so I added a 'T' command, as follows: switch (incomingByte) To troubleshoot, I added the TIMER5 ISR code to the test program, and I want to be able to enable and disable the ISR using keyboard commands, to see if I can cause the anomalous behavior with the ISR enabled, and prevent it by disabling the ISR.įrom reading about TIMER interrupts, it appears that setting TIMSKx (TIMSK5 in my case) to 0 will disable the ISR, and setting bit 0 to 1 (using TIMSKx |= OCIExA) will enable it. When I port the turn algorithm into the main program, however, it behaves erratically, and I suspect the culprit is a TIMER5 interrupt ISR that is in the main program but not in the test program. I constructed a very small program to test just the turns, and this works fine. And since you're operating on a copy of the parameters changed by the interrupt, it doesn't matter if the interrupt changes the parameters in the middle of execution because you're not looking at those values until you make copies.I have a fairly complex autonomous robot program that is getting into trouble when executing controlled turns. Since the interrupt is never disabled, you never have to worry about losing any of them. If you need to modify x_prime, you'll need another copy. The break patterns assume that you're not changing x_prime. I'll operate under the assumption that you need to break out of processing XYZ but it's easy enough to not.Ĭode would look something like this: volatile int x It's not clear from the question whether you need to stop processing of XYZ immediately when the globals change, or if you can wait till XYZ finishes processing to swap in new copies of the variables. You could operate on a copy of the global variables and swap in the new value from the interrupt once you're done with XYZ. This is a big problem (one of the reasons is that TIM4 IRQHandler changes the globals and then activates the TIM4 again to give an interrupt later, I do this because the period between interrupts varies).Ĭan anyone give me a solution to this problem? Is there a better way to disable/restore TIM4 IRQ and NOT lose any interrupt? NEXT SOLUTION Disable only TIM4 interrupt on line A with: TIM_ITConfig(TIM4, TIM_IT_Update, DISABLE)Īnd enable it back on line B with: TIM_ITConfig(TIM4, TIM_IT_Update, ENABLE)įails because I am losing the interrupt: when the int is restored, the interrupt that arrived during XYZ is ignored. MY INITIAL SOLUTION: Disable interrupts on line A with _disable_irq() and restore them on line B with _enable_irq()įails because the XYZ complex operation must use other interrupts (other than TIM4). PROBLEM IS: Since XYZ has many instructions, TIM4 IRQ may come right in the middle of it and, after the IRQHandler changes the globals, the operations resume from the middle of XYZ which ruins the program. So basically I want XYZ to execute repeatedly and TIM4 interrupt to stop XYZ, change the parameters and then the loop must restart by restarting XYZ with the new global parameters. The TIM4 interrupt handler does this: stops XYZ & changes some globals that afect XYZ operations.
XYZ is a complex operation involving tranfers of data between buffers and others.
I have a portion of a code that does an loop-operation XYZ continuously, and from time to time a TIM4 interrupt changes some global parameters and causes the operation XYZ to restart. I'm working on an embedded project in C on a stm32f4xx uC.
0 kommentar(er)
