Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ESPsupport
    replied


    Please try the latest (v3.5) PmmC from here

    http://www.4dsystems.com.au/product/1/11/4D_Intelligent_Display_Modules/uLCD_43/

    If that doesn't fix the problem, try the procedure to reset the touch controller here

    http://4d.websitetoolbox.com/post/touchscreen-abnormal-delay-6240068?highlight=ar1020+reset

    Leave a comment:


  • EMHmark7
    replied


    In the Comms menu I see uLCD-43PT [v3.4]

    I suppose that is the firmware version? Because no other way to find.

    Thanks for your help.

    Marc

    Leave a comment:


  • ESPsupport
    replied


    Right, that's not correct.

    Which PmmC version are you using?

    Leave a comment:


  • EMHmark7
    replied


    I mean, the device I have, if we hold the touch without moving, we do not get status like:3333333333333333333333333333333333, but like 000000000000000000003000000000000000000000003.
    In other words, the status I get from a Pressed, is plenty of zeros with a 3 roughly every 50 to 1600 times. It is the mark of being pressed! (opposed to not touched with just 000000000000000000000000).

    What I want is I press normal time or 5 seconds, I get only one entry., unless I release and reclick.
    So, if I click a button, without programming something to take care of process speed, let's say to increase Contrast by 1, I will easily get 2,3,or 4 increases together.

    So, to avoid it, I need to know I got a release before taking care of the next pressed.
    No, I am not able to get the release message. I see it pass when I only print the status, but the code cannot catch it. My code does not depend on whatever good fit frequency. It works all the way, because it defines a released by the fact that there is no more pressed (namely some 3s appearing here and there in a bunch of zeros) Sounds weard but that is the way the device I have seems to works.

    When I tried to get the release (other than constantly printing status on the screen like a calculator tape) it didn't work. Some day I will try again and post result here.

    Leave a comment:


  • ESPsupport
    replied


    Not shure the many zeros is the intended behavior by design.
    Not sure why you keep saying this, the touch status is the status at the instant you invoke the function (other than the exception you will see below), it does not block waiting for a touch, so if you aren't touching you could get millions of zeros.

    And I still do not catch why in the demo KBMULTIFORMS, when we hold a key, it holds the action rather than re-etering a pressed. (but it used some keyboard functions I did not see the uncompiled source if available).
    Again, not sure what you are getting at, if you are still touching it is still the same 'press'(ed), I have never seen a touch keyboard that is 'typematic', if that's what you want then you will need to do it in your code. (you can do this with a timer that retriggers whilst touch is 'still' pressed or moving)

    You will always get a released after a touch, if you get a 'touched' and then you don't call status until 1/2 an hour after the touch is released, that status call will return released, hence you can do anything you like after the touch, you can't miss the release.

    Look at the supplied examples carefully and have a good play with them.

    Leave a comment:


  • EMHmark7
    replied


    One solution provided billow.

    Not shure the many zeros is the intended behavior by design.
    And I still do not catch why in the demo KBMULTIFORMS, when we hold a key, it holds the action rather than re-etering a pressed. (but it used some keyboard functions I did not see the uncompiled source if available).

    My problem started using the example in the Visi User Guide page37.
    In another demo I got the idea to use the Pressed for updating the button's look,
    but use the Released event to do an action because we cannot get 2 released!
    But we do not have time to catch up the released hit if we do some processing after button is pressed.
    So I do not know how to take advantage of the released event.

    Again, my goal is to get only one pressed event if I hold a key.

    So, unless somebody can shed light on that, here is my perfectly working solution:

    func waitPressed()
    repeat
    pressed:=0; // global var (saving time to declare)
    for (statusCount:=0; statusCount

    Leave a comment:


  • ESPsupport
    replied


    Have a look at the way the ViSi demos handle touch, check that your screen works properly with them and then look at the way they handle touch. There isn't really that much 'overhead' if you do your code right.

    even with a paper clip
    I hope you are using the 'blunt' end, the touch membrane is not tough enough to withstand that sort of treatment using the 'sharp' end for long.

    Leave a comment:


  • EMHmark7
    replied


    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.

    Leave a comment:


  • ESPsupport
    replied


    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

    Leave a comment:


  • EMHmark7
    replied


    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,

    Leave a comment:


  • ESPsupport
    replied


    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.

    Leave a comment:


  • NathanSmutz
    replied


    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.

    Leave a comment:


  • ESPsupport
    replied


    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?

    Leave a comment:


  • NathanSmutz
    replied


    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?

    Leave a comment:


  • ESPsupport
    replied


    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

    Leave a comment:

Working...
X