search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

UART attach blocks deep sleep, no way to override #10059

Closed janjongboom closed 4 years ago

janjongboom commented 5 years ago

Description

I'm not sure if this is a feature, a bug, or something that should be in the documentation...

When attaching an interrupt to UART (through attach) this will always lock deep sleep. According to @0xc0170 this is because:

not every serial is capable of waking up from deep sleep, also the baudrate (higher baudrate might not be achievable running from low power clocks) might be affected thus by default it locks.

However, we don't make this distinction in code. Regardless of the baud rate or the board features we always lock deep sleep. Could we get:

  1. An overview of which features a board requires to enable deep sleep while also having an IRQ on the UART.
  2. What considerations you need to take into account when designing such a system (e.g. baud rate considerations).
  3. An option to override this behavior.

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug
janjongboom commented 5 years ago

Note that this behavior also means that any Pelion DM Client app that uses external radio over UART will not be able to go into deep sleep.

janjongboom commented 5 years ago

https://github.com/ARMmbed/mbed-os-5-docs/pull/992/files#diff-1ca88a5032642c0ab9b513a77db74c67R120 would allow this to work again but would require work in network drivers.

0xc0170 commented 5 years ago

https://github.com/ARMmbed/mbed-os-5-docs/pull/992/files#diff-1ca88a5032642c0ab9b513a77db74c67R120 would allow this to work again but would require work in network drivers.

@kjbracey-arm your latest fix for enable_input/disable should help addressing this. Is this intended to be added to esp8266 or other network drivers?

ciarmcom commented 5 years ago

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-995

kjbracey commented 5 years ago

The UART API extension in 5.12 addresses it from another direction, without any HAL respecification. Just call UARTSerial::enable_input(false), and deep sleep will be permitted, at the cost of input being disabled (it disconnects its RX handler).

But it will be up to modem/wifi/whatever drivers to do that when appropriate. They may themselves need a separate wake mechanism, like an InterruptIn.

ESP8266 will want an update, yes - it creates its UARTSerial on construction, but it should now be making it enabled only between network connect and disconnect. Then deep sleep will be locked only while the network is active - and that's the best we can do unless we have a separate wake interrupt, which I believe it doesn't. That's not currently scheduled for ESP8266, but it's an easy fix. Cellular guys will be looking at their modem drivers though.

If you did have a device where the UART was actually functional in deep sleep, then there is indeed no way of signalling that to allow us avoid the lock while keeping input functional.

However, I'm not actually aware of any such devices - the ones I've seen can only do this for LPUARTs and are limited enough to not be transparent as would be required for just idling. The wakeup time from deep sleep would be slow enough to lose characters if they just fired data at us, so it still wouldn't be appropriate to just not lock deep sleep in normal operation with Rx handler registered. We'd need an API extension - eg detaching the RX handler, but attaching a wake handler.

janjongboom commented 5 years ago

@kjbracey-arm OK, I'll go spend some time on this tomorrow for the esp8266.

janjongboom commented 5 years ago

@cmonr @bulislaw Why is this closed?

ciarmcom commented 4 years ago

Thank you for raising this issue. Please note we have updated our policies and now only defects should be raised directly in GitHub. Going forward questions and enhancements will be considered in our forums, https://forums.mbed.com/ . If this issue is still relevant please re-raise it there. This GitHub issue will now be closed.