Low power?

[tve]

I'm trying to understand whether moddable is at all geared towards low power, i.e., battery operation. Searching for deep-sleep doesn't bring up a lot of hits and the docs say pretty much nothing. Is the framework just not geared towards low power operation and pretty much assumes mains power?
On the ESP32 I would expect a bunch of things to support low power, from different sleep modes (light sleep, deep sleep) to setting appropriate pin modes while sleeping, choosing different clock rates, controlling wifi sleep modes, etc.

[phoddie]

The Moddable SDK works well with battery powered products. Our clients have been extremely pleased with the battery life achieved.

Note that energy management is not limited to battery power. There are regulations in some parts of the world that require products to enter a low power mode when idle, if when connected to power. There are products built on the Moddable in distribution that do this too.

To support optimal energy management, the runtime is designed to only run when there is work to do. This allows the host to take appropriate power saving steps, such as reducing the CPU clock speed or entering light sleep. There are instruments shown in xsbug to help developers monitor for unexpected energy use, such as CPU load and turns (how often the event loop runs).

The Moddable SDK does not provide one API for energy management that works across devices. There is work for Silicon Labs parts that is separate from ESP32, for example. These features are different enough across silicon platforms, that we haven't yet found a satisfying way to provide a cross-platform energy management solution. Consequently, much of the energy management is done specific to a project. We continue to explore ideas here and welcome feedback, especially if it is based on real-world experience.

Even simple things like reducing the clock speed can have unexpected consequences. On ESP32, for example. the ESP-IDF (at last check) does not update the clocks on peripherals automatically, which causes serial and SPI rates to change with the clock speed.

[tve]

Thanks for the reply. I agree that a lot of the low-power stuff is very platform specific. I took a look at the Gecko docs (hadn't done that 'cause I've never used one) and what is missing for me is a similar section in the ESP32 docs so I don't have to reverse-engineer from source and risk missing stuff.

What I believe I've gleaned so far:

• deep sleep: deep sleep can be initiated using System.deepSleep() (?) however all deep sleep parameters (wake-up triggers) must be previously set using native code. Also any desired pin configurations during deep sleep must be set using native code.
• explicit light sleep: light sleep cannot be initiated using the SDK, it must be initiated from native code. (Any SDK-related things to watch for?)
• automatic light sleep (managed by ESP-IDF): automatic light sleep cannot be set using the SDK, it must be configured from native code. Because ESP-IDF changes the clock rate in this mode active peripherals must use REF_TICK or XTAL clock sources. What is the list of peripherals that are initialized appropriately by the SDK?
• Wifi sleep modes, e.g. "modem_sleep" are disabled by the SDK (IIRC) but can be enabled using native code (?)
• Bluetooth ... (haven't looked)

[MKGaru]

System.deepSleep was not implemented for ESP32 yet.
I write out my memo.
to implement deepSleep and wakeup timer for ESP32:

moddable/modules/io/system/system.c

Lines 25 to 39 in 74aa31c

	#include "builtinCommon.h"
	#if defined(__ets__) && !ESP32
	extern void system_deep_sleep_instant(uint32_t time_in_us);
	static void deepSleepDeliver(void *notThe, void *refcon, uint8_t *message, uint16_t messageLength)
	{
	system_deep_sleep_instant((uintptr_t)refcon);
	}
	#endif
	void xs_system_deepSleep(xsMachine *the)
	{
	#if defined(__ets__) && !ESP32
	uint32_t us = 0;

#include "builtinCommon.h"

#if ESP32

#include "esp_sleep.h"

#elif defined(__ets__)
        extern void system_deep_sleep_instant(uint32_t time_in_us);

static void deepSleepDeliver(void *notThe, void *refcon, uint8_t *message, uint16_t messageLength)
{
        system_deep_sleep_instant((uintptr_t)refcon);
}
#endif

void xs_system_deepSleep(xsMachine *the)
{
#if ESP32
        uint32_t us = 0;
        if (xsmcArgc) {
                us = xsmcToInteger(xsArg(0));
                if (us) esp_sleep_enable_timer_wakeup(us);
        }
        esp_deep_sleep_start();
#elif defined(__ets__)
        uint32_t us = 0;

but i don't understand "modMessagePostToMachine"

[phoddie]

modMessagePostToMachine is a function that the native C implementation of the Moddable SDK uses to defer function calls until the system is idle. You can think of it kind of like queueMicrotask in the JavaScript in browsers, except that it is for native code. Here it is being used to defer deep sleep until all the currently running JavaScript code returns. Strictly speaking, that isn't necessary – you could just go to sleep immediately, and we do that on other platforms. I don't recall the reason for implementing it this way for ESP8266.

As noted above, energy management is a complex topic. This API was intended as a temporary stub for some early ECMA-419 testing. The intent is to have a real set of APIs to support energy management. As noted above, that's challenging so it hasn't happened yet. If you'd like to fill this API in to be useful, that's welcome, of course.

[MKGaru]

I see, I understand the background that this function was intended for, thanks for the reply!