Where to put calculations? Inside interrupt handler or main loop? (embedded realtime application)

Question

I'm developing an embedded application for motor control and I have doubts on what to to with some calculations that transform ADC numeric values into signed physical values (Amps).

Should I make the calculations in the interrupt handler or should I just use the handler to set a global flag and make the calculations in the main loop when the flag has been set?

Thank you in advance.

score 3 · Answer 1 · answered Mar 07 '12 at 22:13

3

The less work you can do in your interrupt handler, the better. Right now it might not be a big deal for your application, but there will come a time when your system load is higher and you won't want to hold off other higher-priority tasks to handle interrupts. You might want to look into semaphores and proper multithreading rather than just setting global flags.

answered Mar 07 '12 at 22:13

Carl Norum

219,201
40
422
469

Absolutely. There's not much overhead in implementing basic threading and semaphores, though, and it can *seriously* ease the programming process. – Carl Norum Mar 07 '12 at 22:29
@Carl, perhaps you could elaborate your idea of using semaphores and threading and how that makes programming easier because the way I see it since my application is already pretty complex, adapting a rtos to it at this stage seems scary. – Hungi Mahar Mar 07 '12 at 22:42
If your application is complex, it's the perfect use for a tiny real-time executive. You could have, for example, a thread that handles ADC data and is normally blocked on a semaphore. Then when your interrupt fires, you can have the interrupt handler signal that semaphore to wake up the ADC task and have it do its work. – Carl Norum Mar 07 '12 at 22:43
I agree with Carl, if your app is "pretty complex", that likely means you should have been using a lightweight OS from the beginning. You might want to look at uCOS-II (http://micrium.com/page/products/rtos/os-ii), it's free/open source, and very small and simple, but gives you basics like semaphores, timers, and task pre-emption – TJD Mar 08 '12 at 00:06
uCOS-II is not free or open source. From their web site "Micrium embedded components are priced as individual modules or as bundled solutions. Please contact Micriµm for complete pricing information for your particular requirements" – uɐɪ Mar 09 '12 at 11:01
The conditions of my project prevent me from using a RTOS (free or otherwise) or any other foreign code that wasn't written by me. Is there any way to implement RTOS concepts in a minimalistic way? – Hungi Mahar Mar 09 '12 at 20:06

score 2 · Answer 2 · answered Mar 07 '12 at 22:20

It depends on what you want to do with the ADC values, and how fast you need to do it. If you need to take some time-critical action based on the ADC values, you should deal with that in the interrupt. However, if this is the case, to save yourself the expense of first calculating the "real" analog value from the ADC counts, you should just express your critical thresholds in terms of the ADC counts.

For example, if your ADC outputs 8 counts per volt, and you need to fire an emergency stop if the ADC reports greater than 1.5 volts, you write your interrupt code to fire the E-stop at 12 counts. You could then still pass the ADC counts off to the main loop for translation into user-friendly units for user interface purposes, etc.

The general principle is that to guarantee you can meet your deadlines, you structure your application and any settings to make it as easy as possible to meet those deadlines. If something doesn't have a hard deadline, put it in the main loop (again, in general).

score 2 · Accepted Answer · answered Mar 07 '12 at 22:21

There is no one-size-fits-all answer for this. It depends upon your timing requirements, existing interrupt load, etc.

If it's a fairly simple multiply or something, then I would just do it in the interrupt and move on.

Just make sure you know what you are doing and do not spend more time in your interrupt than you should.

score 0 · Answer 4 · answered Mar 09 '12 at 08:02

One thing to think about is data consistency. If you are getting several related values from the ADC (position, voltage, current, etc..) then you may want to do something to ensure you are working with a consistent set. This may mean that a background update is better than an update in the ISR. Even consistency of a single reading for a given pass of the algorithm may be important. Consider this background code.

  delta = data-lastData;
  //ISR could update data here.
  lastData = data;
  something = K1* data + K2 * delta;  //this may be wrong now

Where to put calculations? Inside interrupt handler or main loop? (embedded realtime application)

4 Answers4