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,


                  • #10
                    I am using display GEN4-uLCD-43DT for my project and like Kakitech I also had planned that in the event of an incorrect checksum received from the display to send NAK from the host to the display. This would indicate corrupted data received by the host and if it worked as stated would provide an opportunity for the display to re-send that data. As it is the initial data can only be ignored by the host and the user will need to repeat their action of button selection or whatever had caused the event that sent data to the host.

                    As Kakitech points out the Visi Genie Reference manual doc revision 2.0, 29th July 2017 (currently the latest release of this manual) sections and state that in the event of NAK from host to display, the display will retransmit the message, I have clipped and highlighted the relevant paragraphs from the manual below.

                    From Michael's response to Kakitech it now looks like 4D systems plan to re-write the manual to remove the NAK functionality of re-transmitting the message from the display on receipt of the NAK from the host.
                    Form my view point I chose to use these displays partly because of the robustness that the NAK response system provides.
                    I would much rather see 4D Systems correcting the problem rather than removing the facility altogether and re-writing the manual which I get the impression is what Michael is suggesting?

                    It is worth noting that I have already mentioned to my customer that if 4D systems do not correct this issue then for future developments of their products (they use 2x displays per product!) it would be wise to 'design out' these displays. (In this case the host has a built in LCD controller so it would not be difficult).

                    I would encourage 4D systems to re-consider implementing the published operation of NAK on being received from the host causing the display to retransmit the message as stated in their current manual.

                    Click image for larger version

Name:	NAK Response.PNG
Views:	145
Size:	271.1 KB
ID:	68036




                    • #11
                      So at what point do you think you'd send the NAK?

                      If it's in response to a Read or Write command you can simply resend the command, surely you will be aware of what the command was.

                      If it's in response to a Report event, consider, report events may occur at any time, so it's possible that another one has been sent before the controller has sent the NAK. The display cannot wait for the master to acknowledge the report event as this could seriously delay the processing in the display.

                      So what do you want, simply a resend of the last report event? Not ideal is it.

                      So you see, fixing the error in the manual is truly the correct course of action, trying to add some flawed processing is not the way to go.

                      Really, you should be removing checksum errors during hardware development, there should never be any in the field. If there are you need to take a proper definitive action, like alerting the user, otherwise, for whatever reason you may end up seriously degrading the system through excessive NAKs without ever realizing it.


                      • #12
                        Thanks for your reply.

                        It is in response to a corrupted Report Event that I would send a NAK.
                        I do see your point that if many Report Events are being triggered then keeping track of NAK would be difficult or impossible if the next event had occurred before the NAK was received by the display.
                        My system has many Winbuttons that report events as and when the user presses them so in my case it would not be an issue as the host would respond to a checksum error before the next event occurred.

                        Anyway in the light of what you have said I have removed the NAK response from my code.