Add an option to use LowPowerTimer for poll

[amq]

Description

Similar to use-lowpower-timer-ticker in events/

This allows to use LEUART / LPUART with an ability to enter deep sleep.

For example, the cellular modem can stay constantly connected, listening for events, without preventing deep sleep.

Pull request type

• Fix
• Refactor
• New target
• Feature
• Breaking change

[kjbracey]

Why is it an option, rather than being #if DEVICE_LPTIMER, and (probably related), why might it cause you to miss events?

This is kind of a general question, as I'm seeing this pattern popping up in lots of places - do we believe the low power timer is broken on certain targets? Why don't we have a "MillisecondTimer" class that automatically directs to low power if available, else microsecond? Why does every piece of code need this ifdef/option?

This also relates to #5419 - since that we no longer need a local Timer anyway for the RTOS case, as we can use Kernel::get_ms_count. The catch is we don't have the non-RTOS equivalent discussed for there yet, and this is a potentially non-RTOS-available call.

[amq]

An option makes this change decisively non-breaking, I thought it would get merged easier this way. Happy to change to #if DEVICE_LOWPOWERTIMER (or directly to DEVICE_LPTICKER as per #6351)

My thought about losing events was that while it is highly unlikely that LowPowerTimer would affect poll directly, the fact that deep sleep won't be blocked anymore could have some side-effects.

[kjbracey]

I guess I'd like some input from those more familiar with the LP timer and power area - it just seems to me that something's not right if code keeps having to do this. I'm pushing back on the pattern - #5419 was a response to #5378 and #5328, which was the equivalent change to this for the event queues.

It would feel most natural to me that if the application needs a timer/ticker at all, it should just be specifying "high-res (us)" or "normal-res (ms)" timer. And if the platform doesn't have a separate low-power timer, then both give you the same thing.

Perhaps we could arrange for LowPowerTimer to be typedeffed or otherwise act as Timer if !DEVICE_LOWPOWERTIMER.

I've no real idea what deep sleep disables on platforms, and thus what might be implicitly relying on the Timer keeping it awake. I guess the concern is that maybe for example the serial port stops working in deep sleep, so the use of Timer is accidentally making it work? Is that possible?

[kjbracey]

I note that SerialBase::attach locks deep sleep, so if you have an interrupt handler for serial, deep sleep won't get entered. That means that if you're using UARTSerial , deep sleep won't get entered anyway.

That's what I'd expect, if it was the case that deep sleep disabled the serial port. So UARTSerial won't be relying on the Timer to keep it working.

Have you got some other FileHandle device that does work during deep sleep then?

[kjbracey]

@geky - thoughts?

[amq]

In my case, I haven't observed any issues with using LowPowerTimer in poll, I was just being cautious.

Regarding typedeffing, I would certainly appreciate it. Currently, I have #if DEVICE_LOWPOWERTIMER everywhere in my application where a timer is needed.

[0xc0170]

events have something similar:

        "use-lowpower-timer-ticker": {
            "help": "Enable use of low power timer and ticker classes. May reduce the accuracy of the event queue.",
            "value": 0
        }

these 2 are similar in functionality, should be aligned

however, lets first answer more important questions here

[amq]

I tried to align it as much as possible

Why not use-lowpower-timer? This would imply that the whole platform uses LowPowerTimer

Why not poll-use-lowpower-ticker-timer? There is no ticker here, unlike in events

[0xc0170]

@c1728p9 @bulislaw Can you review #6418 (comment) please

[amq]

Related: #5943

[geky]

I am for this in the short term.

I agree with @kjbracey-arm that this pattern is popping up too often. We should introduce a generic class that the application can switch between timer implementations.

Honestly, I think users assume the Timer class already does this. What if changed Timer to something like HighResTimer and made Timer a configurable typedef? That way users could opt-in to low-power mode without having to fuss around with user libraries.

[kjbracey]

@amq - I'm still curious what actual device this helps with. As I commented above, I believe UARTSerial will be blocking deep sleep while active, and there aren't many other FileHandles supporting poll() yet.

[amq]

@kjbracey-arm my final goal is to be able to run the cellular modem constantly, while keeping the MCU in deep sleep most of the time. From the point of view of my target (EFM32PG12) and modem (ublox Sara G3 / R4), it is possible. There are multiple changes needed to mbed-os to make this happen, and this is one of them, together with e.g. #5943

[kjbracey]

Okay, that makes sense.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1703
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6418/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1337
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6418/

[mbed-ci]

Test : FAILURE

Build number : 1497
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6418/1497

[cmonr]

Odd. Going to see if those failures are repeatable.

/morph test

[mbed-ci]

Test : SUCCESS

Build number : 1508
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6418/1508