- Fri Nov 11, 2016 5:55 am
#57972
As far as I know, the only way to break the interpreter out of running a busy script is to either press the SAVE or RUN buttons in the browser Edit page, which isn't much use with the current 'reboot when saved' problems, nor if the wifi gets disconnected as often happens with a malfunctioning script.
The serial port is used by the interpreter to send out connection diagnostics, so...
* Why not also use the serial port as input, for sending an 'END' instruction into the busy interpreter to end its task - which could let all background timer and interrupt activities be killed off and allow the interpreter to just concentrate on doing a SAVE.
* Assuming sending a serial END is possible, then why not add an END button to the EDIT page for stopping a script.
* If an END button could be added to EDIT (or even if not), might it be possible to provide option for USER button(s), so the user could include their own quick branch or link to something from the EDIT page if wished.
* If it is possible to send a serial END instruction to the interpreter, it must also be possible to send other instructions... like perhaps a PING to check wifi connection (which is one of the events reported back serially during the connection diagnostics anyway) and which could return a serial PING_ACK to the interpreter if the connection is ok. This would allow for a very useful connection confirmation mechanism which could be used to self-trigger a reboot whenever wifi connection is lost.
* If you can serially END a script without browser connection, then why not RUN it serially without browser connection also. Or run the wifi connection commands serially before even being connected to the wifi.
An incoming serial commands capability for the interpreter might open the door for a raft of unexpected advantages and benefits.
The serial port is used by the interpreter to send out connection diagnostics, so...
* Why not also use the serial port as input, for sending an 'END' instruction into the busy interpreter to end its task - which could let all background timer and interrupt activities be killed off and allow the interpreter to just concentrate on doing a SAVE.
* Assuming sending a serial END is possible, then why not add an END button to the EDIT page for stopping a script.
* If an END button could be added to EDIT (or even if not), might it be possible to provide option for USER button(s), so the user could include their own quick branch or link to something from the EDIT page if wished.
* If it is possible to send a serial END instruction to the interpreter, it must also be possible to send other instructions... like perhaps a PING to check wifi connection (which is one of the events reported back serially during the connection diagnostics anyway) and which could return a serial PING_ACK to the interpreter if the connection is ok. This would allow for a very useful connection confirmation mechanism which could be used to self-trigger a reboot whenever wifi connection is lost.
* If you can serially END a script without browser connection, then why not RUN it serially without browser connection also. Or run the wifi connection commands serially before even being connected to the wifi.
An incoming serial commands capability for the interpreter might open the door for a raft of unexpected advantages and benefits.
