I looked at the log for this tools/idf_monitor.py:

commit 797340f7f82c29c15c8f59a39856bacbd0a74d53
Author: Roland Dobai <dobai.roland@gmail.com>
Date:   Mon Jun 18 12:49:04 2018 +0200

    idf_monitor: Fix console performance

    https://github.com/espressif/esp-idf/commit/51e42d8e925a20011bb7105da8cc3194d6940a6f
    introduced filtering options which handles the last (unterminated) line
    with a delay. This introduced poor performance for console applications
    when the user interacts with the ESP32 device in the same line because
    there is an artificial delay for each key-press.

    https://github.com/espressif/esp-idf/commit/bb152030a0057c5a9a048782f917c4fa9d7b770e
    decreased the delay but there are still delays for each key-presses.

    The current fix makes only one delay per line instead of each
    key-presses. When an unterminated line is detected then no more
    "delayed" print is used for the given line.

    Fixes https://github.com/espressif/esp-idf/issues/2054

commit bb152030a0057c5a9a048782f917c4fa9d7b770e
Author: Roland Dobai <dobai.roland@gmail.com>
Date:   Wed Jun 13 07:48:52 2018 +0200

    Fix the console performance issue

    The IDF monitor waits for one second before printing the last
    unterminated line. This is necessary for the correct filtering.
    However, this causes poor performance, for example, in the case of the
    system/console example.

    This fix reduces the waiting time which improves the response time of
    the console example and doesn't seem to influence the monitor filter.

    Closes https://github.com/espressif/esp-idf/issues/2054

Then tried rolling back to the Jun 13th commit (bb152030a0057c5a9a048782f917c4fa9d7b770e), and that solved the problem for me.

Issue is the Jun 18th commit (797340f7f82c29c15c8f59a39856bacbd0a74d53), which is:

--- a/tools/idf_monitor.py
+++ b/tools/idf_monitor.py
@@ -393,8 +393,8 @@ class Monitor(object):
         # default we don't touch it and just wait for the arrival of the rest
         # of the line. But after some time when we didn't received it we need
         # to make a decision.
-        if self._last_line_part != b"":
-            if self._force_line_print or (finalize_line and self._line_matcher.match(self._last_line_part)):
+        if finalize_line and self._last_line_part != b"":
+            if self._line_matcher.match(self._last_line_part):
                 self._force_line_print = True;
                 if self._output_enabled:
                     self.console.write_bytes(self._last_line_part)

(that is a reverse patch, so ‘-‘ is new, and ‘+’ is old).

It is simple for us to reverse this in our branch, but we’re out of sync with upstream from then onwards.

Regards, Mark.

On 10 Jul 2018, at 10:01 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Maybe timing related? They’ve messed with things to try to avoid the ‘wait for end of line’ delay.

Regards, Mark.

On 10 Jul 2018, at 9:30 AM, Stephen Casner <casner@acm.org> wrote:

I don't see “Password:” overwriting “OVMS>” but I see "Secure mode"
overwriting "Password:".  Since "Secure mode" is a printf, not a
write, I would expect \n to be massaged into \r\n somewhere along the
path.  It can't be expected that all output strings get \r\n instead
of \n.  So I have to retract my assertion of having fixed the problem.

                                                      -- Steve

On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:


Still not working for me. I get:

“Password:” overwriting “OVMS>” when I type “enable”.
First line of output overwrites command prompt whenever I type a command.
Pressing ENTER at “OVMS#” prompt seemingly does nothing.

Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.

Regards, Mark.

On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:

This problem of no newline is related to the somewhat tricky way I
implemented alert output being written above the current command input
line.  I truncate the newline from the last or only line of an alert
message so that when it is followed by microrl putting out a new
prompt, which is preceded by a newline, we don't get a blank line.

I've just committed a fix.  The problem was that the terminal monitor
discards a newline that does not follow carriage return, and microrl's
terminal_newline() function was written to output the same string to
go to the next line as it takes for input to indicate the end of a
command.  We need the input end-of-line to be just a newline
character, so that is all that terminal_newline() put out before the
prompt.  My fix was to change terminal_newline() to output the
explicit string "\r\n" rather than the macro ENDL.

                                                     -- Steve
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev