Closed kelko closed 3 weeks ago
"Program" execution time isn't really a thing unless you have some way of running programs in an environment. That said, there are many possible sources of time on the NRF52833: SYST, RTC, TIMER.
I'm not sure what an officially supported method would look like. What exactly are you looking for?
"Program" execution time isn't really a thing unless you have some way of running programs in an environment.
It seems I misunderstood the method then. My understanding, based on some stackoverflow-answer (which I don’t have at hand right now) was, that it counts the ticks since start up of the controller itself. I didn’t know if it kept track of it in some own code, or whether there was a special register/… that could be read.
What exactly are you looking for?
A strictly increasing, not overflowing counter which I can use to determine the duration of “actions”/“processes”. In my case the time between one button press and the next.
In the meantime I built up own code based on the embassy time handling for nrf52833 using RTC:
Thanks for sharing a working example! There's an API that could be provided by the crate to clean this up, for sure. If you felt like working your stuff up into a PR we would happily look at it.
I looked into making a PR for the Microbit-crate. But two questions arose which I would like to clarify before continuing.
1) My code (as well as the embassy code which my version is based on) bind to RTC1. Is that OK, if the final code would be bound to one specific timer/interrupt? Or should some more generic version be tried? (although I don't fully know how to make interrupt-handling generic. Maybe via macros?)
2) I use free
and Mutex
from the cortex-m
crate. The crate is currently not listed as a a direct dependency. Would it be OK to make this dependency explicit for the crate?
It's fine to make the timing bind to an RTC. The code should be generic: can pass either RTC0 or RTC1. Use the rtc::Instance
trait to get this behavior. The usual way to handle the interrupt handler is to let the user write it and give them a callback into your code, as Display does.
I think it would be difficult to persuade folks here to add the cortex-m
crate as a dependency. Looking at your sample code, it looks offhand like PERIOD
can be AtomicU32
. The Mutex
and interrupt::free
you are using involves the interrupt handler, and thus is maybe not needed if you use the user callback trick.
You might want to check in with the Rust Embedded
Matrix and let them know what you're up to: they likely have better advice than I.
Hey @BartMassey , FYI: I started to work on that and realised that in the end I would basically just re-implement the already existing MonotonicTimer from nrf-hal. That seems like a waste of energy I would rather spend elsewhere.
So if it is OK for you I would close this issue referencing the Monotonic-Timer and my self-written example if anyone else has need for something like that.
Sounds good. Thanks for looking at this!
I currently play around with the micro:bit v2 and this crate because of the rust embedded book. Wanting to write a simple test application by myself (not just following the examples of the book) I need to count time. Not necessarily a "system time with timezone", just the distance between two instants (in seconds) is enough. I found some documentation about the micro:bit having a "running time" and there is a method in MakeCode and the MicroPython for it, as I understand it: https://makecode.microbit.org/reference/input/running-time But I couldn't find any equivalent in the rust code. Is that correct?
I have also seen the discussion about porting to "embassy", and then I could use the embassy timing features (correct?), but that might still take a while.
So: is there some way in the meantime with this crate to calculate seconds? If not, the code from embassy seems trivial enough to be re-implemented using SYST inside my app. But having an official method from the crate would be preferred 😇