doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware
Differences
This shows you the differences between two versions of the page.
doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware [2014/03/01 05:00] – created admin | doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware [2014/08/16 12:25] (current) – admin | ||
---|---|---|---|
Line 2: | Line 2: | ||
- | | OOBD Team | S. Koehler | | + | |OOBD Team |S. Koehler | |
- | | Request for Comments:6 | | + | |Request for Comments: |
- | | Obsoletes: - | | | + | |Obsoletes: - | | |
- | | Category: Draft Standard | May 2013 | | + | |Category: Draft Standard | May 2013 | |
===== Status of this Memo ===== | ===== Status of this Memo ===== | ||
- | |||
- | This memo provides information about how to read real time CAN data through the OOBD firmware. | + | |
+ | This memo provides information about how to read real time CAN data through the OOBD firmware. | ||
+ | |||
===== Copyright Notice ===== | ===== Copyright Notice ===== | ||
- | |||
- | Copyright (C) OOBD Team (2012). | + | |
+ | Copyright (C) OOBD Team (2012). | ||
+ | |||
===== Introduction ===== | ===== Introduction ===== | ||
- | + | ||
==== Concept ==== | ==== Concept ==== | ||
Line 23: | Line 27: | ||
To surround several constrains like bus speed, real time capabilities and memory size when recording real time data in OOBD, the following concept will be followed | To surround several constrains like bus speed, real time capabilities and memory size when recording real time data in OOBD, the following concept will be followed | ||
- | | + | |
- | - To avoid unpredictable bus speed bottlenecks, | + | |
- | - To reuse existing code on application side, the configuration and the data request will be implemented as pseudo UDS services: Service 27 (Write Data) to configure, Service 22 (Read Data) to read. | + | |
+ | - To avoid unpredictable bus speed bottlenecks, | ||
+ | - To reuse existing code on application side, the configuration and the data request will be implemented as pseudo UDS services: Service 27 (Write Data) to configure, Service 22 (Read Data) to read. | ||
==== Initialization ==== | ==== Initialization ==== | ||
Line 32: | Line 39: | ||
Select the CAN RTD protocol | Select the CAN RTD protocol | ||
- | | + | |
+ | < | ||
+ | p 1 1 3 0 | ||
+ | </ | ||
Open the CAN filters | Open the CAN filters | ||
- | | + | |
- | p 8 11 1 0 | + | < |
+ | p 8 10 1 0 | ||
+ | p 8 11 1 0 | ||
+ | </ | ||
This activates the CAN Real Time Protocol, clears the internal PID list and sets the CAN bus into " | This activates the CAN Real Time Protocol, clears the internal PID list and sets the CAN bus into " | ||
+ | |||
==== Configuration ==== | ==== Configuration ==== | ||
Line 45: | Line 61: | ||
=== Commands === | === Commands === | ||
- | |||
The data to listen to is defined by the application to the firmware with an 27- command: | The data to listen to is defined by the application to the firmware with an 27- command: | ||
- | | + | |
+ | < | ||
+ | 27 CanID Type [Length [cPos [cStart]]] | ||
+ | </ | ||
Values not given use 0 as default value | Values not given use 0 as default value | ||
+ | |||
where the data byte meanings are as follows: | where the data byte meanings are as follows: | ||
- | ^ Block ^ Length in Bytes ^ Meaning | ||
- | | CanID | 4 | CAN- ID to listen to (MSB ..LSB) | ||
- | | Type | 1 | Multi frame message type | 0: Single Frame \\ 1: Custom \\ 2: ISO-TP | ||
- | | Length | ||
- | | cPos | 1 | Position of Sequence counter | ||
- | | cStar | 1 | start value of Sequence counter | ||
- | === Errors === | + | ^ Block ^Length in Bytes ^ Meaning |
+ | | CanID | 4 |CAN- ID to listen to (MSB ..LSB) | | | ||
+ | | Type | 1 |Multi frame message type |0: Single Frame \\ 1: Custom | ||
+ | | Length | ||
+ | | cPos | 1 |Position of Sequence counter |-preliminary- If telegram type is custom, than this position (0-7) is used to identify the sequence counter inside the CAN frame. | | ||
+ | | cStar | 1 |start value of Sequence counter |-preliminary- If telegram type is custom, than this value is used to identify the first frame by its sequence counter inside the CAN frame. | | ||
+ | |||
+ | === Errors === | ||
- | ^ Error Code ^ Meaning | + | ^ Error Code ^Meaning |
- | | 1 | Command too long: there are more bytes gives as specified by the command format | + | | 1 |Command too long: there are more bytes gives as specified by the command format | |
- | | 2 | out of Memory: Not enough memory to store the requested data buffer | + | | 2 |out of Memory: Not enough memory to store the requested data buffer | |
- | | 3 | CAN ID already exist: The requested CAN ID is already requested before | + | | 3 |CAN ID already exist: The requested CAN ID is already requested before | |
Line 79: | Line 99: | ||
Request Single frame with ID 0400 | Request Single frame with ID 0400 | ||
- | | + | |
+ | < | ||
+ | 27 00000400 | ||
+ | </ | ||
Request Single frame (=type 00) with ID 0400 and length 3 | Request Single frame (=type 00) with ID 0400 and length 3 | ||
- | | + | |
+ | < | ||
+ | 27 00000400 00 0003 | ||
+ | </ | ||
Request custom multi frame (=type 01) with ID 400 , length 20, sequence counter position at Byte 3 and starting value of 2 | Request custom multi frame (=type 01) with ID 400 , length 20, sequence counter position at Byte 3 and starting value of 2 | ||
- | | + | |
+ | < | ||
+ | 27 00000400 01 0014 03 02 | ||
+ | </ | ||
Request ISO-TP multiframe | Request ISO-TP multiframe | ||
- | | + | |
- | + | < | |
+ | 27 00000400 02 | ||
+ | </ | ||
+ | |||
==== Read Data ==== | ==== Read Data ==== | ||
Line 101: | Line 137: | ||
The request to the firmware to send received data to the application is done with an 22- command: | The request to the firmware to send received data to the application is done with an 22- command: | ||
- | | + | |
+ | < | ||
+ | 22 AA BB CC DD | ||
+ | </ | ||
where the data byte meanings are as follows: | where the data byte meanings are as follows: | ||
- | ^ Bytes ^ Meaning | ||
- | |AA BB CC DD|CAN- ID to listen to (MSB ..LSB)| | ||
- | As result the firmware first repeats the command + 40H (=0x62) , a four byte timestamp (AABBCCDD, FreeRTOS ticks) and the received data bytes after that: | + | ^ Bytes ^ Meaning |
+ | |AA BB CC DD |CAN- ID to listen to (MSB ..LSB) | | | ||
+ | |||
+ | |||
+ | As result the firmware first repeats the command + 40H (=0x62) , a four byte timestamp (AABBCCDD, FreeRTOS ticks), a one byte flag (FL) | ||
+ | |||
+ | |||
+ | < | ||
+ | 62 AA BB CC DD FL 00 11 22 .. | ||
+ | </ | ||
+ | == Flag == | ||
+ | |||
+ | |||
+ | In the moment only bit 0 of the flag is used. If set, the data output is new and has not been printed before. After printed, the flag is set to 0 by the firmware. So when bit 0 is set, this is fresh data. By that the application software don't need to control by itself (by the time stamps) if this data has already been received before or if its new data. | ||
- | 62 AA BB CC DD 00 11 22 .. | ||
=== Errors === | === Errors === | ||
Line 116: | Line 166: | ||
the error messages are designed as General Response Code Errors, means they are coded as received bytes, not as clear text error messages. The byte sequence always starts with 7F 00, followed by the error code byte: | the error messages are designed as General Response Code Errors, means they are coded as received bytes, not as clear text error messages. The byte sequence always starts with 7F 00, followed by the error code byte: | ||
- | |||
- | ^ Error Code ^ Meaning | ||
- | | | ||
- | | | ||
+ | ^ Error Code ^ Meaning | ||
+ | | 01 |unknown CAN ID (not configured yet) | | ||
+ | | 02 |no valid data received until now | | ||
Line 127: | Line 176: | ||
- | ^ Command | + | ^ Command |
- | | p 6 1 |clear the internal data buffer list, releases all used memory buffers| | + | | p 6 1 |clear the internal data buffer list, releases all used memory buffers | |
==== Implementation Details ==== | ==== Implementation Details ==== | ||
- | | + | |
- | - In case a requested CAN ID is > 8 bytes, then the element needs to have two receive buffers (double buffering), to make make sure that there' | + | - In case a requested CAN ID is > 8 bytes, then the element needs to have two receive buffers (double buffering), to make make sure that there' |
- | - The implementation needs to make sure, that a buffer is not altered during its printout process | + | - The implementation needs to make sure, that a buffer is not altered during its printout process |
- | - The implementation needs to make sure, that a buffer is only declared as valid, if a complete frame sequence (0..x) has been received without disturbance. | + | - The implementation needs to make sure, that a buffer is only declared as valid, if a complete frame sequence (0..x) has been received without disturbance. |
==== Security Considerations ==== | ==== Security Considerations ==== | ||
- | |||
- | This RFC raises security issues. It's need to make sure that the firmware only listens on the bus in invisible mode without creating any active (re)action on the bus. | + | |
+ | This RFC raises security issues. It's need to make sure that the firmware only listens on the bus in invisible mode without creating any active (re)action on the bus. | ||
+ | |||
==== References ==== | ==== References ==== | ||
- | + | ||
==== Authors' | ==== Authors' | ||
- | + | ||
Steffen Koehler | Steffen Koehler | ||
+ | |||
Phone: +49 172 410 35 98 | Phone: +49 172 410 35 98 | ||
- | EMail: | + | |
+ | EMail: | ||
+ | |||
==== Appendix ==== | ==== Appendix ==== | ||
- | | + | |
==== Full Copyright Statement ==== | ==== Full Copyright Statement ==== | ||
- | |||
- | Copyright | ||
- | This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, | + | Copyright |
- | The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns. | ||
- | This document and the information contained herein is provided on an "AS IS" basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." | + | This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, |
- | Relation to other RFCs | + | |
+ | |||
+ | The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns. | ||
+ | |||
+ | |||
+ | This document and the information contained herein is provided on an "AS IS" basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." | ||
==== Updates ==== | ==== Updates ==== | ||
- | + | ||
==== Obsoletes ==== | ==== Obsoletes ==== | ||
- | + | ||
==== Obsoleted-by ==== | ==== Obsoleted-by ==== | ||
- | + | ||
==== Updated-by ==== | ==== Updated-by ==== | ||
- | + | ||
==== Contact ==== | ==== Contact ==== | ||
- | + | ||
==== Distribution Lists ==== | ==== Distribution Lists ==== | ||
- | |||
- | The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list. | ||
- | To join (or quit) the list goto https:// | + | The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list. |
+ | |||
+ | |||
+ | To join (or quit) the list goto [[https:// | ||
+ | |||
+ | |||
+ | \\ |
doc/rfc_rtd-real-time-data-protocol-for-the-oobd-firmware.txt · Last modified: 2014/08/16 12:25 by admin