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.
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?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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':
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?