after a long time testing out things with NETMF timers, i came to the conclusion that the issue described in the old Timer-issue thread is still ongoing.
For example:
I’ve created a timer from a GUI-based thread that updates a Text containing the current time every second.
After a varying time the timer stops, without any resource connected to it being released or anything else. It just stops calling the periodic-callback.
Second example:
I’ve created a timer that calls a callback every 15 seconds and within communicates with a bluetooth module over UART. The timer spawns from the main thread. Same as above - stops working due to no noticeable reason.
My NETMF Version is the last version that has been released.
The alternative would be Threads with Sleeps but i experienced heavier CPU-load, which leads to glitchy behaviour.
Have you ever tried creating a Timer from within a GUI-based thread ?
So what i mean is creating a timer like this:
Application.Current.MainWindow.Dispatcher.BeginInvoke(o =>
{
new Timer((timerParam) => { /*stuff*/ }, null, TimeSpan.Zero, new TimeSpan(0, 0, 0, 5));
return null;
}, null);
This does happen when for example a worker thread from a random non-GUI module creates a WindowLayer-derivate which creates timers in its constructor. An UIElements constructor has to be called context-safe - so as described above.
I think that a timer created this way has not the same lifespan as the same timer created from a non-GUI thread.
If you have a main loop just compare time there. I have some timers like this where once every 100ms and once every 1000ms I call functions from the main loop. No sleep required.
Sadly not…
I might try something like a timer manager, where you can request timer-spawning and timer-disposing and so all timers would be created from a fix-thread. Additionally i finally get a use case for the object which can be passed through the timer-delegate .
In embedded systems it is not a good practice to do a lot of creating and disposing of resources. Have to be creative in your design. Use one timer and a queue of requests.
I know what you mean but our software is quite "bloaty"and relies on these “high-level-language” /framework standarts - especially when your first developement experience is the “real” dotNet…
Approx. 10K lines of code and many modules - worker threads, timers etc. Lots of serial communications and GUI stuff. Thats why we decided to go with the G400 and NETMF.
Although everything runs quite fine, some parts have to be more failproof and this is our current problem. In such a “big” embedded system, sideeffects have a huge impact on user-experience and its really hard to figure out the root of the problem.
What i was trying to say is that you’re completely right in what you said concerning resource management on embedded devices BUT due to our big software and our little time we have left (1,5 weeks until CE test and 3 more days until the first devices will leave the stock) such a big change wouldn’t be possible so i have to look for workarounds. Thank you for your engagement - i will now try to solve the problem with a timer manager. If this won’t work i will come back
.