Announcement

Collapse
No announcement yet.

ACK and NACK

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

  • ACK and NACK

    Happy New Year!!!

    I have been working on a GPS project that allows the user to control a small watercraft on the surface of the water until it reaches a GPS target. I control some electric thrusters based upon GPS position, and I update the coordinates and distance to target on the LCD.

    Please see the attached getInput() function and manualNavigate() function. I have sent a portion of the code.

    These functions currently work well by themselves. The problem is when combine and start Writing Strings.

    Please clarify this: Should I receive an ACK or NACK for every byte sent to the uLCD-70DT? I think that the answer is yes. But the GTX Tool shows a single ACK after each Winbutton press, not 6 ACK's. When I receive the ACK's or NACK's, I immediately flush the serial port and wait for the next byte.

    I am currently using a uLCD-70DT with an Arduino MEGA 2560.

    Code Portion #1: I have written code in C to change Forms and to "decode" Winbutton presses, slider movements, and keypad entry. These functions seem to work great.

    Code Portion #2: I also wrote some code to Write String (ASCII) to the uLCD-70DT. This works fine as well.

    But when I combine Portion #1 and Portion #2, the ACK's and NACK's seem to conflict.

    I have watched the response from various widgets in the GTX Tool.

    When I change forms, I receive and ACK.

    When I press a Winbutton, I do not receive an ACK.

    When I Write String, I receive ACK's as well.

    The ONLY problem that I am really seeing is that bytes from the previous reception seem to combine with bytes from the new reception.

    Here is an example from the Serial Monitor: (I have changed the ACK's to bold)

    INPUT BYTES: 6, 6, 6, 6, 6, 6 - program starts and changes from default form to another form
    INPUT BYTES: 7, 6, 0, 0, 0, 1 - I then press a Winbutton
    INPUT BYTES: 6, 6, 6, 6, 6, 1 - and I get this response. Notice the 5 ACK's with the 6th byte from the previous Winbutton press
    INPUT BYTES: 7, 4, 13, 0, 83, 93 - I then move a slider
    INPUT BYTES: 7, 4, 12, 0, 53, 58 - I then move another slider,...no problem
    INPUT BYTES: 7, 6, 14, 0, 0, 15 - Then I press another Winbutton
    INPUT BYTES: 6, 6, 14, 0, 0, 15 - And I get this response. Notice that the first 2 bytes are ACK's and the next 4 bytes are from the previous Winbutton press.

    Even when I flush the serial port, it doesn't seem to be getting flushed. So if execute a Write string and then a slider movement, one of the previous ACK's continues to precede the slider movement command, so I get something like: INPUT BYTES: 6, 7, 4, 13, 0, 81. I really want to shift all of these bytes to the left so that the first byte is 0x07.

    TIA,
    --Neal
    Attached Files
    Last edited by geometrix; 3 weeks ago.
    TIA,

    Neal

  • #2
    Hi Neal,

    Please see the attached getInput() function
    .
    Unfortunately, I haven't seen the function in the attached code.

    Please clarify this: Should I receive an ACK or NACK for every byte sent to the uLCD-70DT?
    No. You will only receive a single byte for every command you sent.

    I have watched the response from various widgets in the GTX Tool.

    When I change forms, I receive and ACK.

    When I press a Winbutton, I do not receive an ACK.

    When I Write String, I receive ACK's as well.
    Quoted from the ViSi-Genie Reference Manual:
    "Acknowledge byte (0x06); this byte is issued by the Display to the Host when the Display has correctly received the last message frame from the Host. The transmission message for this is a single byte: 0x06
    NAK Not Acknowledge byte (0x15); this byte is issued by the receiver (Display or Host) to the sender (Host or Display) when the receiver has not correctly received the last message frame from the sender. The transmission message for this is a single byte: 0x15"


    You will only receive an ACK/NACK when you issue a command from the Host (e.g. using the Write_Obj/Write_Str). When changing forms, have you used the GTX Tool? If you will notice, a 'Write_Obj' is sent to the display which prompts you to receive a ACK. When pressing a button, did you press it on the display itself? There will be no ACK since there is no command issued from the host. When writing strings, you are writing command from the host to the display so a reply(ACK) will be sent to the host.

    Code Portion #1: I have written code in C to change Forms and to "decode" Winbutton presses, slider movements, and keypad entry. These functions seem to work great.

    Code Portion #2: I also wrote some code to Write String (ASCII) to the uLCD-70DT. This works fine as well.

    The ONLY problem that I am really seeing is that bytes from the previous reception seem to combine with bytes from the new reception.
    I assume that the Win button, slider, keypad has a 'Report Message' on them for you to process each widget accordingly. Aside from the 'Report Message (6 bytes)', please do mind that you also need to consider the 'ACK (1 byte)' coming from the display. This is what the ViSi-Genie library is processing.

    Looking at the 'gbdc_v7.ino', you don't have any RESET ROUTINE and a start-up delay (3-5 seconds) on your code. This is important in order to let the display be in sync with the Arduino before issuing any command

    Code:
    lcdCmd(0x01,0x0A,0x00,0x00,0x00);              // Form 0 - intro screen
    delay(1000);                                   // pause for several seconds to view intro screen
    
    lcdCmd(0x01,0x0A,0x01,0x00,0x00);              // Form 1 - main control screen  
    delay(25);
    I haven't yet see what is inside the lcdCMD function. Are you waiting for the ACK after sending the command? Do you also have a method which you can process the events while waiting for the ACK?

    Here is a relevant forum thread for your reference:
    ACK of command in progress is embeded in report string from button press
    https://forum.4dsystems.com.au/node/65942

    I hope this helps.

    Best Regards,
    Kevin

    Comment

    Working...
    X