doc:rfc_canraw-mode
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
doc:rfc_canraw-mode [2014/08/31 11:41] – [Examples] admin | doc:rfc_canraw-mode [2016/01/21 18:14] – admin | ||
---|---|---|---|
Line 80: | Line 80: | ||
- | The OOBD CAN raw format does not only allow single CAN frames, it can also send (if necessary) | + | The OOBD CAN raw format does not only allow single CAN frames, it can also send (if necessary) |
The data consists of one or more blocks: | The data consists of one or more blocks: | ||
Line 98: | Line 98: | ||
Following the scheme above, there can be so much blocks send in one go as fit into the input buffer of 4095 bytes. | Following the scheme above, there can be so much blocks send in one go as fit into the input buffer of 4095 bytes. | ||
+ | |||
+ | |||
+ | The whole sequence is only sent once. For repetition, the application need to raise the command again. | ||
Line 125: | Line 128: | ||
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. | 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. | ||
- | |||
- | == 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) == | == Lawicel Output from ISR (3) == | ||
Line 143: | Line 142: | ||
Which has the following format for 11-bit CAN Identifier | Which has the following format for 11-bit CAN Identifier | ||
- | tiiindddddddddddddddd[ssss] | + | tiiindddddddddddddddd[ssss]\r |
or | or | ||
- | Tiiiiiiiindddddddddddddddd[ssss] \r | + | Tiiiiiiiindddddddddddddddd[ssss]\r |
for 29 bit CANIDs, where the meaning is | for 29 bit CANIDs, where the meaning is | ||
Line 157: | Line 156: | ||
| d | 0.. 8 | 0-8 Data Bytes in Hexadecimal writing | | | d | 0.. 8 | 0-8 Data Bytes in Hexadecimal writing | | ||
| s | 2 | optional timestamp in hexadecimal writing (0..65535 ms) | | | 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, | ||
+ | |||
+ | 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) | ||
+ | | 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 | | ||
+ | |||
doc/rfc_canraw-mode.txt · Last modified: 2016/10/30 09:22 by admin