readme.rst

   1 Linux SocketCAN driver for ELM327
   2 ==================================
   3
   4 Authors
   5 --------
   6
   7 Max Staudt <elmcan@enpas.org>
   8
   9
  10
  11 Motivation
  12 -----------
  13
  14 CAN adapters are expensive, few, and far between.
  15 ELM327 interfaces are cheap and plentiful.
  16
  17 This driver aims to lower the initial cost for hackers interested in
  18 working with CAN buses.
  19
  20
  21
  22 Introduction
  23 -------------
  24
  25 This driver is an effort to turn abundant ELM327 based OBD interfaces
  26 into full-fledged (as far as possible) CAN interfaces.
  27
  28 Since the ELM327 was never meant to be a stand-alone CAN controller,
  29 the driver has to switch between its modes asa quickly as possible in
  30 order to approximate full-duplex operation.
  31
  32 As such, elmcan is a best-effort driver. However, this is more than
  33 enough to implement simple request-response protocols (such as OBD II),
  34 and to monitor broadcast messages on a bus (such as in a vehicle).
  35
  36 Most ELM327s come as nondescript serial devices, attached via USB or
  37 Bluetooth. The driver cannot recognize them by itself, and as such it
  38 is up to the user to attach it in form of a TTY line discipline
  39 (similar to PPP, SLIP, slcan, ...).
  40
  41 This driver is meant for ELM327 versions 1.4b and up, see below for
  42 known limitations in older controllers and clones.
  43
  44
  45
  46 Data sheet
  47 -----------
  48
  49 The official data sheets can be found at ELM electronics' home page:
  50
  51   https://www.elmelectronics.com/
  52
  53
  54
  55 How to check the controller version
  56 ------------------------------------
  57
  58 Use a terminal program to attach to the controller.
  59
  60 After issuing the "``AT WS``" command, the controller will respond with
  61 its version::
  62
  63     >AT WS
  64
  65
  66     ELM327 v1.4b
  67
  68     >
  69
  70
  71
  72 How to attach the line discipline
  73 ----------------------------------
  74
  75 Every ELM327 chip is factory programmed to operate at a serial setting
  76 of 38400 baud/s, 8 data bits, no parity, 1 stopbit.
  77
  78 The line discipline can be attached on a command prompt as follows::
  79
  80     sudo ldattach \
  81            --debug \
  82            --speed 38400 \
  83            --eightbits \
  84            --noparity \
  85            --onestopbit \
  86            --iflag -ICRNL,INLCR,-IXOFF \
  87            26 \
  88            /dev/ttyUSB0
  89
  90 To change the ELM327's serial settings, please refer to its data
  91 sheet. This needs to be done before attaching the line discipline.
  92
  93
  94
  95 Known limitations of the controller
  96 ------------------------------------
  97
  98 - All versions
  99
 100   No automatic full duplex operation is supported. The driver will
 101   switch between input/output mode as quickly as possible.
 102
 103   The length of outgoing RTR frames cannot be set. In fact, some
 104   clones (tested with one identifying as "``v1.5``") are unable to
 105   send RTR frames at all.
 106
 107   We don't have a way to get real-time notifications on CAN errors.
 108   While there is a command (``AT CS``) to retrieve some basic stats,
 109   we don't poll it as it would force us to interrupt reception mode.
 110
 111
 112 - Versions prior to 1.4b
 113
 114   These versions do not send CAN ACKs when in monitoring mode (AT MA).
 115   However, they do send ACKs while waiting for a reply immediately
 116   after sending a frame. The driver maximizes this time to make the
 117   controller as useful as possible.
 118
 119   Starting with version 1.4b, the ELM327 supports the "``AT CSM``"
 120   command, and the "listen-only" CAN option will take effect.
 121
 122
 123 - Versions prior to 1.4
 124
 125   These chips do not support the "``AT PB``" command, and thus cannot
 126   change bitrate or SFF/EFF mode on-the-fly. This will have to be
 127   programmed by the user before attaching the line discipline. See the
 128   data sheet for details.
 129
 130
 131 - Versions prior to 1.3
 132
 133   These chips cannot be used at all with elmcan. They do not support
 134   the "``AT D1``", which is necessary to avoid parsing conflicts on
 135   incoming data, as well as distinction of RTR frame lengths.
 136
 137   Specifically, this allows for easy distinction of SFF and EFF
 138   frames, and to check whether frames are complete. While it is possible
 139   to deduce the type and length from the length of the line the ELM327
 140   sends us, this method fails when the ELM327's UART output buffer
 141   overruns. It may abort sending in the middle of the line, which will
 142   then be mistaken for something else.
 143
 144
 145
 146 Known limitations of the driver
 147 --------------------------------
 148
 149 - No 8/7 timing.
 150
 151   ELM327 can only set CAN bitrates that are of the form 500000/n, where
 152   n is an integer divisor.
 153   However there is an exception: With a separate flag, it may set the
 154   speed to be 8/7 of the speed indicated by the divisor.
 155   This mode is not currently implemented.
 156
 157 - No evaluation of command responses.
 158
 159   The ELM327 will reply with OK when a command is understood, and with ?
 160   when it is not. The driver does not currently check this, and simply
 161   assumes that the chip understands every command.
 162   The driver is built such that functionality degrades gracefully
 163   nevertheless. See the section on known limitations of the controller.
 164
 165 - No use of hardware CAN ID filtering
 166
 167   An ELM327's UART sending buffer will easily overflow on heavy CAN bus
 168   load, resulting in the "``BUFFER FULL``" message. Using the hardware
 169   filters available through "``AT CF xxx``" and "``AT CM xxx``" would be
 170   helpful here, however SocketCAN does not currently provide a facility
 171   to make use of such hardware features.
 172
 173 - No BUS-OFF state and automatic restart
 174
 175   We currently reset the ELM327 and generate error frames manually.
 176   In the future, we may be able to use ``can_bus_off()`` and its siblings.
 177
 178
 179
 180 Communication example
 181 ----------------------
 182
 183 This is a short and incomplete introduction on how to talk to an ELM327.
 184
 185
 186 The ELM327 has two modes:
 187
 188 - Command mode
 189 - Reception mode
 190
 191 In command mode, it expects one command per line, terminated by CR.
 192 By default, the prompt is a "``>``", after which a command can be
 193 entered::
 194
 195     >ATE1
 196     OK
 197     >
 198
 199 The init script in the driver switches off several configuration options
 200 that are only meaningful in the original OBD scenario the chip is meant
 201 for, and are actually a hindrance for elmcan.
 202
 203
 204 When a command is not recognized, such as by an older version of the
 205 ELM327, a question mark is printed as a response instead of OK::
 206
 207     >ATUNKNOWN
 208     ?
 209     >
 210
 211 At present, elmcan does not evaluate this response and silently assumes
 212 that all commands are recognized. It is structured such that it will
 213 degrade gracefully when a command is unknown. See the sections above on
 214 known limitations for details.
 215
 216
 217 When a CAN frame is to be sent, the target address is configured, after
 218 which the frame is sent as a command that consists of the data's hex
 219 dump::
 220
 221     >ATSH123
 222     OK
 223     >DEADBEEF12345678
 224     OK
 225     >
 226
 227 The above interaction sends the frame "``DE AD BE EF 12 34 56 78``" with
 228 the 11 bit CAN ID ``0x123``.
 229 For this to function, the controller must be configured for 11 bit CAN
 230 ID sending mode (using "``AT PB``", see code or datasheet).
 231
 232
 233 Once a frame has been sent and wait-for-reply mode is on (ATR1,
 234 configured on listen-only=off), or when the reply timeout expires and
 235 the driver sets the controller into monitoring mode (``ATMA``), the ELM327
 236 will send one line for each received CAN frame, consisting of CAN ID,
 237 DLC, and data::
 238
 239     123 8 DEADBEEF12345678
 240
 241 For 29 bit CAN frames, the address format is slightly different, which
 242 elmcan uses to tell the two apart::
 243
 244     12 34 56 78 8 DEADBEEF12345678
 245
 246 The ELM327 will receive both 11 and 29 bit frames - the current CAN
 247 config (``ATPB``) does not matter.
 248
 249
 250 If the ELM327's internal UART sending buffer runs full, it will abort
 251 the monitoring mode, print "BUFFER FULL" and drop back into command
 252 mode. Note that in this case, unlike with other error messages, the
 253 error message may appear on the same line as the last (usually
 254 incomplete) data frame::
 255
 256     12 34 56 78 8 DEADBEEF123 BUFFER FULL
 257
 258
 259
 260 To Do list for future development
 261 ----------------------------------
 262
 263 - Handle ``write()`` error
 264
 265 - Rename ``elm327_panic()``
 266
 267 - No auto-restart in ``elm327_panic()``?
 268
 269 - Stop current function when in ``elm327_panic()``
 270
 271 - ``if (!elm)``: Race with ``ldisc_close()``
 272
 273 - ``elm->dev``: Race in ``ldisc_ioctl()``
 274
 275 - DMA capable rx/tx buffers
 276
 277 - fixup constants, constant for '``>``'
 278
 279 - flushing of ``tx_work`` is too late in ``ldisc_close()``