Timer vs Thread

I have been comparing code in many NetMF samples and I have found 2 approaches for persistently reading values from sensors, e.g.


public int PollingInterval { get; set; }
protected GT.Timer PollingTimer;

protected Sensor()
{
    PollingTimer = new GT.Timer(PollingInterval, GT.Timer.BehaviorType.RunContinuously);
    PollingTimer.Tick += PollingTimer_Tick;

    PollingTimer.Start();
}

protected void PollingTimer_Tick(GT.Timer timer)
{
    //read sensor value here!
}


or


public int PollingInterval { get; set; }

protected Sensor()
{
   var t = new Thread(PollSensor);
   t.Start();
}

protected void PollingSensor()
{
   do
   {
       //read sensor value here!

       Thread.Sleep(PollingInterval);
    }
    while (true);
}


Which approach is most appropriate/accurate and are there any advantages / disadvantages to each approach?

All GT.Timers raise their events on the same “UI” thread, so, if you have lots of them, they stack up and get delayed. Thread is a low level construct with A LOT less overhead.

I’d go with Threads.

1 Like

Thanks for your reply.

In that case, I wonder why many of the GHI module drivers use GT.Timer instead of threads?!

It’s the same if you use Threading.Timer.
All Timer Events, along with others, share one single thread.

It is really up to you. Also, timers can be more better because the delay offset does not build up in every loop like in threads.

My gues is: Most of them are written “quick and dirty”.
This does not mean that they don’t work, but I would not rely on any single aspext of them.
Gadgateer was designed for rapid prototyping, and not so much fur a final product.

The Offsets can be easily compensated by taking the time at the beginning of the Loop and calculate the needed delay at the end.
Or even better:
Take the time before the Loop, and add up the Intervall at each Iteration. Then caclulate the needed delay based on that. Woks great, I use this Approach for cyclic CAN bus Messages.

1 Like

@ Reinhard Ostermeier - or just use timers :slight_smile: Back to what I was saying…it is up to you and your application.

@ Gus - You are right, my implementation might be similar to how the NETMF timers work.
But I like to have dedicated threads for specific Long running Actions.
And my own thread gives me more control, like Setting the thread priority.
I think I should implement my own thread based timer class, where you can create as many new threads as I want and add timers to them.
I would put all the nice Features in it like spawning in timer thread, spawn a new thread, use my ThreaPool to run Event, …

I’ve been assuming that the timers, NETMF or Gadgeteer use the hardware timers built into the processor. Is that correct?

@ Gene - Nope. As far as I remember, NETMF only uses one hardware timer.

.NETMF PAL (Platform Abstraction Layer) provides an abstraction of the timer ie. a timer driver, this abstraction drives all asynchronous calls in the framework including .NETMF timers. .NETMF timers are added to a queue and then scheduled to run the callback routine by the timer driver at (or close to) the required time.

That is an implementation detail. For example, the .NETMF timer driver implementation for the STM32 actually chains 2 hardware timers, one 32bit timer and a 16bit timer to create a 48bit timer which is the bases of the .NETMF timer driver.

Thanks for correcting my mis-understanding

@ taylorza - Any chance you’ll be relocating to the beautiful Monterey Bay area any time soon :)?

Not anytime soon, but you never know where life takes you…

1 Like