[Ovmsdev] Console logging / CAN tracing

[Michael Balzer]

I've found a strange issue with console logging and/or especially CAN tracing:

If CAN tracing is enabled and a command that sends CAN frames and runs longer than about a second (?) (i.e. "co can1 scan"), the trace output first becomes
garbled, the command will need much longer than usual to finish, and after returning to the prompt, the hex and single char output of the trace is split into
separate outputs, coming one per second (running for a while), intermixing with the shell prompt. Also trace output gets garbled especially on a parallel telnet
session.

I suspect that's due to the UART queue becoming full, and the console logger doing xQueueSendToBack() with 1000 ms timeouts.

Every hex dump byte is logged by a separate call to MyCommandApp.Log(). If the queue is full, every single call gets delayed for a second …adding up to block
the console for as many seconds as there are calls…? (unverified theory)

> As proposed, I will change the script code to use BufferedShell and
> also change how console_logger() is done so I can remove the
> problematic OvmsConsole::Log() function.  Then puts() will work again,
> too.
>                                                         -- Steve

Is this related? I.e. should the CAN trace output be done using ESP_LOG instead of MyCommandApp.Log()?

If so I can take care of that…

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26