Using DelayMs with code that uses interupts

[geoff_c]

Been a while since ive done some coding. I have a control board i made up a few years ago and it works fine. I need to add a HMI to it to add some more versatility to it.

Ive used a Nextion HMI and have it communicating with my board fine now i just have to modify the program to accept the hmi data. I copied a small interupt driven routine i used years ago to read the serial data from the HMi in.

 Just remember something about using longer DelayMs commands not being good when you use a interupt in your program. Instead of just putting DelayMs 1000 is it better to put For x= 1 to 1000:delayMs 1: Next X. Im a bit rusty about exactly how the interupts functions. Thanks for your input.

[Giuseppe]

Yes to make a certain delay it is better to use a timer overflow that generates an interrupt in a time you choose. For example if you need to make a delay of 1000 mS you can set a timer overflow to 100 mS. Every time it generates an interrupt you go to increment a variable, once the variable has increased 10 times you got your delay without using the delayms that blocks the whole program

[TimB]

IMHO if you have a regular 1000ms delay in code your doing it wrong or you have really nothing to do in the code.

If your using a 1000ms delay then are you really that worried how accurate it is. Using 1000 x 1ms delays is 100% going to be non accurate as you have all the code around the delays and makes no odds in relation to the interrupts. It's still going to slow the delayms.

What is the interrupt? How often is it occurring? if its only 2-3 times a second it is not going to make much difference.

[Stephen Moss]

I could be wrong but I don't think here is much difference in that the ISR could interrupt the delay (depending on when it occurs) making it slight longer in both cases.
However, there is a big difference in the code generated in that there is more code created with the For-Next Loop, so instead of your total delay time being 1000mS + possible ISR execution time with the DelayMs command, with the For-Next loop it will be 1000mS + possible ISR execution time + For-Next execution time.

I believe that with the DelayMs command the compiler factors in the execution time when calculating the necessary number of loop iterations, you have not in your For-Next loop example, to get a delay close to 1000mS with that you would need to factor in the For-Next execution time yourself and reduce the number of loop iterations accordingly, i.e. For X = 1 to 990 instead of 1 to 1000.

Is it possible you are getting confused about not using long delays/long executing code in your ISR's? It is always good practice not to do so and keep your interrupt code as short as possible as the main code execution is halted while handling the interrupt.

[geoff_c]

Thanks guys I think what I was thinking about was putting long delays in the ISR. When i was testing the serial data transfer from the HMI i had a couple RSouts inside the ISR to look at the data and when i started sending more than 6 bytes or so i started losing data so that makes sense now.

I know its not good programming practice to use a long DelayMs when i wrote the code 3 years ago I didnt need the processor to do or check anything while the delay was running so I took the lazy way of doing it.

I understand also that doing a delay with a for next loop would not be as accurate as it does take into account the cycle times and running it a high number of times would make the error large.

About 10 years ago i got a couple great little routines from I believe you Tim to look after serial coms between 2 pics called PicPicComms and SensorUSRatCode. I used them in several projects and they work great. They had very good comments and I learned my first bit about interupts from that although not doing much coding im very rusty now. Thanks again for that Tim and thanks Giuseppe and Stephen.

So even if a DelayMs is running a delay, a interupt can run its ISR and then go back and finish the DelayMS instruction.  Sorry if thats a dumb question as i said im pretty rusty on interupts and im in Canada and its 3:20 AM and my brain is getting tired lol.

[TimB]

If your running an interrupt driven USART then in your main code you will need to check for data.

So I'm kind of with you on the for next loop.

In the end if the code works then no worries. It's not like you can tell from the outside.

I know from experience that the more complex the code then the more I need interrupt timers.I would be wrong thought to push it on others.

[Giuseppe]

If you want you can also use 2 interrupts one for the time base that generates the delays and one for receiving data