Differences

This shows you the differences between two versions of the page.

--- doc:rfc_canraw-mode [2014/03/02 06:47] – created admin
+++ doc:rfc_canraw-mode [2014/09/01 07:14] – [Examples] admin
@@ Line 58: / Line 58: @@
 Activate CANraw listen mode
-  p 7 1 1
+  p 7 1 x
+where x is one of the output formats of the listen command.
-Hint:
+Received CAN Frames will be immediately dumped on the serial output. See the chapter Example for more details.
-If there are already CAN-Messages received on the HS-CAN interface they will be directly transmitted from the firmware to the serial Bluetooth interface so that they are directly accessible by any application (i.e. OOBD-Android). See the chapter Example for more details.
 ==== Configuration ====
@@ Line 107: / Line 107: @@
 ==== Examples ====
-receiving frames:
+=== Receiving Frames: ===
+Depending on the parameter x given at the listen format ''p 7 1 x''. the dongle dumps the received frames in different formats (where x=0 means disable listen outputs):
+== Vector Style Output (1) ==
+When having x=1, the output is like this
   # 170943 0x1f6  0x0  8  00  00  01  49  00  03  00  0a
@@ Line 113: / Line 120: @@
   # 170944 0x2fd  0x0  6  00  e5  e2  00  2e  f0
-FIXME Sending frames:
+== Vector Style Output from ISR (2) ==
+When having x=2, the output is like 1, but to have higher output performance (if needed), this output is already made in the CAN service routine.
+== Lawicel Output from ISR (3) ==
+With x=3, the output comes also straight out of the CAN Interrupt service routine, having the so called Lawicel or SLCAN format:
+  T000007e1801a1a2a3a4a5a6a7deab
+  T000007e247202700000000000e293
+  T000007e381010323334353637e67b
+  T000007e081112131415161718ea63
+  T000007e1802b1b2b300000000ee4b
+  T000007e3821363738393a3b3cf233
+Which has the following format for 11-bit CAN Identifier
+  tiiindddddddddddddddd[ssss]\r
+or
+  Tiiiiiiiindddddddddddddddd[ssss]\r
+for 29 bit CANIDs, where the meaning is
+^ Field name  ^ Length (Bytes)  ^ Meaning ^
+|    T / t    |      1          | T= 29 bit CAN ID, t= 11 bit CAN ID |
+|    i        |      2 / 4      | CAN ID either as 2 bytes (=11 bit) or 4 Bytes (=29 bit) |
+|    n        |      1          | DLC (Number of Bytes) in Hex Format ("0".."8") |
+|    d        |     0.. 8       | 0-8 Data Bytes in Hexadecimal writing |
+|    s        |      2          | optional timestamp in hexadecimal writing (0..65535 ms) |
+== Binary Output from ISR (4) ==
+With x=4 the output is in a binary format for highest throughput. This binary format is unique to OOBD and not supported by other software (yet).
+All values are directly transferred in their binary representation, except the value 0xFF (255). If a 0xFF appears in the bytestream, it's written as a sequence of two 0xFF.
+On the other hand the 0xFF is used as Sync-Byte, which can optionally mark the start of a frame sequence. Please notice that this Sync-Byte is not mandatory for each frame sequence and might only be sent each few frames to allow the receiving software to sync to the byte stream.
+As the Sync Byte is always followed by the Info Byte, which MSB is always set to 0, a sync byte can always be identified.
+So a frame sequence consists of
+^ Field name  ^ Length (Bytes)  ^ Meaning ^
+|    SB    |      1          | Sync Byte (SB), Value 0xFF, **optional** |
+|    IB    |      1          | Bit 7 (MSB)=0 \\ Bit 6 = Extended CAN-ID \\ Bit 4-5 Errorflags \\ Bit 0-3 DLC |
+|    TS    |      2          | Time Stamp (0..65535 ms) |
+|    ID    |      2 / 4      | Extended / Normal CAN ID |
+|    Data    |    0..8       | Data Bytes |
+FIXME Sending frames:
 ===== Implementation Details =====