Logging Details.
Message Structure:
1. Message ID
Eleven bits, normally 7FF max for real CAN messages.
Up to FFF for pseudo-CAN Messages, never sent via CAN.
Represented as HLL, three hex nibbles.
2. Data Length Nibble
A single hex nibble, 0 to 8 for real CAN messages.
The value F is used for pseudo-messages, which
are never transmitted via CAN.
Represented by N, one hex nibble.
3. Data Bytes
Eight bytes, D1 through D8, any values 0 to FF.
When the data Length is less than 8,the unused
data bytes are forced to FF before logging.
4. Sync Byte
One byte, EOR of NH LL 0x53
Represented as one byte SY.
5. Time Stamp
Two byte value = seconds *1024, + milliseconds.
(or, faster, ((sec << 10) + ms)
Seconds = 0 to 59, ms = 0 to 999.
Represented by two bytes SS MM
6. CAN Type
A single byte, usually 1 to 4 for CAN types
EV, CAR, AV, and QC.
The value 0 is used for Date-Time Messages, and
other messages, like Events, that apply to all
the CAN types.
One byte, represented by TY.
7. ALC format Message
A fixed length (14-byte) binary "record", with no delimiter.
SY LL NH D1 D2 D3 D4 D5 D6 D7 D8 SS MM TY
Source of Log Messages:
1. Test Messages
Valid CAN messages, or pseudo-messages, usually with
data fields that include sequence numbers so that
missing messages can be detected.
The Time Stamp tells when they were created.
My Arduino Due Sketch creates these now.
2. Internal Operation Data
Messages, pseudo or CAN that hold data important
to monitoring and evaluating the design and performance
of the mini-QC. Example, temperature, input AC Current, etc.
3. Date-Time Messages
These are special pseudo-messages, with N=F
and MsgID =FFF, where the data first 4 bytes contain
the Date-Time as the number of seconds part the
start of 1970 (I think), and the other 4 bytes...
zero, I think, but I need to check.
These messages are recognized and used by CAN-Do.
4. Status-Event Messages
With N=F, and the MsgID =FFE, and the data is 8 ASCII
characters, these pseudo-messages are recognized
by CAN-Do as Event, or Error, messages to the user.
Using MsgID = FFC to make a "Continuation" message,
one can extend the ASCII message to 16 or 24 characters,
but these messages must precede the FFE message.
A feature of CAN-Do is to insert User-defined Event
messages into the arriving log stream. This is handy
when looking for something like window-control bits
in the CAR-CAN data. Just before running the window
down, insert a Down-Event, etc. to help locate the
desired data in the Log.
5. CAN Input
We want to handle getting the CAN input on an interrupt,
so that the message gets read out of the MOB (CAN
hardware "Mailbox") quickly, the MOB gets prepared to
receive again quickly, and the received message gets
its Time Stamp, is processed as needed, and is put into
the Ring Buffer in proper sequence.
To handle fast-arriving messages, one right on the
tail of another, one usually needs to use two or more
MOBs to avoid missing messages.
So, get the message out of the MOB, check various
error flags to see if it is a "good" message, get a
Seconds-Milliseconds Time Stamp, reset the MOB,
and write the message into the Buffer.
Then, copy the message for use by the Timer.
6. CAN Output
The real CAN Messages, to be sent on the CAN bus,
should also be logged as well as properly sent.
Conflicts with the other interrupts need to be
carefully avoided, and in general, the interrupts
should not interrupt each other. A bit of masking
or checking limits is wise, so check N <= 8 and
MsgID <= 7FF.
