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.