Announcement

Collapse
No announcement yet.

Press and release persisting?: uLCD-43PT

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

  • Press and release persisting?: uLCD-43PT

    Hi,
    I'm using a uLCD-43PT in SGC mode, using serial commands exclusively.

    Get touch's Wait-for-press "0x6F 0x01" and wait-for-release "0x6F 0x02" modes seem to be returning a seconds-old press/release instead of waiting for a new one.

    I have a menu which issues a wait-for-press "'o'0x01 ", waits for 4 bytes then sends a wait-for-release "'o'0x02", and waits for another 4 bytes before processing any point data and passing on selection information.
    I'm currently flushing my receive buffer right before these to try to screen out any complications on my end.

    The program displays selected data for about a second, then returns to the menu.

    Here's the problem, sometimes when control returns to the menu, it doesn't wait for another press and release it just passes on the previous position data.
    As I said, I'm flushing my receive buffer and the program waits for 4bytes each after these commands, so the program must be receiving the previous touch data after the wait-for-press and wait-for-release.

    Will a wait-for-press "0x6F 0x01" command report a press event that happened before wait-for-press was issued?

    What's the logic on these? If there is a single status for press/release/move internal to the uLCD then it would have to flip between the wait-for-press and wait-for-release for this to happen.

    Very best,
    Nathan

  • #2


    I have not used SGC (only 4DGL), but what if you "Get Touch Status" until it = "No Touch" before you issue the next "Wait until touch press"?
    _______________
    Best Regards,
    Howard

    Comment


    • #3


      Which PmmC version are you using? There were some problems with earlier versions.

      If you are using touch for anything other that very simple purposes, you should be using a get status loop, otherwise it's possible that you may be losing activity between each of your calls
      Mark

      Comment


      • #4


        Sorry, wrong thread.....
        _______________
        Best Regards,
        Howard

        Comment


        • #5


          Experimenting, I poked the screen in another location during the second or so between wait-for-release commands, and it is still returning the original press location.

          This problem is also much more common with wait-for-release than wait-for-press.

          I was going to probe for touch status; but the I'm getting odd responses from touch status: 0x6F 0x04 seems to cause background color changes.

          Comment


          • #6


            Hmm, that last bit about background color changes makes me think you have gotten the command / response system out of whack somehow.

            Check that you are sending the correct commands (i.e. not an extra byte or two) and waiting for each individual response.

            That may be the problem with the 'original' release position, you are reading the response to an earlier command, not the one you just sent.

            Have you checked the PmmC version yet?
            Mark

            Comment


            • #7


              I've just loaded from the display in the DISP tool; but none of the tabs seem to show a PmmC version. In the Parameter Identification String field under the Characteristics tab, I see "uLCD-43-PRT-V01-AUS." That's the closest thing I see to any kind of firmware version ID.

              I imagine I'd do well to load the latest PmmC anyway.

              Comment


              • #8


                I'm going to load the latest PmmC, and test things out. I've checked the buffer on both sides of a wait-for-release and there's nothing waiting on the buffer before or after.

                Comment


                • #9


                  Hmm, the only PmmC files available from the product page seem to be GFX versions.

                  Is there another repository for the latest downloads?

                  Comment


                  • #10


                    I googled into one of 4D's directories and found:
                    uLCD-43PTSGC-R22.PmmC

                    Is Rev. 22 the latest stable version?

                    Comment


                    • #11


                      R22 is the latest.

                      If you page further down the products page you will come to the SGC displays. (The GFX ones are first)
                      Mark

                      Comment


                      • #12


                        I'm getting the same behavior on the new PmmC (v22).

                        I'm still checking to make sure nothing unexpected has been sent to the LCD, but my buffer checks imply that nothing is being recieved from the LCD before a wait-for-release " 'o' 0x02 " is issued.

                        As for the touch-status " 0x6F 0x04 ", I put it at the top of my main file right after initializing the LCD (reset then 3 second pause and a send of the character 'U', successful receipt of an ACK then a flush of my RX buffer for good measure). I confirmed that the buffer was clear then sent the touch-status command. I received a 0 (expected) along with more bytes on the receive buffer and multiple background color changes incident to later commands.

                        The documentation (PICASO-SGC-COMMANDS-SIS-rev9.pdf page 48) shows the touch-status command returning only one byte. If this isn't accurate, and it returns 4 bytes like the other 'o' commands then that might explain the extra data but not the weirdness with the background.

                        Are there any timing protocols that need to be observed? Is there a, maybe, minimum spacing required between bytes or whole commands?

                        Comment


                        • #13


                          It returns 4 bytes, of which only one byte is 'relevant'.

                          The timing is simply wait for the (full) response to a command before sending the next command
                          Mark

                          Comment


                          • #14


                            Thank you very much; that's very helpful. That cleared up the background changes etc. The serial example on page 48 showed a response of 02hex.

                            I show a clear buffer before issuing touch-status, and receipt of touch information on byte 2. Is this what I should be seeing? I presume this was meant as a 2-byte word.

                            Here's a new wrinkle on the wait-for-release problem: After I run a test of touch-status, and confirm an empty receive buffer, a later wait-for-release returns the position poked during the touch status test. If I comment out the touch-status test, touches previous to the first wait-for-release are not returned.

                            I would conclude that wait-for-release is occasionally accessing internal data from previous queries.

                            Any idea what might cause a wait-for-release to report a previous touch event?

                            Comment


                            • #15


                              I took your advice and rolled my own with a status loop. Seems stable if a little more sluggish.

                              Thank you again very much.

                              Comment

                              Working...
                              X