-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: add hal_jump_to_the_future_us(usec)
#756
base: master
Are you sure you want to change the base?
Conversation
including when they occur at the same of "micros()" overflow. overall cost when enabled: around 130 flash bytes on AVR
@terrillmoore if this pull request is fair for further consideration, |
@d-a-v thanks for the contribution, but this is disruptive and conflicts with how we've done this in other ports. I don't want to add an API (forever) without a lot of thought. |
I like to use the most standard and supported code I can find in supported libraries, but I haven't found low-power use-case in the examples. |
Catena Arduino Platform, and MCCI's uses in non-Arduino environments. Despite the "arduino-lmic" name, this is very important to MCCI, and possibly for others. In particular, MCCI's BSPs have a way to adjust the Arduino's answer on micros() and millis(). This allows other things to survive sleep properly, not just the LMIC, and lets us use more things unchanged. (Many things need to know about the passage of real time.) I tried pushing a change to Adafruit when we were heavily using SAMDs; they said "try upstream"; but I didn't have the time to deal with the resistance. And on non-Arduino platforms, the platform correctly keeps time through sleep. If the Arduino core team ever comes up with a portable, cross-platform API for low-power systems, then we should adopt it. But that also involves thinking hard about how to handle Anyway, panning up: there is a real cost (maintenance, test, etc) in putting things into the LMIC. Sorry I'm so conservative in this regard. (Example: I proposed #576 about a year and a half ago; it's a very simple, non-intrusive change, but it still had to wait a long time before I decided to incorporate it.) Also, there are support issues with any HAL change; it becomes another variable to consider when thinking about trouble reports, and... that's an issue, especially when timing is involved. Not saying we won't do it, but didn't feel I had time to consider this properly for v4.1. Thanks... |
When MCU is put in sleep mode,
micros()
can be not updated.A new function
hal_jump_to_the_future_us(usec)
is proposed to tell HAL that we just woke up in the future.It is not enabled by default, and is conditioned by the macro
HAL_ALLOW_FUTURE_JUMP
.edit:
micros()
overflow andfuture_usec
overflow are separately handlededit2: use case:
in
onEvent()
:in
loop()
:edit3:
It allows to avoid specific code for every underlying MCU like this one for AVR.
TBH I was looking for an equivalent hack for the SAMD21 until I thought that such feature had to be generic.