Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
API to temporarily enable/disable FileHandles #9797
New API to permit input and/or output to be temporarily disabled on a
At present the use of
This PR allows you to do
(For this particular common case, should there be a
Pull request type
bulislaw left a comment
Looks good. I'm assuming that all other serial/uart classes are not affecting sleep in the same way (not holding a sleep lock)?
We need to document it, not only in terms of API, but also in context of sleep as it's not obvious. Maybe a note in handbook's power management section?
deepikabhavnani left a comment
Implementation looks fine, but I don't see any test case or even use case where the new functionality is implemented and verified.
API's to disable RX and TX are provided by
Is the intention to leave it completely to application developer to disable serial RTX before deep sleep? Also, it will be good to have test case to verify the new API's.
Yes, or more precisely it allows the application developer to disable serial RX so that deep sleep is possible. We can't deep sleep if serial RX is required, but there's currently no way for the application to indicate they don't need RX (other than closing/destroying the UARTSerial).
That would be nearly equivalent to having enable_input false as default - you'd still need an API to indicate that an app actually needed serial reception. An app could just manually call "deep sleep lock" to do this, but that would be an abstraction/layering error - the application shouldn't need to know the details of how a particular FileHandle interacts with power management. We do need this facility for quite specific "you can deep sleep now" reasons with serial, but the API needs to be generic.
I discussed this more over in #9676 - this is largely addressing that, although it's closed.
Indeed - I haven't quite figured out how to do this. I don't think we can easily do it in Greentea, because the debug serial is being driven by a RawSerial, and we can't just take it over. If I can slot into a cpu stats test in the Ice tea framework would be ideal. Or maybe it could be slotted into say an ESP8266 test, where we know we're running on a board with that 2nd serial port connected up.
Is this tracked anywhere?