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:
- C*: comment
- CXX: general comment (rest of line is a
comment)
- CEV: user-generated event (rest of line
is event description)
- R11: rx standard frame
- R29: rx extended frame
- T11: tx standard frame
- 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.
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.
- The constructor should be passed
the vfs file path to log to. It should fopen
the m_log file to that.
- 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.
- Initialise m_log to NULL in the
constructor.
- In the destructor, if m_log is
not null, delete it’s object and set it to
NULL.
- 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.
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@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev