Electronic – Is disabling time sensitive interrupts in C a bad idea

cinterruptsmicrocontroller

I sometimes see code that disables interrupts, for example to perform a non-atomic read/write to a global variable used in an ISR. On AVR with gcc, this may look like:

ExpensiveOperation();
cli();
// Perform a non-atomic read/write
sei(); // Assume that it is acceptable to enable global interrupts here.

The cli and sei macros expand to asm volatile statements with memory barriers. The volatile keyword ensures that the cli/sei instructions are not optimized out, while the memory barriers ensure that if the non-atomic read/write is to a volatile variable, it will occur between the cli and sei instructions. However, this page suggests that nothing is preventing the compiler from putting ExpensiveOperation after the cli instruction.

Interrupts often require precise timing. If disabling interrupts in C risks having expensive operations run with interrupts disabled, should timing critical interrupts only be disabled in inline assembly (or should your program be rewritten to use only atomic reads/writes)?

Best Answer

Depending upon what kind of side-effects ExpensiveOperation() has, it may be illegitimate for a compiler to move it beyond a call to a function that the compiler can't "see" into if, from the compiler's point of view, there would be a possibility of such a function making use of such side-effects. It would be helpful if there were a standard function, typically implemented by an intrinsic, which would in actuality do nothing, but which a compiler would be required to treat as though it might do anything. Compilers which treated such a function as an intrinsic could avoid having to actually generate a useless "call" instruction [or any other code] for it beyond the fact required to ensure that any global variables which are cached in registers would get flushed before the "call".

Unfortunately, while calling an outside function would probably force a compiler to process ExpensiveOperation() in its entirety first, I don't know of anything that would 100% eliminate the possibility of a compiler identifying portions of that function whose execution could be deferred. Still, adding a sequenced side effect to ExpensiveOperation() and calling an outside function that would require any such side effect would need to have been completed may be the best one can hope for.

Related Solutions

Electronic – How to use interrupts in micro C

This may be a bit obvious answer, but since there are no other answers and the device is PIC16, I think that the only way to get levels is using a block of if or equivalent statements.

For example something like this:

interrupt()
{
  if(A)
    {
      handle(A);
    }
  if(B)
    {
     handle(B);
    }
}

Basically inside the interrupt function, which in mikroC has to be void interupt(void) for normal and high level interrupts and void interrupt_low (void) for low level interrupts on 18F or declared using iv keyword, you place a list ifs which check each interrupt flag in order you like. Inside the if you place the handler that handles the interrupt and clears the flag and then go on to the net flag. Unfortunately, that means that there is no easy way to implement multiple levels of interrupts.

One "hack" could be to check for interrupt flags you want to have higher priority inside of a if block of a lower priority interrupt before parts which take long time. This however leads to long and complicated interrupt service routines.

For example

interrupt()
{
  if(A)
    {
      handle(A);
    }
  if(B)//B takes a long time and several steps
    {
     init(B);
     if(A)
     {
       handle(A);
     }

     handle(B);//This takes long time
    }
}

Another way would be to move the interrupt processing from the ISR to the main loop, if you can. Make some global variables (declared outside of any functions) and use them a flags which will be set in the ISR and then processed inside the main loop. In case you have some very critical interrupts which cannot wait for the main loop to come and process them, you could make the hybrid approach. Place the handling routines for the most important interrupts in the ISR and for the rest of the interrupts use flags which will be processed in the main loop. You could even add few more "levels" of interrupts by checking flags set by the ISR for the more important interrupts several times in the main loop and for the less important interrupts only at the beginning or the end of the loop.

For example

char a,b,c;

interrupt()
{
   if(A)
        {
          handle(A);
        }
      if(B)
        {
         b=1;
         clear_B_interrupt_Flag;
        }
    }

main()
{

  while (1)
  {

   if(b)
    {
      handle(B);
      b=0;
    }
  }
}

Here's the link for the mikroElektronika's documentation for interrupts.

Electronic – arduino – Using ADC interrupts and TIMER interrupts at the same time

One thing that I notice from your code is that you are acquiring the samples in free running mode with ADC clock at F_CPU/2. According to the Atmega 328P datasheet

In Free Running mode, a new conversion will be started immediately after the conversion com- pletes, while ADSC remains high.

and the conversion time for free running mode (on table 23-1, page 255) is specified as 13 ADC clock cycles. This means that your ADC ISR is firing every 26 clock cycles with your current prescaler settings. On top of that, your TIMER1_COMPA ISR is also fired so frequently (every 64 cycles) that your ISR might actually take longer to execute than the desired time. You basically use all your time acquiring data and/or in your timer ISR. An easy solution is to increase the count in OCR1A to, say, 5 and increase the prescaler of the ADC

ADCSRA |= (1 << ADPS1); // ADC prescaler 8, conversion time 4*26 MCU cycles
OCR1A = 5; // 5*64;

If you want to squeeze every last drop of performance out of the old 328 you should inspect the generated assembly for your interrupt routines, and figure out if you can do something to optimize them. Common performance hogs are, for example, frequent data fetches from SRAM, but if you're using gcc you might find all sorts if groovy stuff happening upon ISR entry.

Keep in mind that the human eye cannot detect insanely fast flickering (hence pwm driven leds work as they do, with no visible flicker). If the slower running rate looks visually unpleasant you can of course try to reduce the prescaler and OCR1A, but you should also consider dispensing the ISR's altogether and just run your led flashing code in the main loop and have just the ADC ISR acquire data to be processed. This might work better since every function call takes at minimum 8 cycles (might have been 6, memory is a bit fuzzy on this particular detail) PLUS all the stack PUSH'n an' POP'n, which depends on your variable usage. So you could go for something like:

while(1) {
   checkData();
   handleLeds();
}

and have both functions be inlined.

Best Answer

Related Solutions

Electronic – How to use interrupts in micro C

Electronic – arduino – Using ADC interrupts and TIMER interrupts at the same time

Related Topic