Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same. Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi. Greg
Maybe the recent change for IDF v3 where Espressif messed around with CRLF. 2f0c9f0 Translate CR or CRLF to LF on async console for microrl $ git diff fc69e3e 2f0c9f0 diff --git a/vehicle/OVMS.V3/main/console_async.cpp b/vehicle/OVMS.V3/main/console_async.cpp index e7110fa..dd3df4a 100644 --- a/vehicle/OVMS.V3/main/console_async.cpp +++ b/vehicle/OVMS.V3/main/console_async.cpp @@ -155,6 +155,24 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) if (buffered_size > 0) { int len = uart_read_bytes(EX_UART_NUM, data, BUF_SIZE, 100 / portTICK_RATE_MS); + // Translate CR (Enter) from montitor into \n for microrl + bool found = false; + for (int i = 0; i < len; ++i) + { + if (found && data[i] == '\n') + { + for (int j = i+1; j < len; ++j) + data[j-1] = data[j]; + --len; + continue; + } + found = false; + if (data[i] == '\r') + { + data[i] = '\n'; + found = true; + } + } ProcessChars((char*)data, len); } break; @@ -171,7 +189,7 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) uart_flush(EX_UART_NUM); break; default: - ESP_LOGI(TAG, "uart event type: %d\n", event.type); + ESP_LOGE(TAG, "uart event type: %d", event.type); break; } } That should only affect the ASYNC console, I think. It converts CR/LF/CRLF -> LF. Maybe the enum KEY_ACTION in openemacs (vfsedit component) needs to change? Fix is probably to add a NL=10 to KEY_ACTION and then to treat NL or ENTER as the same in the editor_process_keypress. My build environment is all switched to v3 at the moment, so hard for me to test (as IDF v3 does things differently). I’ve made the fix in the for-master branch, and it seems to work for me. $ git diff --staged --- a/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c +++ b/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c @@ -71,7 +71,7 @@ struct append_buffer enum KEY_ACTION { CTRL_A = 1, CTRL_B = 2, CTRL_C = 3, CTRL_D = 4, CTRL_E = 5, CTRL_F = 6, BACKSPACE = 8, TAB = 9, - CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, + NL = 10, CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, CTRL_S = 19, CTRL_U = 21, CTRL_V = 22, CTRL_X = 24, CTRL_Y = 25, CTRL_Z = 26, ESC = 27, FORWARD_DELETE = 127, // The following are just soft codes, not really reported by the @@ -1297,7 +1297,7 @@ bool editor_process_keypress(struct editor_state* E, int k) // Quoted insert - insert character as-is editor_insert_char(E,key); } - else if (key == ENTER) + else if (key == ENTER || key == NL) { editor_insert_newline(E); } I just made the fix also in the master branch, but haven’t tested. Regards, Mark.
On 12 Jan 2018, at 1:36 PM, Greg D. <gregd2350@gmail.com> wrote:
Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same.
Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm still on v2.1... Good thing to watch out for, however. Greg On January 11, 2018 9:51:32 PM PST, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Maybe the recent change for IDF v3 where Espressif messed around with CRLF.
2f0c9f0 Translate CR or CRLF to LF on async console for microrl
$ git diff fc69e3e 2f0c9f0 diff --git a/vehicle/OVMS.V3/main/console_async.cpp b/vehicle/OVMS.V3/main/console_async.cpp index e7110fa..dd3df4a 100644 --- a/vehicle/OVMS.V3/main/console_async.cpp +++ b/vehicle/OVMS.V3/main/console_async.cpp @@ -155,6 +155,24 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) if (buffered_size > 0) { int len = uart_read_bytes(EX_UART_NUM, data, BUF_SIZE, 100 / portTICK_RATE_MS); + // Translate CR (Enter) from montitor into \n for microrl + bool found = false; + for (int i = 0; i < len; ++i) + { + if (found && data[i] == '\n') + { + for (int j = i+1; j < len; ++j) + data[j-1] = data[j]; + --len; + continue; + } + found = false; + if (data[i] == '\r') + { + data[i] = '\n'; + found = true; + } + } ProcessChars((char*)data, len); } break; @@ -171,7 +189,7 @@ void ConsoleAsync::HandleDeviceEvent(void* pEvent) uart_flush(EX_UART_NUM); break; default: - ESP_LOGI(TAG, "uart event type: %d\n", event.type); + ESP_LOGE(TAG, "uart event type: %d", event.type); break; } }
That should only affect the ASYNC console, I think. It converts CR/LF/CRLF -> LF. Maybe the enum KEY_ACTION in openemacs (vfsedit component) needs to change?
Fix is probably to add a NL=10 to KEY_ACTION and then to treat NL or ENTER as the same in the editor_process_keypress. My build environment is all switched to v3 at the moment, so hard for me to test (as IDF v3 does things differently). I’ve made the fix in the for-master branch, and it seems to work for me.
$ git diff --staged --- a/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c +++ b/vehicle/OVMS.V3/components/vfsedit/src/openemacs.c @@ -71,7 +71,7 @@ struct append_buffer enum KEY_ACTION { CTRL_A = 1, CTRL_B = 2, CTRL_C = 3, CTRL_D = 4, CTRL_E = 5, CTRL_F = 6, BACKSPACE = 8, TAB = 9, - CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, + NL = 10, CTRL_K = 11, CTRL_L = 12, ENTER = 13, CTRL_N = 14, CTRL_P = 16, CTRL_Q = 17, CTRL_R = 18, CTRL_S = 19, CTRL_U = 21, CTRL_V = 22, CTRL_X = 24, CTRL_Y = 25, CTRL_Z = 26, ESC = 27, FORWARD_DELETE = 127, // The following are just soft codes, not really reported by the @@ -1297,7 +1297,7 @@ bool editor_process_keypress(struct editor_state* E, int k) // Quoted insert - insert character as-is editor_insert_char(E,key); } - else if (key == ENTER) + else if (key == ENTER || key == NL) { editor_insert_newline(E); }
I just made the fix also in the master branch, but haven’t tested.
Regards, Mark.
On 12 Jan 2018, at 1:36 PM, Greg D. <gregd2350@gmail.com> wrote:
Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same.
Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Greg, I put in a \r to \n translation in the async console similar to what has been present all along in the telnet and ssh consoles. I made this change because in the esp-idf v3.0 there is a new behavior for stdin line endings. In the config there are additional lines to choos the stdin line ending: CONFIG_NEWLIB_STDIN_LINE_ENDING_CRLF= CONFIG_NEWLIB_STDIN_LINE_ENDING_LF=y CONFIG_NEWLIB_STDIN_LINE_ENDING_CR= This defaulted to CR which resulted in the async console never seeing a newline input so it was not possible to execute commands. It did not matter whether Ctrl-J or Ctrl-M is pushed on the keyboard, still the character coming through was CR. Unfortunately, changing the config to LF or CRLF did not seem to make any difference. It appears that the compiled code does not change with this parameter, so my guess is that it is supposed to affect the behavior of the python code. I believe the python code is where the character translation is occurring because when I tried "make simple_monitor" then it looks like both CR and LF were delivered to the console. I tried my own console program that I wrote a while ago; it translates Enter to newline before sending it through, so then the console received the newline that it wants and responded properly. After discussing with Mark, we agree to fix the problem by having the async console translat CR to LF. You could argue that this was not fixing the problem in the right place since the change in behavior that prompted the change was apparently in the python monitor program. -- Steve On Thu, 11 Jan 2018, Greg D. wrote:
Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same.
Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Greg D -
Greg D.
-
Mark Webb-Johnson -
Stephen Casner