No announcement yet.

No response to NAK?

  • Filter
  • Time
  • Show
Clear All
new posts

  • No response to NAK?

    Hi, I am using a gen4-uLCD-24DT display programmed with Visi Genie, connected to a host processor. I want the host processor to start sending data to the display when a winbutton on the display is pressed. In order to send the correct data, the host must know which button is pressed.
    To accomplish this, the 'event handler' is set to 'report event'. Every time the button is pressed, a message of 6 ascii characters is sent.
    So far, so good.

    Since the host is very busy and it can't use an interrupt, the processor has to poll the UART of the host for received data. When a character is found in the buffer, a button must have been pressed but the message is lost. The idea was pause the main program and to force the display to resend the message, by sending NAK (single character 0x15) to the display. Unfortunately, this does not seem to work.
    Am I doing something wrong? Is there a better way to do this?

    Regards, Kakitech

  • #2
    you dont send a nak to the display, if you want to read an object you need a 4 byte crc validated packet to do so. keep in mind the protocol for the display expects the host to handle the acks/naks/events from the display, if this is not done, and things get out of sync, the display might not respond anymore until reset or the frames come back in sync.

    visigenie has a library for many mcus, why not use its handler for the button capture? the libraries are designed for the protocol implemented in visigenie in workshop


    • #3
      Thank you for your comment, tonton81. I'll check the library for a handler. However, I still don't understand why the display does not repeat its last message when I send it a NAK. In chapter of the reference manual: "If the Host did not understand the message it may respond with a NAK. In this case, the Display will retransmit the message."


      • #4
        thats an interesting question, however, i highly doubt this is possible. Pehaps one of the staff can answer this? In my opinion sending a NAK will offset the stream of bytes which the protocol uses for CRC check, and the display will start returning NAKs when you send it valid commands...


        • #5
          It's not possible, unfortunately that section of the manual seems to be a bit confused about who the host is

          What is the host such that it can't use an interrupt?

          Perhaps you need to run in polled mode? Although if the host is 'very busy', perhaps it can't even lend the time to poll the display


          • #6
            So, this feature is described in the manual but not implemented in the software, unfortunately. Maybe a good idea to correct the manual on this?

            I'll find a workaround, probably using a polling mechanism.


            • #7
              be careful if shifting bytes in they dont get out of sync, youll need to handle it if that event ever occurs, otherwise there may be undefined behaviour, thats why a library written for it is recommended


              • #8
                The Visi-Genie Reference manual clearly states:
                "From Host to Display: NAK
                "NAK If the Host did not understand the message it may respond with a NAK. In this case, the Display will retransmit the message."

                This can be found on page 10, sections, (Report Object Status Message) and ( Report Event Message)

                Mark's response is not acceptable. That section of the manual is very clear about which side the HOST is on.

                So either Mark is mistaken, or 4D Systems is openly claiming that their products do something that they actually don't....

                What's a solution? If data is lost/corrupted from the Display to the Host, or the HOST messed up and needs the data to be resent, what recourse is there except to poll ALL of the elements on the DIsplay?


                • #9

                  Apologies for any inconvenience that this may have caused.

                  Mark is not mistaken neither are we claiming that our products are doing something that they don't.

                  This is merely an error on the datasheet and we are taking steps on correcting that.

                  I hope you understand.

                  Best regards,