1
\$\begingroup\$

I have used timer interrupt in my application, mainly for timing reasons like timeout detection for processes,pulse generation etc, every 1 ms. Now i have a doubt.

Suppose in main(), if im doing another operation like, maybe writing to a SPI Flash a huge chunk of data, and the timer interrupt occurs,will the data writing process stop due to interruption by timer ISR or data be corrupted due to interruption by timer ISR? Im just wondering if whether the timer interrupt time is decided considering such operations that make up the complete application code?

If so,if a SPI flash write takes about 5ms and timer interrupt happens every 1ms, how can i keep track of timeouts,pulse generations etc without compromising of data corruption scenarios,because now ill have to change the timer interrupt to greater than 5 ms, and then i cant keep a reference of timeouts for processes where small timeouts like 1 ms may be needed.

Update

Im using a hardware timer, and when the interrupt occurs,il be using a software timer counter(variable) in the ISR,to keep track of time.

|improve this question
\$\endgroup\$
1
\$\begingroup\$

If you write the mainline code where the SPI Flash Writes take place in the proper way then the occurrence of the timer interrupt should not corrupt the operation in progress. If the main stream operation has certain timing dependancies that must be kept then it is necessary to disable the interrupts for short periods of time when the critical timing windows occur.

Another thing is to keep the code in the timer interrupt very simple and concise. Do not put any real decision code in the timer routine. Instead make yourself a collection of software managed timer variables. The timer interrupt simply checks each one of these variables and if non-zero it would simply decrement the value by one. The mainstream code would set one or more of these variables to suitable non zero values when a time period is needed. Then in the normal course of its mainline operations the timer variable can be checked to see if it has gone to zero. This can thus signal a timeout or time delay has occurred.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thats exactly how im using my ISR(just to start a increment of a variable and check the value of the variable in main()). But for timing to be consistent,the ISR must never be stopped right(in opposition to what you said)?In the scenario in my question,if i want to complete the SPI process,i have to disable timer->complete write->enable timer. \$\endgroup\$ – Akshay Immanuel D Apr 19 '16 at 9:41
  • \$\begingroup\$ I did not say that you would have to disable the timer through your whole write. What I did say was that if the code is written properly the writing will not be corrupted by the timer interrupt. I then went on to say that sometimes there may be critical narrow windows where you need to disable interrupts for a very short time. That could be for a chip timing dependency or where you need to guarantee an atomic operation on a data item that requires multiple CPU instructions to complete. \$\endgroup\$ – Michael Karas Apr 19 '16 at 10:08
  • \$\begingroup\$ As @berendi pointed out, it should be fine for the SPI situation as long as i dont mess with SPI registers from the timer ISR right? \$\endgroup\$ – Akshay Immanuel D Apr 19 '16 at 10:49
1
\$\begingroup\$

writing to a SPI Flash a huge chunk of data, and the timer interrupt occurs,will the data writing process stop due to interruption by timer ISR or data be corrupted due to interruption by timer ISR?

No way (but check the datasheet of your flash to be sure). SPI flash has no timeouts, only lower bounds on timings. You have all the time in the world to finish a write or any other operation. No data corruptiuon should occur as long as you don't touch the SPI registers from within your ISR (for beginners, later you'd do some locking).

whether the timer interrupt time is decided considering such operations that make up the complete application code?

Of course you should always take the time possibly spent in some interrupt handler into account. If you have some really time-critical task to do, you can disable interrupts for a short time, just make of the following

The sum of the maximum time spent in interrupt handlers, and in any one critical section (where interrupts are disabled) should not exceed the time between any consecutive interrupts of the same type.

That way you will still have accurate timekeeping, and won't lose any interrupts. Most (if not all) interrupt controllers are smart enough to hold an interrupt request until the CPU is able to process it, but they won't keep track of how many requests of the same type have occured without servicing.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Im using SST25VF010A. I'll check. Your saying that if my timer interrupt actually takes 500us out of 1ms(worst case), i can disable the timer interrupt for a max time less than 1ms(time before next interrupt)+remaining 500us( available from 1st interrupt), if i have to maintain timeout integrity?. \$\endgroup\$ – Akshay Immanuel D Apr 19 '16 at 10:47
  • \$\begingroup\$ No, don't disable interrupts for more than 1 ms. Suppose the worst case: timer interrupt request occurs just as you disable interrupts in the main application. Now, if you keep interrupts disabled for more than 1 ms, then a second timer irq would occur while the processor could not yet service the first one, so one interrupt is lost. \$\endgroup\$ – berendi Apr 19 '16 at 11:14
  • \$\begingroup\$ How can the second timer irq occur if i disable the interrupt? Also, how can u keep a track of "dont disable interrupts for more than 1 ms" without a timer to tell me not to exceed 1 ms?? \$\endgroup\$ – Akshay Immanuel D Apr 19 '16 at 11:21
  • \$\begingroup\$ - No interrupt occurs, a request occurs. I request you stop what you're doing, but you don't hear me, then you don't stop. - A software interrupt timer simply doesn't advance while interrupts are disabled, you cannot use that to keep track of the time spent with interrupt disabled. - If you think you must disable interrupts for more than 1 ms, then think it over, there should be some other way. One should avoid such constructs in embedded programming. Perhaps describe the exact problem in a separate question, complete with the description of your hardware. \$\endgroup\$ – berendi Apr 19 '16 at 11:54
  • \$\begingroup\$ Im using a hardware timer interrupt.Not a software interrupt. \$\endgroup\$ – Akshay Immanuel D Apr 19 '16 at 12:33
0
\$\begingroup\$

In addition to what @berendi said, you can do two things.

1) Disable interrupts, just before you do the critical data transfer. And use polling instead. Assuming you are transferring data from a buffer, send some 10(use any arbitrary number here) data frames and poll the interrupt pin. Even if the interrupt is disabled, the flag will be set, so you can approximate* the event without having to pause the data transfer.

2) Keep the interrupt enabled. Have very few instructions inside the ISR. A high speed controller will be able to accommodate very small processes between data transfer**. Since the SPI peripheral will take the load once you dump the data into the buffer, the processor will have little time in-between. It can accommodate well calculated events. Consider the interrupt entry and exit latency, and the instructions processing time.

Alternatively IF the controller supports DMA, your concern can be addressed easily.

*assuming you do it frequently enough to detect two events.

** during critical data transfers it is recommended to disable and enable interrupts.

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.