I have a question: Is there some sort of background thread/timer or something running in the firmware that causes a blocking/delay approx. every 5 seconds? I have now done a lot of testing to make sure that this was not caused by me. I made a fresh start, erased everything and made a new tiny project containing only the following lines of code:
private static DateTime now;
private static DateTime last = DateTime.Now;
public static void Main()
{
while (true)
{
now = DateTime.Now;
TimeSpan time = (now - last);//calculate the time between now and the last run
last = DateTime.Now;
Debug.Print(now.ToString() + " - " + time.Milliseconds);
}
}
The code will do a debug.print of the time differences of each run in a loop. In my setup the debug.write (which I know is slow) takes about 13-14 ms. to complete, but at about every 5 seconds the processing takes exactly 100 ms extra to complete. Below is a small dump of the output:
What could be causing this?
It’s to precise to be cause by the GC and that would also cause debug info to be written to the output window…as far as I know. I also testet this using thread.sleep and added the times to a list without doing debug.prints and it’s the same result: a 100 ms. delay.
This is a real problem for me. Because I need to count pulses and close a valve on a pump and a 100 ms. delay really messes this up.
I realise it’s not a realtime system, and small variations can happen, but this is just to much of a variation.
I have also experienced this behavior. In my case I was using PWM output to fade LED in and out. I noticed that every few seconds the LED is not fading smoothly (hangs) for a small period of time. Tricon Data test however is more accurate. I am not using Ethernet connection.
Hi,
I did not even start with micro.NET, but even than I think I know source of your problem:
Debug.Print(now.ToString() + " - " + time.Milliseconds);
You are creating several objects of type String in each cycle. Framework has to sweep away them from time to time. I expect your delay is simply garbage collector.
Quick easy way to test the GC for sure is to force collection at the end of each loop. If that stabilizes things you know where your problem lies. Also check that ethernet cable suggestion.
@ Gus
My thouhgts exactly. I suspect that it’s a result of the EthernetOscillator too (at least thats what I think you are thinking ;D), but I haven’t been able to turn if off. Using the following method freezes the entire module:
Anyway your trick works: as soon as I plug in an ehternet cable the delay disappears.
So how do I turn it off without a cable (that would result in very long cables for this project)?
@ m-land
Believe me I have done several test as I mention in my post using different approaches and its always 5 seconds. And the GC would never run in such precise intervals (every 5 seconds). But thanks for your suggestion, nice that people try to help ;D
@ Tricon Data
OK, I belive you I did not catch in your initial post that it is 5 seconds with every program, not only with this particular one - sorry. Because for such program like your example there is perfect reason for framework to run GC in regular intervals (this program does still the same - and allocates still amount of memory to do so - so GC will run in precise intervals)
This is great news to me too. Two weeks ago I was trying to pick the best host PC interface for my datalogger app and was chosing between WiFi and Ethernet (on EXM dev board). With WiFi I was getting these same weird delays every five seconds and with Ethernet everything was fine. Of course I was blaming my WiFi infrastructure and ZG2100 for all this… Turns out this was a bug in Ethernet
Just found this post. Does this problem was related to the EthernetOscillator or not? because in the last release, disabling the Oscillator still goes on to freeze the board.
