 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Be careful with settick timers!
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
I just worked out what was causing a bug in my program today, and it was something of an innocent mistake, but it was preventing the rest of the code from working once the timer was set. If you have something like: SUB BEEPER Pulse PIEZO,100 Pause 100 END SUB ...and you call that with a tick-timer like this SetTick 200,BEEPER,1, when this code runs, the rest of the code never does below that line.  The problem is that as I have a timer set to run this every 200ms, and the routine takes about 200mS, so there is no time left for the rest of the code to do anything - whoops!  It's forever running that timer and can't run anything else.  Always make sure your Tick timers are setup so they are not called at the same time it takes for the sub to run - you end up in an infinite loop the the MM never gets a chance to get out of it.  That's my hair-loss moment for today.  Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Which is a good reason to set a flag in the interrupt routine and check for the flag in the main program loop. (Something I didn't do in the remote code decoder program) With the main loop something like this: Do if flag1 > 0 then dostuff1 if flag2 > 0 then dostuff2 LOOP You get to the interrupts 'eventually' and if there has been a second occurrence of the interrupt while it's waiting, there is no lockup. By increasing the flag i the interrupt routine you will know if there were multiple triggers. Timing is stuffed up but life goes on. Jim VK7JH MMedit |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003 |
SetTick calls the sub as a result of the timer interrupt going off so all good techniques used in interrupt routines should be used. i.e. keep it short and ask the main loop to do the work with a flag. PAUSE 100 in a main loop still lets the processor service other interrupts during the pause. I think a PAUSE 100 within an interrupt routine is not so friendly as I don't the processor will service other interrupts during the PAUSE 100 while still in an interrupt routine. Latest F4 Latest H7 FotS |
||||
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
@TassyJim By using a flag counter as you have suggested you can also decide what to do if you have not been able to process each interrupt separately. Depending on your needs you can process it as 'an' interrupt and clear the flag or process it as multiple interrupts if there have been more than 1. For timer related things yo might be able to 'catchup'. For data flow you need to think about using circular buffers to not loose information. You may also use a flag > 1 count it to indicate, log or alert you have lost information. @disco4now Agree, you should always try to avoid any time delays within an interrupt. Set flags and timestamps within the interrupt. Process these flags and timestamps outside the interrupt (in the main code, subroutine or function) as triggers and for timing delays needed between events. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Yes, you call all say 'I told you so.' I know not to hang around in interrupts, so why I did it this way remains a mystery to me. However, if it amuses you all as an example of what NOT to do.....  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
@Grogster Not at all. We have all been there putting something into a routine when it should not be there and later reading over your code and saying to yourself "what was I thinking". Just trying to suggest to any less experienced programmers reading TBS of less troublesome and error prone ways to get the same thing done. It does take more planning and coding initially but it generally pays off in the long term with more reliable and reusable code. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
It is my own saying: "Thau shalt not hang around in interrupts." You'd think I would follow my own commandment! Sheesh. Yes, totally agree about flags. That's really all an interrupt should do, and the main loop can act on the flag. Like I said - I knew that.......  Smoke makes things work. When the smoke gets out, it stops! |
||||
| greybeard Senior Member  Joined: 04/01/2010 Location: AustraliaPosts: 174 |
Thou shalt only be interrupted for a short while, else it would be nagging |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
