[com2kid]

> Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods?

ooh! I worked on one.

Cooperative multithreading, you could schedule a task (callback function) to be called in 'n' hundreds of microseconds.

There was a scheduler that would drop the entire CPU to a super low power state if no tasks were scheduled to happen anytime soon (and set a HW timer to wake the CPU when more tasks were going to come due), but there was no "user land" API to sleep the entire system.

Sleeping the entire system when battery life is important (better to do as much work during each CPU wake cycle as possible, then drop back down to super low sleep for extended periods of time), and when other code needs to run, is rather rude, so we didn't allow it.

[oralty]

Nothing in the generic spec for a "sleep" function specifies you can't drop to a low power state if there is nothing to do. To varying degrees that is how sleep functions work on general purpose OSes. The CPU doesn't just spin for extended periods of time when there is nothing to do (it may spin for short waits). A "schedule a task to be called in 'n' hundreds of microseconds" is effectively a "sleep" function, the use of an explicit callback (PC) vs implicitly saving the PC of the thread is a mere implementation detail.

[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..."