Interrupt Handler behaving wierdly - c

I am using a code as shown. I have a buzzer connected to pin 14. The function 'Sound_Play()'(produces sound for 0.5 secs) does its work only when encountered the second time inside the loop.
void loop() {
inside_loop=1;
TCCR1A=0; //initialize Timer1 for 1sec duration
TCCR1B=0X0D;
OCR1A=15624;
TIMSK1=0X02;
Sound_Play(); //This does not seem to work
block1=1; block2=0;
while(timer1_value>0)
{digitalWrite(13,HIGH);}
block1=0; block2=1;
Sound_Play(); //This works
while(timer2_value>0)
{digitalWrite(13,LOW);}
timer1_value=time1_sec;
timer2_value=time2_sec;
}
ISR(TIMER1_COMPA_vect)
{ if (block1==1) {timer1_value--;}
else if (block2==1) {timer2_value--;}
}
void Sound_Play(){ //activate timer2 for producing sound for 0.5 secs
TCCR2B=0x07;
TCCR2A=0x02;
OCR2A=35;
TIMSK2=0x02;
counting=110;
}
ISR(TIMER2_COMPA_vect)
{ if(inside_loop)
{
if(counting>0){
digitalWrite(14,HIGH);
counting = counting-1;
}
else{
TIMSK2=0x00; //deactivate timer2 on completing the time
digitalWrite(14,0);
}}
I tried using function once inside loop . It still made buzzer on only when encountered second time. I don't think the priority of the interrupts must be causing this.
Can please someone explain why this function does not make sound on everytime it is encountered?
Thanks!
Bhuvnesh

Related

STM32 - While loop blocking behaviour of timerUpdate callback in stepper motor application

I am working on a 2-axis CNC machine using an STM32F103C8T6 and using the HAL libraries. I've setup a seperate timer for each axis of the machine and have those configured in PWM mode.
I have a function called step_x(numberSteps, Direction) which takes in two parameters which are the number of steps to make and the direction to move in. The function sets the number of steps as the target number of steps in a global variable, sets the direction via GPIO write and then starts the PWM in interrupt mode using the HAL library:
void step_x(uint32_t numberSteps, uint16_t direction){
RELEASE_X=0;
steps_x_target = numberSteps;
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_5, direction_x);
__HAL_TIM_ENABLE_IT(&htim1, TIM_IT_UPDATE);
HAL_TIM_PWM_Start_IT(&htim1, TIM_CHANNEL_1);
}
This then starts the PWM and I am counting the number of pulses via the timer update callback function:
void TIM1_UP_IRQHandler(void)
{
if (__HAL_TIM_GET_FLAG(&htim1, TIM_FLAG_UPDATE))
{
if (__HAL_TIM_GET_IT_SOURCE(&htim1, TIM_IT_UPDATE))
{
step_update('X');
__HAL_TIM_CLEAR_FLAG(&htim1, TIM_FLAG_UPDATE);
__HAL_TIM_CLEAR_FLAG(&htim1,TIM_FLAG_CC1 );
}
}
}
Inside this callback, step_update() is called taking as a parameter which axis I am working with.
The step_update function adds +1 to a count for the number of steps that have occured and stops the PWM when the number of steps is equal to the target number of steps that was set. It also calls a function which keeps track of the position in mm rather than steps. (Y and Z axis cases removed for the sake of brevity)
void step_update(char axis){
switch(axis){
case 'X':
steps_x++;
updatePosition(axis);
if(steps_x==(2*steps_x_target)){ //check if 2* because the update event happens twice every pulse
HAL_TIM_PWM_Stop(&htim1, TIM_CHANNEL_1);
steps_x_target=0;
steps_x=0;
RELEASE_X=1;
if(limitSwitchX_Trigger==1){
positionX=0;
limitSwitchX_Trigger=0;
NVIC_EnableIRQ(EXTI0_IRQn);
}
}
break;
case 'Y':
break;
case 'Z':
break;
}
}
I'm sure this is not an entirely efficient way to do this however it works well enough except for the fact that I have no way to call the step_x() function and wait for it to finish before making the call to the next one. I added the volatile variables RELEASE_X which is set to 0 when step_x() is called and set to 1 when the step_update() function has stopped the PWM when the target steps are reached. I thought using this that I may be able to do something like this which I would expect to step 800 pulses in one direction and then step 800 pulses in another direction:
step_x(800,0);
while(RELEASE_X!=1);
step_x(800,1);
However what happens is that the while loop ends up blocking the Timer1_Update callback from occuring and the pulses don't get counted. I expected that because the pulse counting is done in an ISR callback that the MCU would just jump to the ISR from this while loop and update the steps until RELEASE_X is set to true and then advance to the next call of step_x()? Why is this not so?
Could someone suggest a way that I can write code which will allow me to call a function which steps a certain amount of steps while waiting for them to finish before moving on to the next call? I am trying to implement Bresenhams line algorithm next and so I need to step a certain amount of steps and then only return from the call and advance to the next line of code when the steps are complete. (Essentially, how can I make this function blocking but without toggling GPIO pins/bit bashing)
https://github.com/Blargian/EPR400
It's not really an answer as to why this happened but I solved the problem by disabling the timer update and global interrupts in CubeMX under the NVIC tab. I removed the callback functions from my main.h and main.c and then I modified the step_x function to be:
void step_x(uint32_t numberSteps, uint16_t direction){
RELEASE_X=0;
steps_x_target = numberSteps;
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_5, direction_x);
__HAL_TIM_ENABLE_IT(&htim1, TIM_IT_UPDATE);
HAL_TIM_PWM_Start_IT(&htim1, TIM_CHANNEL_1);
while(RELEASE_X!=1){
if (__HAL_TIM_GET_FLAG(&htim1, TIM_FLAG_UPDATE))
{
if (__HAL_TIM_GET_IT_SOURCE(&htim1, TIM_IT_UPDATE))
{
step_update('X');
__HAL_TIM_CLEAR_FLAG(&htim1, TIM_FLAG_UPDATE);
__HAL_TIM_CLEAR_FLAG(&htim1,TIM_FLAG_CC1 );
}
}
}
}
Basically just moved the code that was in the callback function to within the while loop in the step_x function. The function is now a blocking function which is atually what I need anyway.

Can a SysTick exception in Cortex-M4 preempt itself?

I have a handler for SysTick exception which counts ticks and calls other functions (f1, f2, f3) whose execution time can be longer than SysTick period. These functions set and clear their active status (global variables) so if a SysTick exception occurs it can detect an overload and return to interrupted function.
I have assigned fixed priority to SysTick exception (let's say 16). I want to somehow make possible for SysTick to generate an exception regardless of it's prior active status, go to SysTickHandler, increase tick counter and return to interrupted function.
One solution which may be useful is to use BASEPRI. It can be set to priority lower than SysTick so it would enable that exception. Unfortunately, using BASEPRI got me nowhere because nothing happened (I set it to max value). BASEPRI value was 0 inside SysTickHandler before I changed it. Should that value be equal to SysTick priority when processor enters handler function? Is exception priority loaded automatically in BASEPRI?
I have also considered for NVIC to have an issue with preempting already active exception but found nothing regarding that in ARM documentation.
Also, return from handler when oveload is detected could set the processor state to thread mode. Let's ignore that for now.
void SysTickHandler(void) {
ticks++;
//set_BASEPRI(max_value);
if (f1_act || f2_act || f3_act) return;
else {
f1();
f2();
f3();
}
}
A simpler example for this problem (without return) would be to increase tick counter when having an infinite loop inside handler.
void SysTickHandler(void) {
ticks++;
set_BASEPRI(max_value);
while(1);
}
If the interrupt becomes pending while its handler is already running, the handler will run to completion and immediately re-enter. Your tick will be aperiodic, and if the functions consistently take longer that one tick period, you may never leave the interrupt context.
It may be possible I suppose to increase the priority of the interrupt in the handler so that it will preempt itself, but even if that were to work, I would hesitate to recommend it.
It sounds that what you actually need is an RTOS.
Sorry to disappoint you, but it seems a overall design problem to me...
Why won't you just set some flag in SysTick and read it somewhere else?
Like:
#include <stdbool.h>
volatile bool flag = false;
//Consider any form of atomicity here
//atomic_bool or LDREX/STREX instructions here. Bitbanding will also work
void sysTickHandler(void) {
ticks++;
if (f1_act || f2_act || f3_act) return;
else {
flag = true; //or increment some counter if you want to keep track of the amount of executions
}
And somewhere else:
int main() {
// some init code
//main loop
for(;;) {
foo();//do sth
bar(x); //do sth else
if (flag) {
f1();
f2();
f3();
flag = false;
}
}
}
Or if we assume that every interrupt wakes the microcontroller and power-down mode is needed, then sth. like this might work:
if (flag) {
f1();
f2();
f3();
flag = false;
}
goToSleep(powerDownModeX); //whatever;

How to force interrupt to restart main loop instead of resuming? (timing issue!)

For the last two days i wrote a program that in basic terms generates a fairly accurate user adjustable pulse signal (both frequency and duty cycle adjustable). It basically uses the micros() function to keep track of time in order to pull low or high the 4 digital output channels.
These 4 channels need to have a phase difference of 90 degrees (think a 4cyl engine) always. In order for the user to change settings an ISR is implemented which returns a flag to the main loop to re-initialise the program. This flag is defined as a boolean 'set4'. When it is false a 'while' statement in the main loop will run the outputs. When it is true an 'if' statement will perform the necessary recalculations and reset the flag so that the 'while' statement will resume.
The program works perfectly with the initial values. Phase is perfect. However when the ISR is called and comes back to the main loop, from how i understand it resumes the program in the 'while' statement from where was originally interrupted, until it finishes and re-checks the flag 'set4' to see it is now true and it should stop.
Then, even though the 'if' statement afterwards resets and re-calculates all the necessary variables the phase between these 4 output channels is lost. Tested manually i see depending on which time the ISR is called it will give different results, usually having all 4 output channels synchronised together!
This happens even though i might don't change any values (thus the 'if' routine resets the variables to exactly the same ones when you first power up the arduino!). However, if i comment out this routine and just leave the line which resets the flag 'set4' the program will continue normally like nothing never happened!
I'm pretty sure that this is somehow caused because of the micros() timer because the loop will be resumed from where the ISR was called. I've tried to do it differently by checking and disabling for interrupts using cli() and sei() but i couldn't get it to work because it will just freeze when the arguments for cli() are true. The only solution that i can think of (i've tried everything, spend the whole day searching and trying out stuff) is to force the ISR to resume from the start of the loop so that the program may initialize properly. Another solution that comes to mind is to maybe reset the micros() timer somehow..but this would mess up the ISR i believe.
To help you visualise what is going on here's a snip of my code (please don't mind the 'Millis" name in the micros variables and any missing curly brackets since it is not pure copy-paste :p):
void loop()
{
while(!set4)
{
currentMillis = micros();
currentMillis2 = micros();
currentMillis3 = micros();
currentMillis4 = micros();
if(currentMillis - previousMillis >= interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
// if the LED is off turn it on and vice-versa:
if (ledState == LOW)
{
interval = ONTIME;
ledState = HIGH;
}
else
{
interval = OFFTIME;
ledState = LOW;
}
// set the LED with the ledState of the variable:
digitalWrite(ledPin, ledState);
}
.
.
//similar code for the other 3 output channels
.
.
}
if (set4){
//recalculation routine - exactly the same as when declaring the variables initially
currentMillis = 0;
currentMillis2 = 0;
currentMillis3 = 0;
currentMillis4 = 0;
//Output states of the output channels, forced low seperately when the ISR is called (without messing with the 'ledState' variables)
ledState = LOW;
ledState2 = LOW;
ledState3 = LOW;
ledState4 = LOW;
previousMillis = 0;
previousMillis2 = 0;
previousMillis3 = 0;
previousMillis4 = 0;
//ONTIME is the HIGH time interval of the pulse wave (i.e. dwell time), OFFTIME is the LOW time interval
//Note the calculated phase/timing offset at each channel
interval = ONTIME+OFFTIME;
interval2 = interval+interval/4;
interval3 = interval+interval/2;
interval4 = interval+interval*3/4;
set4=false;
}
}
Any idea what is going wrong?
Kind regards,
Ken
The problem is here:
previousMillis = 0;
previousMillis2 = 0;
previousMillis3 = 0;
previousMillis4 = 0;
All if statement will be true on the next loop.
Try with:
previousMillis = micros();
previousMillis2 = micros();
previousMillis3 = micros();
previousMillis4 = micros();

Increasing an integer through a time delay

I'm producing a game in C on a microprocessor. The score is controlled by how long you can survive; the score increases by 1 every 3 seconds. The score is an integer which is declared globally, but displayed from a function.
int score = 0;//globally declared
void draw_score(int score_d)
{
char score_draw[99];
sprintf(score_draw,"%d", score_d);
draw_string(score_draw, 9, 0);
}
I was thinking of a function which just increases the score by one with a delay on it, however that has not worked.
void score_increaser(int score)
{
score++;
_delay_ms( 3000 );
}
Does it need to be in a while loop? the function itself would go into a while loop in the main anyway.
C is pass by value.
score_increaser() as shown in your question increases just a copy of what is passed in.
To fix this there are (mainly) two options:
As score is defined globally, do not pass in anything:
void score_increaser(void) {
score++;
_delay_ms( 3000 );
}
This modifes the globale score directly.
Pass in the address of score and de-reference it inside the function
void score_increaser(int * pscore) {
(*pscore)++;
_delay_ms( 3000 );
}
Call it like this
...
score_increaser(&score);
...
A 3rd, a bit more complex, approach (which assumes signals are supported on the target platform) would
setup a signal and a referring handler, then
setup a timer to fire a signal every N seconds.
This signal then is handled by the handler, which in turn
increases the global score and
starts the timer again.
This might look like:
#include <signal.h> /* for signal() and sig_atomic_t */
#include <unistd.h> /* for alarm() */
#define DURATION (3) /* Increase score every 3 seconds. */
sig_atomic_t score = 0;
void set_alarm(unsigned);
void handler_alarm(int sig)
{
++score;
set_alarm(DURATION);
}
void set_alarm(unsigned duration)
{
signal(SIGALRM, handler_alarm);
alarm(duration);
}
int main(void)
{
set_alarm(DURATION);
... /* The game's codes here. */
}
This latter approach has the advantage that your game's code does not need to take care about increasing score. score is just increased every 3 seconds as long as the program runs.
I'd recommend using a timer interrupt. Configure the timer to 3 seconds.
volatile int score = 0; //global
void Intr_Init(peripheral_t per)
{
//Initialize the timer interrupt
}
void draw_score(int score_d)
{
char score_draw[99];
sprintf(score_draw,"%d", score_d);
draw_string(score_draw, 9, 0);
}
int main(void)
{
Intr_Init(TIMER);
while(1)
{
//Code that makes your game run
draw_score(score);
}
}
ISR (TIMER1_COMPA_vect)
{
//clear disable interrupt
score++;
//enable interrupt
}
In embedded, you should rely on Timers for better time critical tasks and accuracy. The way Delay routines are implemented is usually a loop or a up/down counter. Whereas a timer is usually based on counting SysTicks.
Another major advantage of Interrupts is that you let processor do its tasks all the while instead of making it block in a delay loop.
score is global value then do not need to pass it in function if that function has access to that global space
void score_increaser() {
score++;
_delay_ms( 3000 );
}
here is a good method for handling the score.
in the 'start game' function,
clear 'score' to 0
setup a timer:
--to expire once each 3 seconds
--enable the automatic reload feature,
--enable the timer interrupt
--enable the timer counter
in the timer interrupt handler function
--increment 'score'
--clear the timer interrupt pending flag
in the 'end game' function
disable the timer counter
disable the timer interrupt
display the 'score' value
You dont need parameter for the score since it's declared globally..
//global
int score = 0;
void score_increaser()
{
_delay_ms(3000);
score++;
}
calling is like: score_increaser(); should do the work..
i suggest you check for score in any other line/function.. maybe you have redeclared it or accidentally changed the value..
hope this helped..

Making a delay in C with 20MHz crystal(beginner level)

I've recently started with C and Im trying to figure out how to make a 10ms delay for
PIC16F884. From the formulas in the datasheet I've managed to create the following:
fosc = 20MHz and Toscx4 = 200ns
If I put a preset to 100 => t=100x200ns=20us and to get a 10 ms delay
10ms/20us = 500
Will the following code in C give me what Im looking for (10ms delay)? Assume I have all the initiating code and variables.
void interrupt ISR(void){
if(TMR0IF){
TMR0IF=0;
counter++;
}
if(counter==100){
delay++;
counter=0;
}
}
int main(void){
TMR0=155;
if(delay>4){
//any code
delay=0;
}
}
Might be a bad example but hopefully you understand
No, since the code in main() never actually waits, it won't implement a delay.
Assuming the interrupt and timer logic is properly set up, you're still going to need to loop:
delay = 0;
TMR0 = 155; /* Start timer. */
while(delay < 4)
; /* Do nothing */
/* More code here, delay has expired */
Also, remember to make delay a volatile variable since you're accessing it from multiple parallel threads of execution.
If you're a really beginner and want a tool that can help you calculate timer settings I advise you to look at this link :
http://www.mikroe.com/timer-calculator/
It generate the ccode for settiing properly a lot of different microcontroller

Resources