cpu/avr8_common: Add support to threadless idle

[nandojve]

Contribution description

This attempts to introduces threadless idle support for AVR-8 platform.

Testing procedure

Local tests was conduct using timer_periodic_wakeup example on a atmega328p-xplained-mini board (m328p).

Original Code
   text	   data	    bss	    dec	    hex
   9814	    126	   1015	  10955	   2acb

With this proposal
   text	   data	    bss	    dec	    hex
   9898	    120	    823	  10841	   2a59

Triggered by #19740

[hugueslarrive]

With this proposal, it fits in the 1KB SRAM of the atmega8

[nandojve]

With this proposal, it fits in the 1KB SRAM of the atmega8

Nice! Thank you for feedback.

[riot-ci]

Murdock results

✔️ PASSED

3e207a4 cpu/avr8_common: Add support to threadless idle

Success	Failures	Total	Runtime
6934	0	6934	11m:34s

Artifacts

• Documentation preview

[maribu]

Sadly, this causes a number of regressions. See https://github.com/maribu/riot-test-results/blob/main/pr-19741/arduino-mega2560/failuresummary.md

Note: Some of the test failures are also present in master. https://github.com/maribu/riot-test-results/blob/main/master-2023-01-10-05caaafc3c68776db96afe08c2f8319d482a710c/arduino-mega2560/failuresummary.md is my most recent run of all tests on AVR on master. There might be some new regressions that were merged since, but e.g. tests/core/thread_flags does indeed work with master while it fails here.

Guessing from the shell output I think it might roughly be three causes of issues:

1. lost IRQs while idling (e.g. tests/core/thread_flags
2. entering sleep mode while a peripheral is still busy (e.g. tests/sys/sema_inv); it looks like the UART is stopped while idling and keeps sending breaks to me
3. stack overflows (e.g. tests/core/thread_flags_xtimer)

The stack overflow is quite plausible: The call to sched_arch_idle() may happen when the thread stack is already almost exhausted. Before (without call to sched_arch_idle()) it might have been just enough to still handle an IRQ (or it may not, but due to luck IRQs didn't happen exactly when the worst case situation was reached). Now, the IRQ comes in when the worst case situation + the context and return address prior to the call of sched_arch_idle() have been pushed to stack.

The issue with AVR not having a dedicated IRQ stack and IRQs victimizing the stack of whatever thread is running when the IRQ is triggered is quite a pain in the ass.

[nandojve]

Sadly, this causes a number of regressions. See https://github.com/maribu/riot-test-results/blob/main/pr-19741/arduino-mega2560/failuresummary.md

Note: Some of the test failures are also present in master. https://github.com/maribu/riot-test-results/blob/main/master-2023-01-10-05caaafc3c68776db96afe08c2f8319d482a710c/arduino-mega2560/failuresummary.md is my most recent run of all tests on AVR on master. There might be some new regressions that were merged since, but e.g. tests/core/thread_flags does indeed work with master while it fails here.

Guessing from the shell output I think it might roughly be three causes of issues:

1. lost IRQs while idling (e.g. tests/core/thread_flags
2. entering sleep mode while a peripheral is still busy (e.g. tests/sys/sema_inv); it looks like the UART is stopped while idling and keeps sending breaks to me
3. stack overflows (e.g. tests/core/thread_flags_xtimer)

The stack overflow is quite plausible: The call to sched_arch_idle() may happen when the thread stack is already almost exhausted. Before (without call to sched_arch_idle()) it might have been just enough to still handle an IRQ (or it may not, but due to luck IRQs didn't happen exactly when the worst case situation was reached). Now, the IRQ comes in when the worst case situation + the context and return address prior to the call of sched_arch_idle() have been pushed to stack.

The issue with AVR not having a dedicated IRQ stack and IRQs victimizing the stack of whatever thread is running when the IRQ is triggered is quite a pain in the ass.

I realize that is not possible merge this at current state of cpu context switch. I think it will be necessary implement the stack for ISR and maybe more. In this proposal it was necessary re-enable the global interrupt inside context switch because of wake from sleep. However. I believe this could create serious issues because there is no valid context.

For reference: This is one point that cpu call sched_run():

RIOT/cpu/avr8_common/thread_arch.c

Lines 264 to 266 in 561e193

	avr8_context_save();
	sched_run();
	avr8_context_restore();

This is the place that sched_arch_idle() is called:

RIOT/core/sched.c

Lines 158 to 160 in 561e193

	do {
	sched_arch_idle();
	} while (!runqueue_bitcache);

This proposal introduces:

void sched_arch_idle(void)
{
...
+    sei();
...}

In the case above assumption is correct I'll keep this PR on hold for the moment.

[nandojve]

I think this won't be necessary after new IRQ handling. The PM from XMega can be moved to avr_common and shared between all SoC variants, initially. Maybe a mechanism will be necessary for Mega to define what Sleep Modes will be available by SoC.