AVR Freaks

Behind the scenes, libc calls "nanosecond" which makes a system call and gets the current time directly from BIOS.

I'm not convinced that your linux summary is very close to correct.  While there is a nanosecond counter "somewhere", a user-level "sleep" call will usually use a much lower-resolution "system tick" timer based on a periodic interrupt.  (sleep() has a resolution of seconds, the system tick for a desktop OS is usually about 10ms.)

On the Arduino, a timer controlled by the crystal is set up to interrupt the system every 1.024ms, and then millis() is incremented by an appropriate amount, and micros() is derived from the count of clock ticks plus the contents of timer registers.

delay(n) simply loops until 1000 us has gone by n times, to give you n milliseconds.  (it USED to be based on the millis() value, which had unfortunate effects when called near the "edges" of the milliseconds ticks.  delay(1) would delay somewhere between "very short" and about 3ms.)

On Arduino, your program sits there running waiting for the count to expire.  On a desktop OS, other processes will be permitted to run while the time passes.

Be careful with your use of the term 'sleep'. In an OS context, 'sleep' means the task is not executing. In the AVR world, 'sleep' is a specific mode where the processor is suspended in order to save power.

You could run an RTOS like freeRTOS and get the functionality you expect but since the AVR is reasonably resource constrained (ie ram), a RTOS is not usually a good idea. Thus co-operative techniques are used.

For 'callbacks', there are timers and interrupts - load the timer with the required time value and configure it to interrupt when it expires.

With millis(), the idea is that you store a timestamp and then loop reading millis() until the required time has expired. As part of the loop you would perform other processing tasks. So, one thread of execution and dividing the large computing task into smaller chunks. Similar to the 'async' techniques that are popular at the moment.

On a 'full-fat' operating system, very many functions end up with a system call, which asks the kernel to do something for, or on behalf of, the requesting process. In the case of sleep(), etc it is saying 'don't bother giving me any CPU time for this number of seconds'. 

Most small microcontrollers don't run an operating system or task scheduler. There is one application (task, process) and one thread of execution, rather like the old days of MS-DOS.

Your OP linked to the Arduino SAMD core source, which is for Arm processors. That will confuse you if you're currently focusing on AVR. The link you want is: https://github.com/arduino/Ardui...

void delay(unsigned long ms)
{
	uint32_t start = micros();

	while (ms > 0) {
		yield();
		while ( ms > 0 && (micros() - start) >= 1000) {
			ms--;
			start += 1000;
		}
	}
}

Which in turn calls micros():

unsigned long micros() {
	unsigned long m;
	uint8_t oldSREG = SREG, t;
	
	cli();
	m = timer0_overflow_count;
#if defined(TCNT0)
	t = TCNT0;
#elif defined(TCNT0L)
	t = TCNT0L;
#else
	#error TIMER 0 not defined
#endif

#ifdef TIFR0
	if ((TIFR0 & _BV(TOV0)) && (t < 255))
		m++;
#else
	if ((TIFR & _BV(TOV0)) && (t < 255))
		m++;
#endif

	SREG = oldSREG;
	
	return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}

This, as you can see, uses a timer.

You've been presented a number of ways. None of which are specific to the AVR.

'Blocking' as a term doesn't make sense in this context. There is nothing else to give processor time to; no other tasks, applications or threads. We are not being 'selfish' by hogging the processor. There is no other work to be done, so it doesn't matter if the code consumes all the processor time in a tight busy-wait loop.

so the "delay" function IS blocking, it's a while loop. So you guys are saying there is another way to do this similar to "setTimeout" in javascript which is not blocking and it uses a hardware timer? 

The arduino delay() function is blocking.  The timer that drives it using non-blocking code.  (this is true of sleep() on desktops as well, although "blocking" means something different.)

Arduino's delay() looks at the time kept by the non-blocking timer service (micros())  micros() does not block.

Your link is to the SAM D core.  If you are interested in atmega code then look at this rather: https://github.com/arduino/Ardui...

Everything used by delay is present above the code, except yield(), which is an empty stub.  Towards the top there are even some brief but helpful comments.  Hopefully the bits and pieces from the rest of this discussion falls in place when you can see the actual implementation.

Edit: Apologies obdevel, I just noticed I basically repeated what you mentioned in reply #12...

If _it_ is defined as the uC then you should reconsider defining _it_ when designing software on bare metal. If you want sleeping to happen, you need to pull out the datasheet and figure out which sleep level you're targeting. You might be fine with the WDT ISR or you might want WDT always guarding and need an async timer using an external clock source. You might not care at all about the WDT at all and want to use its oscillator for the uC where it's supported. 

You're limitations aren't going to be about the APIs or OS's level of hardware abstraction. Also, this feels like an x/y question; the compiler doesn't decide if you program a function to return a value or if it will never evaluate true to a return condition; any program which you wouldn't want to return after a pre defined set of iterations doesn't "exit" at the bottom of main() like a game or a windowed program or the operating system; nongnu avr toolchain which includes avr-gcc and avr-libc does have sleep and delay functions/macros; and lastly, I'm quite ignorant so I try not to presuppose parts of an answer to something I'm asking because, regardless if I'm told part of something that I already know, 1) I tend to get the answer quicker than if I'm argumentative about what I think I know, 2) you'll likely never be regarded in a negative connotation for asking a question and listening but you will for being a know-it-all-of-wrong-things, and 3) it's the internet so everything I didn't agree with is wrong anyhow and nothing is to be remotely trusted without sources (including this post [1]AtM3llchip.datasheet [2]nongnu.tld/avr-libc [3]4chan/b)

No, the Arduino delay is just running round and round a loop until the time has elapsed.

No sleeping going on. (That yield function call is just a stub function that does nothing).

In the Arduino delay, it works out when the time has elapsed based on a hardware timer.

It is also possible to have a busy loop that just wastes time by executing nop instructions, you can work out how many instructions are needed for a given delay for a given clock frequency, no hardware timer required.

You are right to not confuse 'sleep' with 'delay' when talking about bare metal MCU without an Operating System.

What we shuold be talking about here is just delays.

I made the point earlier about 'puting into a low power mode' just as an example that if you have a case where the processor is going to be wasting time running round a loop, one option can be to put it into a low power mode, that way you can save some power whilst you are 'wasting time'. Using a low power mode in this bare metal context is more what you would think of as sleeping.

How you do that, or whether you can do that, is totally dependent on the features provided by a given processor.

For the AVR, it was already stated back in post #11 where you can read about power saving modes in the 328p datasheet (Section 9 'Power Management and Sleep Modes').

(If you do have an Operating System, when the scheduler decides that it hasn't got any tasks that need running, the scheduler might put the procesor into a low power mode at that point).

there is NO inherent link between delay and sleep.

On a microcontroller that has "sleep" low-power modes.   sleep() in a linux program and delay() in an Arduino sketch are very similar, which is what the OP was trying to compare.