What does it mean in practice ?
Will
DateTime.Now.Ticks
still return a valid value ? If yes what is the resolution ? (IIRC on older windows systems the resolution was 18ms)
The real time clock and the system clock are two different things.
The real-time clock is a hardware feature that will retain the time when the power is removed if a battery is used.
A DateTime is returned from the system clock.
The system clock, which is usually initialized from the real-time clock on initialization, will run the same on the Panda as the other systems.
With the Panda you will need to find a way to set the system clock to the current data/time if required. If not, the system clock will run fine, the data/time will just be wrong. Measuring elapsed time will work.
“DateTime.Now.Ticks” will return a “valid” value…
To strictly answer your question, one “Tick” is 100ns,
DateTime.Now.Ticks is the amount of Ticks elapsed since system boot up.
@ Mike that’s exactly what i wanted to know, thanks
@ Chris I mixed up ticks resolution with timer resolution. This code
Timer timer = new Timer(o => Debug.Print((DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond).ToString()), null, 0, 1);
Thread.Sleep(-1);
outputs on the NETMF emulator:
[quote]12929721854800
12929721854801
12929721854802
12929721854803
12929721854805
12929721854805
12929721854806
12929721854808[/quote]
So, it’s pretty close to the 1ms asked interval, but on windows it outputs:
[quote]63420848843297
63420848843312
63420848843328
63420848843344
63420848843359
63420848843375
63420848843390[/quote]
So on windows is called on a +/-16ms interval, not 1ms as asked
Windows has a different definition for Ticks.
The resolution of Ticks for the full and micro .NET is 100 nanoseconds per tick.
Both framework’s documentation says the DateTime ticks are from 00:00:00 January 1, 0001.
But I believe this incorrect for the micro framework. It has a later time base. I think a problem report has been submitted to Microsoft.
There is a constant that can be calculated to convert MF to full .NET DateTime.
Are you sure about that Mike? I could’ve sworn full .NET’s Tick resolution was different.
Easy way to test, though. Just have NETMF calculate the ticks from a certain date, then full .NET
Chris
Well, the documentation says 100 nanoseconds for both. But, the documentation says base date is the same, which is wrong.
Ah, I see. The epoch isn’t correct.
Yeah, I was wondering when someone would bring that up. :think: