[Ovmsdev] CAN BUS logging to flash storage

Mon Jan 15 01:13:21 HKT 2018

Mark,

thanks for the info, I'll add a documentation file on this.

It just turned out writing into a file is far too slow to be done inline with the frame processing… and yes, I _could_ have anticipated that ;)

Maybe idf 3.x will perform better on file I/O, but a separate logging task is better anyway.

Regards,
Michael

Am 12.01.2018 um 01:44 schrieb Mark Webb-Johnson:
> Thanks.
>
> I really should formally document the CRTD format properly somewhere. Anyway, here are my old notes on it, and an example:
>
> +++++
>
> CRTD Example:
>
>     1320724293.000 CXX OVMS Tesla Roadster cando2crtd converted log
>     1320724293.000 CXX OVMS Tesla roadster log: trip.20111108.csv
>     1320724294.072 R11 420 00 96 96
>     1320724294.073 R11 588 00 00 86
>     1320724294.073 R11 280 00 00 03 00 00 00 00 00
>     1320724294.073 R11 001 00 00 00 00
>     1320724294.073 R11 590 01 00 00 00 00 00 00 00
>     1320724294.113 R11 400 01 01 00 00 00 00 4C 1D
>
>
> Generators should use whatever line termination the host system uses. For Unix and embedded systems that is LF. Parsers should support all CR, LF, and CRLF
> variants.
>
> Generators should output hex fields in upper-case and front zero padded (for clarity). Parsers should support both upper and lower case, as well as variable
> length.
>
> By convention, the .crtd extension is used for these files. It is suggested that generators prefix all crtd files with CXX lines documenting the generator,
> comment and source of log file.
>
> Space-separated fields are:
>
>   * Timestamp (can be seconds, milliseconds, or microseconds - zero prefixed and full length padded for ms and us).
>   * Type:
>       o C*: comment
>           + CXX: general comment (rest of line is a comment)
>           + CEV: user-generated event (rest of line is event description)
>       o R11: rx standard frame
>       o R29: rx extended frame
>       o T11: tx standard frame
>       o T29: tx extended frame
>
>
> Other field notes:
>
>   * For the R?? and T?? types, the rest of the line is hex ID followed by hex data bytes (up to 8).
>   * In the case of systems supporting multiple CAN buses, the type can be prefixed with the bus number (eg; 1R11, 2T29, etc). Messages from different CAN bus
>     captures can be written to one shared crtd file, or individual files for each bus - entirely up to the generator.
>
>
> +++++
>
> Regards, Mark.
>
>> On 11 Jan 2018, at 8:59 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark,
>>
>> I'll add the logging support along with the TX queue.
>>
>> Regards,
>> Michael
>>
>>
>> Am 10.01.2018 um 01:27 schrieb Mark Webb-Johnson:
>>> Probably best to split this off as a separate eMail thread.
>>>
>>> I think the implementation would be relatively simple.
>>>
>>>   * Create a canlog class with a FILE* m_log member variable, and a virtual function Log() that is called with a direction (tx/rx) and frame to log.
>>>       o The constructor should be passed the vfs file path to log to. It should fopen the m_log file to that.
>>>       o The destructor should fclose the m_log file.
>>>   * Create a canlog_crtd class, derived from canlog, that supports Log() to log to m_log in CRTD format.
>>>   * Optionally create other canlog_* classes, for other logging formats that we want to support.
>>>   * Add a canlog* m_log member variable in canbus.
>>>       o Initialise m_log to NULL in the constructor.
>>>       o In the destructor, if m_log is not null, delete it’s object and set it to NULL.
>>>       o Have a command ‘can log’ like ‘can trace’ that specifies a vfs file path (remember to check it with OvmsConfig ProtectedPath) and logging format. It
>>>         will then ’new’ a canlog_* style object (depending on logging format).
>>>   * In can::IncomingFrame, log incoming CAN messages with m_log->Log(), in the same way as m_trace is handled.
>>>   * In canbus::Write, log outgoing CAN messages with m_log->Log(), in the same way as m_trace is handled.
>>>
>>>
>>> Volunteer?
>>>
>>> Regards, Mark.
>>>
>>>> On 10 Jan 2018, at 8:07 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>> Now SD CARD support is coming, anybody want to step forward and extend components/can to support CAN bus logging to a file (in crtd format, or perhaps
>>>> support one or two popular formats)? Implementation would be in class canbus, very similar to m_trace; just need to have a FILE* m_log and appropriate
>>>> commands / logging of packet write/read in the same place that trace does it.
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180114/abf6fd9b/attachment.htm>