Using interrupt for 10 seconds

[stephenmccarthy]

Hi lads,
I've attached my code and hope i can get some quick help with the following problem. In my code I am using two interupts the first to call the int_counter macro which is set to make 150 counts the second to call the input_rb0 maco. I am using a 12MHz crystal. My problem is i do not know how to set the frequencies in the interupt to give me 10 seconds between updating the values on the LCD. I need to set it to 10seconds as the value read into rb0 while the count is taking place will be multiplied by 6 to give the beats per minute(BPM) so 10seconds*6=BPM. The whole code is based around a bluetooth heart rate monitor and everything else is working great. Can anybody help me with his please?

Thanks
Stephen

[Benj]

Hello Stephen,

I would do it like this,

You have your timer interrupt interrupting 150 times a second so what you could do is in your main check to see if the count variable is 0. If it is then you know one second has passed. If you allow your interrupt count to count up to 1500 using an INT variable then you can check to see in the count variable is 0 in main and this will give you a ten second tick in which to process your heart rate counter.

[stephenmccarthy]

Hi, ben and thanks for your reply i do not think i can let the count variable count as far as 1500 because the pre scaller on the interrupt is 1:256 so anything over 255 and the count seem to time out and not show data on the lcd? Am i correct in thinking this? I am just thinking now that if i made the count = 255 this should give me 5 seconds and if i multiply the heart beat value by 12 rather then 6 that could gave me an accurate BPM do you think this would work?

Thanks again
Stephen

[Benj]

Hello,

The prescaler on the interrupt is simply a scaler on how fast the interrupt timer count register counts.

Clock frequency / 4 / prescaler / 256 = interrupt frequency

Your Flowcode count variable is different from the interrupt timer count variable and is counting the number of interruptions.

When setting up the timer in Flowcode you are given an output frequency from the timer. Eg for a interrupt rate of 150Hz you would have to count up the 150 separate interrupts to delay for 1 second.

Multiplying a value can lead to problems as you are always in the multiples of 6 or 12 range. To allow for a truly flexible count I would allow the count to either run for the whole minute before refreshing or to create some kind of a rolling average so that you can display the count more frequently without loosing precision.

[stephenmccarthy]

Hello Ben,
Thanks for clearing that up for me, and yes you are corrct about multiplying values as this is also an issue with my code, how ever the count will not let me count higher then 255 in an if statement and with an interupt frequency of 45.776Hz, I am not sure how to get around this issue?

Thanks
Stephen

[Spanish_dude]

Hi,

Are you using an integer variable for your counter ?

[stephenmccarthy]

Hi,

Yes I had the count variable set to a byte, stupuidly i just realised this wont count passed 255 so i changed it to an interger. I think I have been looking at this code too long. A can now get a long enought interupt to allow me to multiply my variable by 6 to get an average BPM. the only problem is when i try to rset the Heart_beat value back to 0 and test it in my circuit the lcd goes crazy and constantly changes from 0 to sumthing else back to 0. Without reseting the heart_beat back to 0 on my circuit the LCD will print the heart rate but then when it updates the heart_rate it will add it to the value of the previous heart_rate. I know this is what you mean by messing with calculations ben.
Any ideas on how to overcome this.

Thanks
Stephen

[Benj]

Hello Stephen,

Could it be that the display is updating several times while the interrupt count = 0. If so then you could add a second variable that is cleared when interrupt count = 0 and then set after you have updated the LCD. If you then test the variable before updating the LCD then the LCD should only be updated once with the correct reading.

[stephenmccarthy]

Hello Ben, yes that seems to be the case, for example i place my finger between the sensor and it can go from 64 to 130 to 250 and when i remove my finger the value will return to 0. As for your solution, do you recommend i use the new variable too actually display the BPM on the display?

Thanks again,
Stephen

[medelec35]

Hi Stephen,
I don't believe this is going to work.
Reason is you have a call Call Heart_Beat_Calc macro within your timer interrupt, then within the Call Heart_Beat_Calc macro your are calling a Display value macro which contains LCD functions (that will have delays built in).

Also the timing will be bit out because of timer interrupt frequency is 45.776Hz. So that means every second the timer interrupt is accessed 45.776 times = 457.76 in 10 seconds.
= 457 time as number of times can only be a whole number. This may affect the accuracy of results.

When I get a chance I will see if I can alter your Flowchart for you.
I have not looked at the datasheet yet for your chip, but what about using the pll function, or you can change xtal value to give more accurate interrupt values.
E.g with 19660800MHz xtal , you can get interrupt of exactly 75.00Hz, 150.00Hz etc.

Martin

[stephenmccarthy]

Hello martin
Thanks for your reply, if i called "heart_beat_calc" and "display_value" from outside the loop in the main program do you think this would help? Also yes i understand what you mean about the timing being off, unfortunately at the time of designing my code i only had an option of 12Mhz, I have moved the project from eblocks and and push buttons too my own sensor and PCB, so i find my self stuck with the components ive used. I just checked my sensor on an oscilloscope and it seems to be working correct so the problem definitly seems to be in my code. I know i still need to reset "heart_beat" value back to zero in my code for the next count of ten seconds but whenever I do this it has an unwanted efffect on my lcd in the real world.

Thanks
Stephen

[medelec35]

if i called "heart_beat_calc" and "display_value" from outside the loop in the main program do you think this would help?

Yes definitely will help.
What you are finding now, is corruption is occurring.
You must never place any macro calls or component macros that also incorporate a delay or any delays within a interrupt.
Since you have put a call macro that has several write to LCD within timer macro that will cause your LCD display problems.
What I do is:
As soon as a set time has elapsed, set a flag called Update to 1.
In the main routine. If update is = 0 then LCD Display Macro is not accessed.
When update is = 1 then LCD Display Macro is accessed, and update is reset to 0, so it waits for the next set time to elapse.

When you compile to hex or compile to chip, look out for:

Code: Select all

Building CASM file
Serious Warning: Possible sw stack corruption, function 'FCM_Int_counter' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCM_Input_RB0' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

As for the timing I will look into that more tonight when get more time.

[stephenmccarthy]

I am just going to look at my code again and try make the appropiate changes and impliment the check for update in to it. I'll keep a look out for the wrning you told me to watch for too and let you know how it goes.

Thanks
Stephen

[medelec35]

Hi Stephen.
I don't think it will work as well using INT0
If my theory is correct (and I could be wrong of course ) INT0 takes priority over timer0 therefore timer0 will temporary halt, thereby inducing timing errors.
So I have changed INT0 to PortB IOC. This means i/p is now on RB4. Maybe you could try with INT0 (B0) and IOC (B4) and see if there is any difference?
I have also changed your routine to count in 1 second intervals, then used if seconds >=10 then update =1.
Reason for using seconds is
1) makes it easer to follow.
2) You can use seconds function for other timing routines.

I have also added a * that can be briefly seen when change on port is detected.

The tmr0l += 43; just sets timer0 to 43 instead of staring at 0. So timer goes from 43 to 255, then rolls over trigging the interrupt routine.
This is just to fine tune timer so when count reaches 54, exactly 1 second has elapsed. ( well that's the theory )
At least this is a starting point for you

Martin

[stephenmccarthy]

Hello martin
And thanks for going through the trouble of altering the code, im going to download it to my development board shortly, Ive also made a few changes to my original code now I am using timer1 and i have taken out the loop and calling the two macros from with in it completely. Also i decrement the count rather then increment it and this seems to work for giving me a ten second update. I tested this by putting a pulse on RB1 and checking for it on an oscilloscope. i found one pulse every 10ms. So now the micro seems to behave correctly on my pcb. So i used the oscilloscope to check my pulses coming in from my sensor. And the signal seems very distorted compared to how it looks on breadboards. So really i need to correct this before i can make sure the code is correct I will post myown updated code so you can view it too

Thanks
Stephen

[medelec35]

Hi Stephen,
It looks like the last file you posted is the same as your original.

Re: timer2
Yes that can be used, but Flowcode is unable to simulate timer1 or timer2 so interrupt macro will never be accessed. It will work fine on your hardware.
Here is the timer2 version, so you can see how I have set the values to.

Martin

[stephenmccarthy]

Hello Martin,
Sorry i must have posted the wrong code, i've kept different version of the same code as it evolved, sorry about that. I also tested timer1 on my own circuit board and it appears ok. I am however using a twelve meg crystal and Ive just realised i may have soldered it too close to the board. The board is copper and the tracks are routed. I think this might be causing a bad signal, so I will resolder it when i get a chance over the weekend and try both our codes hopefully with some positive results

Thanks
Stephen