Main Site Documentation

T35 appears to lag system


#1

If I am running a timer to blink a led and touch and hold the screen with no controls on it, the system will really lag , my led will be very jumpy, is this normal?


#2

Welcome to the Forum.
Which Mainboard, NETMF and SDK Version are you using?
Show your code please.


#3

welcome Robbiecat07 !

simply put, that scenario is totally plausible.

Your timer is being hampered by the interrupt for the touch sensor. You may find a simple touch sensor handler with nothing in it will help (or it may not). What is it you’re trying to achieve with this test?


#4

Mainboard = Spider
SDK=4.2

Listed code below (hope I formatted it correctly), I added back the image events, they only fire once but screen still seems to be firing something to spider.

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;

using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using Microsoft.SPOT.Input;
using Gadgeteer.Modules.GHIElectronics;

namespace WPFWindowExample
{
public partial class Program
{

    bool button_pressed = false;
    private Bitmap normalButton;
    private Bitmap pressedButton;
    private Image imgButton;
    private Text txtMessage;

    void ProgramStarted()
    {
        SetupWindow();

        GT.Timer Pulse_DebugLED = new GT.Timer(100);
        Pulse_DebugLED.Tick += Pulse_DebugLED_Tick;
        Pulse_DebugLED.Start();

        Debug.Print("Program Started");
    }

    void Pulse_DebugLED_Tick(GT.Timer timer)
    {
        this.PulseDebugLED();
        
    }

    private void SetupWindow()
    {
        Font baseFont = Resources.GetFont(Resources.FontResources.NinaB);
        normalButton = Resources.GetBitmap(Resources.BitmapResources.NormalButton);
        pressedButton = Resources.GetBitmap(Resources.BitmapResources.PressedButton);

        Window window = display.WPFWindow;
        Canvas canvas = new Canvas();
        window.Child = canvas;

        imgButton = new Image(normalButton);
        imgButton.TouchDown += new TouchEventHandler(imgButton_TouchDown);
        imgButton.TouchUp += new TouchEventHandler(imgButton_TouchUp);
        canvas.Children.Add(imgButton);
        Canvas.SetTop(imgButton, 50);
        Canvas.SetLeft(imgButton, 90);

       

        txtMessage = new Text(baseFont, "Button is NOT PRESSED");
        canvas.Children.Add(txtMessage);
        Canvas.SetTop(txtMessage, 200);
        Canvas.SetLeft(txtMessage, 90);

       

    }



    void imgButton_TouchDown(object sender, TouchEventArgs e)
    {

                  
       if (button_pressed == false)
        {
           imgButton.Bitmap = pressedButton;
           txtMessage.TextContent = "Button is PRESSED";
            button_pressed = true;
        }
    
    }
    
    void imgButton_TouchUp(object sender, TouchEventArgs e)
    {
        if (button_pressed == true)
        {

            imgButton.Bitmap = normalButton;
            txtMessage.TextContent = "Button is NOT PRESSED";
            button_pressed = false;
        }

       
    }
}

}


#5

Brett,
I figured when the screen fired the touch_down event, holding my finger on screen would not interfere with system. but on my system it appears to be.


#6

Brett,
My project is a Bio-Diesel system, four temperature sensors, a circulation pump, three valves for adding catalyst and washing of fuel, I program PLC’s where I work, but have always wanted to use an embedded system with VS, but a little concerned how easy threads can get blocked, while trying to batch fuel, would I need two spiders, one for control and one for the display?

Robbie


#7

@ robbiecat07 - As I am sure you are aware, the first thing to realize is that .NETMF is not a real time OS so you will need to deal with a degree of non-determinism. Then the fact that .NETMF runs purely interpreted ie. no JIT and none of the optimizations that the 2 phase compilation offers.

Having said that, I still see possible performance improvements that you could make that might reduce the impact on your code. I do not have anything to test with right now, so I will make a few suggestions, but I cannot be certain that they will make any difference at all.

Firstly, you are not actually using threads in your code so this is not a case of threads getting blocked, but the fact that you have lots of activity on a single thread. For example, your touch events and timer events are all being queued on the same Dispatcher queue, so if there are multiple touch operations in the queue they need to be handled before the timer operations can be handled. Note I use the word operations and not events, these operations are as a result of the events, but are managed on a completely separate queue.

Two things I would try

  1. Use the timer from System.Threading for the LED flashing
  2. Start a new thread and go into a loop with a 100ms sleep, in the loop you can toggle the LED in the loop.

Also note, you should declare the timer instance outside of the ProgramStarted method, otherwise it will eventually be garbage collected.

Try option 1 first, I am certain that separating the timer from the dispatcher queue will help.

Option 1.
Use System.Threading.Timer


Pulse_DebugLED = new Timer(Pulse_DebugLED_Tick, null, 0, TimeSpan.FromTicks(100 * TimeSpan.TicksPerMillisecond));

...

private void Pulse_DebugLED_Tick(object state)
{
    PulseDebugLED();
}

Option 2.
Use a new thread to toggle the LED
Remove the timer code and in the ProgramStarted method add the following where you where creating the timer.


new Thread(() =>
    {
        while (true)
        {
            PulseDebugLED();
            Thread.Sleep(100);
        }
    }).Start();



#8

I was still wondering why you were concerned about the touch-and-hold scenario, is that something that you expect to happen (or happen a lot)?


#9

@ robbiecat07 - I just setup a quick test with my Spider and I got the same result as you did. I can also confirm that both Option 1 and Option 2 solves the problem.


#10

Yes I deal with PLC’s and they are deterministic, but very expensive, for the money these controllers seem great, once I understand it’s rules. I’ve read worst case is 20mS round robin setup if I split it into different threads, did that test and still have lag.

for instance:
If I hold a button module, I get one event, does some work, then life goes on, with this display, I press it and get an event, does some work, then I am lost, no more events, just a peculiar lag on system, not trying to beat a dead horse, but just want to understand if my display is not working correctly.


#11

@ robbiecat07 - When you say different threads, do you mean that you used your existing code and just put things in separate threads or did you use a thread to loop and toggle the LED? If all you did was introduce new threads but stilled used the Gadgeteer.Timer then you still have a bottleneck on the dispatcher queue.


#12

thanks, I will try that now


#13

I did option #2 and did it improve, but the LED would flash every 10mS, then pause for about 2 seconds, take off again, then pause.

Thanks for your help, I may end up using a small micro PLC to do my project, I might be asking a little too much of this guy, i’m afraid it will hang up and not regulate my burner, that would be bad!!! LOL


#14

@ robbiecat07 - It is a pleasure. I hope that you get to revisit this at some point and see if you can get it to work.

My system here is pretty consistent with the flashing LED, no 2 second pauses. There is a slight glitch when the initial touch is made but other than that the LED flashes consistently and has been since I wrote the test. Strange…

Have fun…


#15

cam you confirm whether this is the “press and hold” scenario or just a normal “touch” to click a button? I can’t see a normal touch being anything other than a short triggered event that you then handle, so a gap of 2 seconds when the touch isn’t being touched doesn’t make sense and could be a touch sensor connection issue. The “press and hold” scenario isn’t something I would expect to see in real life, would you? But having said that, minimising the impact is something that should be possible, and as @ Taylorza has shown that on his test, it may well point back to something with your setup/hardware…


#16

Taylor,

 That makes me real curious, the button module will create a very small delay when pressed, but fine afterwards just like you are describing, you are saying the touchscreen will do that also even if you hold it, I am convinced it is something i'm doing wrong, would it be possible to sent me your program, so I now it not an error on my part.

#17

I guess in a nut shell I want the touchscreen to react like a button, one event, no matter how long I hold it, it is perplexing me that so far everything on this project has went smooth, and my obsession to grasp this press and hold scenario, has stumped me, why would it matter how long I hold button, one event, hopefully it’s my programming or my display


#18

That is correct, that is my experience.

The thing with holding your finger to the display is that internally it is continuously generating events, you will only receive the initial touch event, but it is checking move events to handle gestures. I have not looked at the details around touch and gestures so I am no expert here.


#19

Thanks again,

I’ve scoured the web about this, I didn’t want to bring it here until I felt it was a problem, now you say it could issuing an event that i’m not looking for and choking down the dispatcher makes perfect sense, the details on this display is slightly vague, I am going to continue on with my project, but still may have a few more questions for the forum, along the way :smiley:


#20

Yes,
I made an event display.WPFWindow.Touchmove and it fires steadily, the whole time you press and hold button. (Just had to understand), I know It sounds obvious now, but not an hour ago, thanks again