I have a process that runs every minute. I use Timer(callback,null, 60000, Timeout.infinite). On TinyCLR 1.0 it works exactly. However, on 2.0 I have to use 26000 instead of 60000. That gives me approximately 1 min. But it varies, not always right on. The RTC show 26 sec elapsed time.
first time seen it. can you please provide a bit more code so we can reproduce exactly the case?
is it any different whith debug and not debug?
No difference on any combination of build for debug or release and run with or without debug
Can your share a small piece of code to be sure?
this is a section of code in an initialization which happens a few seconds after boot:
The initial 10000 is only a wait period. (I have not timed this)
this is a section from the timer callback. note the 26000 on the timer
there is not much more after what is shown in the callback
The Stat.oneminute is a flag that the foreground UI uses to splash a large red dot on the screen. The red dot appears about at one minute intervals
@trichins just a hint, text snips of code are much more helpful than screen grabs when asking someone to repro an issue
Thread.Sleep means sleep for at least. It does not mean sleep for exactly. This is why you are seeing an apparent lapse. Every function that has that type of nature uses the same underlying mechanism.
It is not Sleep. It is Timer
Yes, please copy paste your code here
Why don’t you use this :
MonitorMinute = new Timer(MonitorMinuteCallBack, null, 10000, 60000);
instead of setting the period to Infinite and then change it in every callback ?
We just tried it, it is exactly 1 minute for every callback.
We also tried 1ms toggle led, also exactly.
Here is the code we tested, similar with you but more simple:
static int secondInTimer = 0;
static Timer monitorMinute;
static void MonitorMinuteCallBack(object data)
{
Debug.WriteLine("Fire every one minute: " + secondInTimer++);
monitorMinute.Change(60000, Timeout.Infinite);
// Scope 1 ms
//led1.Write(led1.Read() == GpioPinValue.High ? GpioPinValue.Low : GpioPinValue.High);
//monitorMinute.Change(1, Timeout.Infinite);
}
static void Test_Custom()
{
monitorMinute = new Timer(MonitorMinuteCallBack, null, 60000, Timeout.Infinite);
Thread.Sleep(-1);
}
Can you please try it or show us how to reproduce? We tried it in preview6 but I don’t think we make any change to this timer.
Just tried with 26 seconds as curious, still get callback every 26 seconds.
I tried to reproduce as well but without success either. Timer fired its event as expected.
I will be trying several things today
I inserted the above code first thing in Main(). Leaving the Sleep(-1) in, it worked correctly. When I removed the Sleep(-1), thus executing the entire program, the one minute event happened at 2 min 12 sec (132 sec).
The program does about 4-5 screen refreshes per second (multitude of drawstring, rectangles etc and a Flush). Also it processes 20-30 CAN messages per second. I wouldn’t think heavy processing would effect the Timer
1 Like
Yesterday, I had my minute timer at:
MonitorMinute.Change(40000, Timeout.Infinite);
This was giving me about 57/58 secs per event. I left the system running overnight and now the event occurs about 126 secs. I tried several things to see if I could restore it to yesterdays performance:
- hard reset
- build/deploy from Visual studio
3)power down/power up - restart Visual Studio
- Erase all, reload the firmware and build/deploy
None of these things have affected the minute event, it remains at about 126 secs.
I also have a debug LED that I flash on every 50 cycles through my code. It also has slowed down, implying:
- somewhere, a timeout is getting longer
- a Sleep is occurring
- CLR is doing more things
- processor is slowed (clock rate adjusted ???)
Any Thoughts ?
We need your help to narrow it down. Can you try a small program and see if you can reproduce the same behavior?
We see the issue and working on it.