Initial bits for Canopied

1 files changed, 71 insertions, 0 deletions

diff --git a/notes/iso-15765-2.mdwn b/notes/iso-15765-2.mdwn
new file mode 100644
index 0000000..24d8230
--- /dev/null
+++ b/notes/iso-15765-2.mdwn
@@ -0,0 +1,71 @@
+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.