Maybe reopen issue 2054 to list our specific example of what fails to see what they say? -- Steve On Fri, 27 Jul 2018, Mark Webb-Johnson wrote:
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/51e42d8e925a20011bb7105da8cc3194... 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/bb152030a0057c5a9a048782f917c4fa... 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