RTC runs in real time, not simulated time

[alto777]

This offhand remark

Rather strange that the Serial.print for the RTC actually matches real time though

was in the context of talking about when the simulation can't keep up. I said it may be slow, but it will do the same things eventually, but it does seem that the RTC cranks away full speed.

Here's a simulation; I borrowed a project that will make my tablet go down to 50 percent real time:

RTC beats simulated passage of time!

The RTC and any other parts that talk about real time (timeout in the PIR detector, e.g.) should rightly derive their base timing from the simulation master time keeping mechanism, not the real clock time.

I expect this would hapen on any platform, I have use macOS (runs fine at 100 percent, nothing to see here) and iPadOS?? of some late version.

I couldn't right away think of why that RTC flaw would matter, I am sure given time I could. But then I remembered the time-out in the PIR. I have not the time to look into that just now, but I think that any use of "real time" should respect the simulation concept of time as a matter of fidelity and also as a thing we would just expect.

I was incredulous and defensive, then got empirical.

a7

[sutaburosu]

I like the current behaviour of the simulated RTC, but I can see how it may cause problems for sketches which use both RTC and millis(). If this behaviour changes, I would like to see an attr on the RTC part to choose sim time or real time.

[alto777]

I have to wonder why you would like the RTC time to zoom ahead of a simulation that was running slower than real time because of its complexity or whatever slows it down when it does.

For example, if the RTC was being used to see how long something took to compute, it would provide meaningless information.

a7