No announcement yet.

RX/TX order internal to uLCD

  • Filter
  • Time
  • Show
Clear All
new posts

  • RX/TX order internal to uLCD

    How does the uLCD handle rx/tx order? If a user touches the screen during a command that has not been replied to, which scenario applies?

    a) a screen touch is queued until the command is completed like this:

    [PC: command]--------- [uLCD: ACK] [uLCD: screen touch]


    b) a screen touch is sent immediately followed by the ACK from the previous command like this:

    [PC: command] ---- [uLCD: screen touch] ----- [uLCD: ACK]

    I'm assuming other events and request for data would be handled in one of these ways to but I'd like to be clear on which method is used in the system. Programatically at the PC end I could probably test for both scenarios.


  • #2
    The display will not 'mix up' the command an responses as it 'strictly' will send the ACK before the screen touch.

    However, that doesn't mean it can't 'appear' to happen. Since the coms link is full duplex and buffered you could be 'still sending' the command when the display starts sending the 'screen touch'. This will then appear to you as the b case.


    • #3
      Hi Mark, Then scenario a or b applies in effect, which means that if I'm sending a command and then waiting for an ACK, the response could be a touch event. Would it not be better for the display to buffer a touch event if it detects incoming data and wait until the ACK has been sent, and then send the tofu event. Then again I suppose after I send a command wait for either an ACK or otherwise.


      • #4
        Even if it was buffered there would be no guarantee that when received it wont be 'mixed up' (eg a high latency / wifi system will easily suffer from this).

        Really, when you are looking for an ACK, if you get something else (eg a touch), you just need to 'push' it into a 'receive' stack. The 'polling' routine then pops the anything that is stacked before checking comms.