retropilot
/
panda
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

J2534_WIN: Added missing docs. Current implementation is wrong.

master
Jessy Diamond Exum 2017-10-09 00:07:47 -07:00
parent 43137849a9
commit e69df3d913
1 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
drivers/windows/docs/other notes.txt
View File

@ -191,6 +191,41 @@ DLL using the Win32 Registry mechanism described in this section.
A.1 Flow Control Overview
ISO 15765-2 was designed to send blocks of up to 4095 bytes on top of the limited 8-byte payload of raw
CAN frames. If the data is small enough, it can fit in a single frame and be transmitted like a raw CAN
message with additional headers. Otherwise, the block is broken up into segments and becomes a
segmented transmission, generating CAN frames in both directions. For flexibility, the receiver of the
segments can control the rate at which the segments are sent.
Each transmission is actually part of a conversation between two nodes. There is no discovery
mechanism for conversation partners. Therefore, each desired conversation must be pre-defined on each
side before the conversation can start. Conversations are symmetric, meaning that either side can send a
block of data to the other. A conversation can only have one transfer (in one direction) in progress at a
time. One transfer must complete before the next transfer (in the same or in a different direction) can
start. The device must support multiple transfers at once, as long as each one is part of a different
conversation. Raw CAN frames are not allowed when using ISO15765-2.
A key feature of a conversation is that each side has a unique CAN ID, and each side uses their unique
CAN ID for all transmissions during the conversation. No other CAN IDs are part of the conversation.
Even though the useful data is only flowing in one direction, both sides are transmitting. One side is
sending the flow control message to pace the segments of data coming from the other side.
For example, during OBD communication, a pass-thru device and an ECU might have a conversation.
The pass-thru device will use the "Tester1" physical CAN ID ($241), and the first ECU will use the
"ECU1" physical CAN ID ($641). During a multi-segment transfer, both sides will be transmitting using
only their respective IDs. It does not matter if the data is being sent by the ECU or by the Tester, the IDs
remain the same.
It is important to understand the difference between OBD Requests/Responses and ISO 15765-2
transfers. The OBD Request is transmitted from the Tester to the ECU using functional addressing.
Because segmented transfer is not possible on functional addresses, the message must fit in a single
frame. The OBD Response is a message from the ECU to the Tester using physical addressing. Unlike
other protocols, the responses are not sequential. In fact, the responses can overlap, as if each ECU
were having a private conversation with the Tester. Some of the responses may fit in a single frame,
while others will require a segmented transfer from the ECU to the tester.
A.2 Transmitting a Segmented Message
When PassThruWrite is called, the API will search the list of flow control filters, looking for a
pFlowControlMsg that matches the CAN ID (and possible extended address) of the message being sent.