ISO 15765-2 =========== Also known as CAN-TP or ISO-TP, this is the packetisation and flow control scheme which underlies the unified diagnostic services which underlies OBD-II In order to be non-blocking, our handling of ISO-TP will have to be around a state machine. Since we need to handle both sending and receiving of large packets, we'll have to have state machines for both. ISO-TP always operates with CAN messages with the full eight bytes of payload. When the packets would be short, ISO-TP pads them. It is safe to pad with zero, 255, or whatever we choose. We will likely use zero. For payloads of fewer than eight bytes, a single CAN packet is needed. For more than seven bytes of payload, more than one packet must be transmitted, which invokes the need for flow control frames. All ISO-TP packets begin with a four bit header in the top nibble of the first byte of the packet. Currently this can take one of four values: 0. Single frame (SF) - The transaction has a payload of fewer than 8 bytes, this is the only CAN frame in it. 1. First frame (FF) - The transaction has a payload of 8 or more bytes, this is the first frame in the transaction. Subsequent frames shall be transmitted following acknowledgement by the recipient with a flow control frame. 2. Consecutive frame (CF) - These are the continuations of a long transaction and contain up to seven more bytes of the payload. 3. Flow control frame (FC) - These are sent by the recipient of a FF and set the parameters by which the rest of the CFs may be transmitted. Depending on the chosen parameters, there may be subsequent FCs needed to get the whole transaction through. In SF, the lower nibble is the number of bytes in the frame, excluding the first (so 0 to 7). Subsequent bytes in the frame are the payload, padded if necessary. In FF, the lower nibble of the first byte, and the whole of the second byte, form a 12 bit value for the number of bytes in the ISO-TP transaction. This in theory allows for up to 4095 bytes, though most ECUs will balk at more than a few hundred. The rest of the frame (6 bytes worth) are the first six bytes of the transaction. In CF, the lower nibble of the first byte is a simple counter, starting at 1 after the first FF and incrementing and wrapping as necessary. This allows for the recipient to notice if it has missed a frame. The remaining up-to-seven bytes are the next chunk of the transaction. In FC, the lower nibble of the first byte is a command/status enumeration: 0. Continue to send 1. Wait please 2. Overflow/abort In practice, most ECUs will only ever use 0 or 2. If the FC is a continue then the second byte is the number of CFs to send before waiting for a new FC (zero means send them all) and the third byte is the inter-frame timing requirements. 0 to 127 is in ms, 241 to 249 mean 100µs to 900µs respectively. Sadly some ECUs get these wrong, so don't be surprised if they send more slowly or more quickly. Since we're a super-powerful computer (yes, even a Pi counts as that) we can always send an FC which says "gimme it all, as fast as you can" which is rendered as a frame consisting of the 3 in the upper nibble of the first byte and everything else being zero. Since the car computers may not be quite so powerful, to send, we should always honour the FC limits. This means we need to use non-blocking timers and have a moderately complex sending state machine.