millis() interfere with Task Scheduler?

[SamuelWilson10]

Does using millis() function inside a callable block interfere with the task scheduler? I'm using an RF library which checks for timeouts using the millis() function, and I noticed that the scheduler hangs.

[feilipu]

The use of any function that disables interrupts globally will prevent the scheduler from triggering. Unfortunately millis() is just one of those functions.

Normally it wouldn't be a problem, as the time where the global interrupt is disabled is very short, but if millis() is called from within a tight loop, then the scheduler WDT interrupt (and all other interrupts, by the way) will be lost.

Unless there are very tight timing requirements, that would normally be supported by a hardware timer, it is better to use the FreeRTOS API delay functions to block tasks. This enables you to put the MCU to sleep in the idle Task when all productive Tasks are blocked waiting for a timer to expire (and therefore the idle Task can run).

unsigned long millis()
{
	unsigned long m;
	uint8_t oldSREG = SREG;

	// disable interrupts while we read timer0_millis or we might get an
	// inconsistent value (e.g. in the middle of a write to timer0_millis)
	cli();
	m = timer0_millis;
	SREG = oldSREG;

	return m;
}

[SamuelWilson10]

That was exactly the problem, thank you.

[feilipu]

Good luck.

[Floessie]

@feilipu

Normally it wouldn't be a problem, as the time where the global interrupt is disabled is very short, but if millis() is called from within a tight loop, then the scheduler WDT interrupt (and all other interrupts, by the way) will be lost.

That sounds contrary to the datasheet. Quoting from ATMega328/P page 32:

If an interrupt condition occurs while the corresponding interrupt enable bit is cleared, the Interrupt Flag will be set and remembered until the interrupt is enabled, or the flag is cleared by software. Similarly, if one or more interrupt conditions occur while the Global Interrupt Enable bit is cleared, the corresponding Interrupt Flag(s) will be set and remembered until the Global Interrupt Enable bit is set, and will then be executed by order of priority.

The WDT interrupt has priority 7 whereas Timer 0 has 15-17. Wouldn't that mean, that even in a tight loop the WDT interrupt would be remembered and executed as soon as SREG is reloaded with its previous value? 😕

Best,
Flössie

[feilipu]

Yes, generally, there would be a hang for as long as the global interrupt is disabled. Since the usage of millis() is typically for a few hundred milli-seconds (i.e. a tight loop for non "tight" delays), this interferes with timing and will hang the scheduler, as several timeouts will potentially have happened, and they can't be queued up. Only the last interrupt will be recognised.

I've also noticed the same effect with other Arduino code that disables the global interrupt for long periods, like software serial.

Far better to use the FreeRTOS based timers to manage delays, or in the worst case the delay() function.

[Floessie]

Aha, so the problem was more like:

cli();
while (millis() < 50);
doSomething();
sei();

Thus it's absolutely fine to use millis() for let's say state machine timeouts while interrupts are enabled.

Thanks for the explanation! Much appreciated (and I'm less confused now). 👍

Far better to use the FreeRTOS based timers to manage delays, or in the worst case the delay() function.

Of course, but you only get 15ms slices with the WDT. Maybe worth to mention: When dealing with clock cycles __builtin_avr_nops() looks handy.

Thanks, Phillip!

Best,
Flössie

[feilipu]

Reading the arduino/arduino it is clear that millis() needs to have the global interrupt enabled, or it itself will not work.

Actually, the problem is not inherent in millis().
So what I stated above was not a correct explanation for the issue found. But, still the issue was resolved, so there must be some impact.

Of course, but you only get 15ms slices with the WDT.

Normally, I use the Timer0 or Timer2 for up to 1ms accuracy. Just that Arduino configures all the hardware Timers itself, so they can't be reconfigured by a library without errors.