[com2kid]

It served a similar purpose, if no one else scheduled anything anytime soon.

The schedule task function in this particular embedded OS actually didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout!

Timer coalescing and all that.

Irritated the heck out of the traditional embedded engineers when they first got introduced to it though. "I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?"

Not allowed! Plenty of old school engineers are used to just spinning the CPU while waiting for something to happen!

[oralty]

> didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout!

This is the contract for sleep on just about every general purpose OS preemptive or cooperative, and what would be assumed in the original article.

> I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?"

I mean now we're just conflating so many things. What you describe here is the essence of a hard real-time OS. It's quite orthogonal to the issue of ensuring low power. Since there are plenty of systems that require both.

> Plenty of old school engineers I can assure you there are plenty of old school engineers that can get an MCU to run for months on a couple AA batteries. They're not spinning a 20MHz CPU in a busy-loop most of the time.

[com2kid]

> I can assure you there are plenty of old school engineers that can get an MCU to run for months on a couple AA batteries. They're not spinning a 20MHz CPU in a busy-loop most of the time.

Oh sure, the good ones aren't, but I've met more than one who thinks spinning is A-OK, especially if they haven't done battery powered stuff before!

As an example, we had a heck of a time finding a non-blocking power loss resistant file system. Ending up having to write our own. (Not an easy choice, a lot of vendors were talked to) We went to the traditional embedded file vendors at the time (hopefully things have changed) and across the board asking for a (NOR) Flash file system that could handle sudden power loss, but without the file system needing any blocking, was met with stares of "why would you want that?"

Of course a lot of embedded works uses interrupts, but on more than one occasion we encountered bugs when doing things "the correct way" and comments from our suppliers that were basically summed up as "well if you weren't so insistent on everything being async..."