Use millis() with of external interrupts

LeafLabs Garden » Support » Maple IDE Support

Use millis() with of external interrupts

(5 posts) (4 voices)

Started 2 years ago by samtal
Latest reply from gbulmer

samtal
Member
Hi all,
It is known that millis() (that is interrupt driven) can not update time when run within an interrupt handler function.
I tried to detach the interrupt within the handler, after its start, and read the millis(), but the millis does not update although the interrupt was detached.

I have also tried to have an in-between handler to run my function, but it is still the same: The millis() timer does not advance.
(Does this mean that whenever there is an active interrupt, the timer freezes?!)

I still wish I could start the function by an external interrupt!
Is this normal and is there a reasonable workaround to that?

The code looks like: (simplified)
```
void setup()
{
  attachinterrupt(enableChannel, run_cycle, RISING);
}

void run_cycle()
{
  detachInterrupt(enableChannel);
  uint16 count = 0;
  uint32 starttime = millis();
  do
  {
    uint8 nowstate = digitalRead(runChannel);
    while (digitalRead(runChannel)== nowstate) { }  //Loop until logic change
    uint16 time = (millis() - starttime) & 0xFFFF;
    count ++;
    }
   while (digitalRead(enableChannel) == 1);  

attachInterrupt(enableChannel, run_cycle, RISING);

  Select_Mode(time, count);
}
```
Posted 2 years ago #
mlundinse
Member

First of all interrupt handlers should generally be short and never have to wait for millis(). It will interfere with other things like serial and USB communications.

If you still need an interrupt handler that takes a long time, just make sure that your interrupt handler runs at lower priority (higher value in priority registers) than the priority for the SysTick handler.

This is done in the NVIC interrupt priority registers. There is a function to do this, probably found in files nvic.c/h ( I dont have the Maple lib files available right now )

Posted 2 years ago #
gbulmer
Moderator
samtal - The timers can be used to time a signal on a pin.

libmaple doesn't support that, so it would require digging through RM0008 :-(

That would require very brief interrupts, one when the values are copied from the counter, and the other to enable or disable the counter.

Edit:
samtal, I realise the code is simplified, but that code doesn't compile for me.

I've created a dummy declaration for Select_Mode.
However, when I try to compile the code, I get:
" error: 'time' was not declared in this scope"
" warning: unused variable 'time' "
" error: 'attachinterrupt' was not declared in this scope" - it should be attachInterrupt
Does this compile okay for you?

Edit2: detachInterrupt() simply stops an interrupt service routine being called in the future.
detachInterrupt() does not effect the currently running interrupt service routine, I does not effect the priority of a currently running interrupt service routine. It can't effect the ability of the the millis() interrupt to run until the current interrupt service routine has finished. So it doesn't enable the millis() interrupt to run while run_cycle() is running.

I guess the time taken to do:
```
uint8 nowstate = digitalRead(runChannel);
while (digitalRead(runChannel)== nowstate) { }
```
Is not much different from taking an interrupt.

So you might rewrite the code to throw an interrupt on every transition of enableChannel and runChannel (assuming the pins are chosen so that there are two different interrupt service routines).

count and starttime would become static variables accessible by both interrupt service routines.
The enableChannel's interrupt would either attachInterrupt or detachInterrupt for the runChannel, and when doing an attachInterrupt, it would do count=0; and starttime = millis();

The runChannel interrupt would count, and do something about the time (I can't be sure what as the code seems to have a bug).
I assume you want each runChannel duration. As I wrote above, that could be done by a timer, in which case it might not need an interrupt.
Posted 2 years ago #
vfr800nut
Member

I've got a similar problem, reading a 12 pulse encoder at 18K RPM and a 3 pulse encoder at 9KRpm with the 3rd pulse being a timing trigger point.

From what I've read,
DMA channel 1 ADC can function to print a timestamp on voltage above x(digital high), without stopping the timer(timer 1). It prints the timer 2 value. Obviously using dma the value won't be a real time interrupt but would provide the timestamp.

I haven't written any code for it, yet.
hope that helps

Posted 2 years ago #
gbulmer
Moderator

vfr800nut - "I've got a similar problem, reading a 12 pulse encoder at 18K RPM and a 3 pulse encoder at 9KRpm with the 3rd pulse being a timing trigger point."

I think you are describing a significantly harder problem than samtal's code is aiming to solve. The code is using millis() to measure pulse duration, which introduces about a 1ms error.

"DMA channel 1 ADC can function to print a timestamp on voltage above x(digital high), without stopping the timer(timer 1). It prints the timer 2 value."
That is a nifty approach in the general case.

Assuming the signals from the pulse encoders are clean, and at 3.3V level, the timers can directly time signals. (If they are quadrature encoders, then timers can be configured to count up and down using the two pulse signals.)

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.