• Is the ack something you receive serially / over RX from the module?

    If so, use serial.onData(callback) with callback function receiving the ack and triggering the next command...

    For use in application logic, this is of course a bit cumbersome... Therefore, you may use a FIFO with some triggering methods inbetween your app and the display which takes care of feeding the display module with the comands in a timely correct manner/sequence, where as the application just pushes to the FIFO without having to be time aware.

    The FIFO is of course a buffer and could over-grow if you have a run-away in your application.

    Some code 'in the rough':

    var dsp =
    { cmds: [] // fifo
    , idling: false
    , serial: null
    , exec: function(cmd) { // cmd to send to display
        this.cmds.push(cmd);
        if (this.idling) { 
          this.idling = false;
          this._tx();
        }
      }
    , _tx: function() {
        this.serial.write(this.cmds.splice(0,1))­;
      }
    , _rx: function(data) {
        if (this.cmds.length > 0) { 
          this._tx(); 
        } else { 
          this.idling = true;
        }
      }
    , connect: funcrtion(serial) {
        this.serial = serial;
        this._rx.bind(this);
        this.serial.on('data',this._rx);
        this.idling = true;
        this.exec(""); // may be some initializations...
      }
    }
    
    Serial1.setup(9600); // setup Serial1
    dsp.connect(Serial1);
    dsp.exec("....."); // 1st cmd
    dsp.exec("....."); // 2nd cmd
    dsp.exec("....."); // 3rd cmd
    

    This code has no error handling (over flow, out of synch, etc.) in place. For examples:

    • .exec() needs overflow handling (some reasonable limit to the fifo size check)
    • ._rx() needs check ack data received and accdingly acted on
    • some state / timout has to be put in place in case communication gets 'out of sync'

    A first enhancement is to leave the command in the fifo (using this.serial.write(this.cmds[0]);) until 'good' ack is received and then removed (this.cmds.splice(0,1);). If 'bad' acc is received (or timout hits), re-send/re-print or drop - with or without error logging - has to be considered.

    The .connect() is currently minimal. You may extend it with additional parameter(s) - string (or array of strings) that include some display module initialization that has to be done anyway.

    Can you share the code how you got your display initially working?

About

Avatar for allObjects @allObjects started