Way to clear touch-buffer on uLCD-43PT?

[NathanSmutz]

Within a program loop, I periodically do a touch check: (hex command 0x6F 0x04, check for anything but 0 as a reply.)

Then I check the last touch location, to see if a button is currently pressed.

Here's the problem: I'm detecting touch activity and location (maybe release) almost a second after an actual touch event. I've been running gratuitous touch-checks before and after my actual checks in hope that that would clear past touch events from the LCD; but this hasn't been entirely successful.

Is there a command that clears the touch state on the LCD?

I'd like to do guarantee that I will only detect touch events which occurred after a specific time.

Best,
Nathan

[ESPsupport]

Assuming you have the latest PmmC the only way you will get a release is after a press and you MUST get a release after a press.

Therefore if you had a press half an hour ago and didn't touch or call it for half an hour you will get a release when you do the status call.

Otherwise you would have to 'assume' that the display is still touched and the user is getting a very sore finger.

[NathanSmutz]

So, a status check should clear everything?
Am I correct that the LCD's status goes straight to 0 after you send a status-check-command and doesn't queue up events over time or anything?

I have a button on my display that changes between day and night mode. So keeping a long press at bay is a challenge. I'll try trapping release only; but I've had bad luck doing that. In my menus I've generally had to combine a wait-for-press and wait-for-release to avoid double detection. Waiting for release by itself seemed especially prone to double detection.

[ESPsupport]

Nothing is Queued up.

It's better to check for status and not use the 'wait for' commands as it is possible for them to appear to double report.

[NathanSmutz]

I should have mentioned that I'm using my own wait functions.
Basically:
while(get_status() != whatever)
{// Do nothing
}
return location_xy()

I think I've still had better luck throwing a wait-for-press (my own) in before a wait-for-release.

Can I make sure I understand status-states correctly?

Pressed--finger-moves-->Moving--finger-lifts-->Release
Pressed--finger-lifts-->Release
Release--StatusCheck()-->NoTouch
Pressed--StatusCheck()-->Pressed
Moving---StatusCheck()-->Moving

Thanks for all the help,
Nathan

[ESPsupport]

On SGC you will get

1 "Touch Press" when the screen is touched
2 "Touch Moving" whilst the touch is in contact with the screen (and almost certainly moving)
3 "Touch Release" when the touch is released
4 "No Touch Activity" There is nothing in contact with the screen

If you have received a 1, you will always receive a 3 on a later call

[NathanSmutz]

So, if I receive a release status more than once after a single touch, I can reasonably assume that there's something wrong with my display.

[ESPsupport]

I'd think that was so unlikely, if not impossible, that I'd be checking my coms setup very carefully.

i.e. am I reading everything available, sending the correct command with no extra garbage at the end, that sort of thing

[NathanSmutz]

I'll check it out. I've checked to make sure there's nothing in the receive buffer before the check. I'll make sure I'm not sending anything weird.

One other thing, is there a calibration to prevent a stuttering effect as the finger leaves the screen?

[ESPsupport]

We have not seen a stuttering effect as the finger leaves the screen.

Which PmmC version are you using?

What are your environmental conditions like?

[NathanSmutz]

I think I fixed my problem by removing a timer-reset that was happening too soon and causing a premature status-check. I'll have to re-test my menus and see if I'm doing something else wrong there.

I believe the PmmC I'm running is: uLCD-43PTSGC-R22.PmmC
Here's what I gather from my tests:

1.It appears that the display will not show a release unless it has first returned a press event.
I ran a test delaying a second or so between status checks. A quick poke between status-checks registers nothing on the second check. (I would have thought I'd see a release status.)

2.If a finger is down on one check, up, then down again by the next check, status returns "moving."

So, for periodic touch checks, a finger must be down at the very moment of a status check or nothing will be done. Trapping for release means action won't be taken until the next check. So trapping for press is best if your delay between status-checks is long enough to remove a finger; however, repeated presses will be dodgy unless you also check for movement.
Measures must be taken to strip any latent releases before switching to anything that polls for release.

For continuous checks: trapping for release is probably best, leaving no artifacts to cleanup.

[ESPsupport]

Correct, the status is current at the time you do the call (with the exception of Touch Release as described below).

If you need to know more current status, you need to poll more regularly.

You can't queue or otherwise buffer touch activity, think about it, it wouldn't work if you did that.

[EMHmark7]

What is the logic behind touch_Get(status) function?

Programming on mLCD-43PT.

Doing touch_Get(status) within a repeat forever and display the value,
I see that even if I hold the finger on, it cycles through different values (So fast I cannot read).

So, I understand that it will constantly generate some move and release even if I hold on.

Anybody can give details about that function?

My goal is to get actions triggered only once when I hit and hold a "button".
So, I need to test the holds and releases. But seems more complicated because of that function logic.

Thanks,

[ESPsupport]

You haven't said what platform you are using, as several of the simpler ViSi and/or Designer samples show the 'framework'.

Generally it's

NOTOUCH (no touch)

TOUCH_PRESSED (initial press)
TOUCH_MOVING (0 or more possible)
NOTOUCH (if absolutely no movement, almost impossible in practise)
TOUCH_RELEASED(touch released)

This assumes you have the latest PmmC.

Also, try some of the samples to satisfy yourself that it is working correctly

[EMHmark7]

I do not know how to know the actual firmware version.
Working on Workshop4 Windows Visi.


From my experience, constantly printing the touchStatus it appears that if I click and hold pressure without moving, I get a train of 0000000000000000000000 with a 3 appearing every 85 reads (a variable frequency).
So, to get consistant 'pressed/unpressed' values (in other words, not to see a false release) I need to read 1600 times the status, do the sum and test if it is non zero or zero.

The idea is I need to catch the 3s so I know I am holding the pad.

1600 times needed, because is if I hold for let's say 3 minutes, there is a recuring probability that I need to wait for a long time for getting a 3. This long occurence of "zeros only" can happen anytime, so it can be after I pressed the pad.

This is taking lots of CPU. Fine now, but when I will add more areas to test, response will get slow.

So, bottom of the line, most of the time I hold the touch pad, it gives zero as the status!

Maybe this CPU intensive long procedure or the way touchscreen behave has something to do with a problem I have:
Even if well calibrated, the bottom left area of 50x50 does not respond well to touch (even with a paper clip) most of the time I need to click 3-4 times in order to get a response.

Further testings show: I get a constant 3 if mouving, and a 2 if releasing.