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            29 \
  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 - Clone "v1.5" devices
  99
 100   Sending RTR frames is not supported and will be dropped silently.
 101
 102   Receiving RTR with DLC 8 will appear to be a regular frame with
 103   the last received frame's DLC and payload.
 104
 105   "``AT CSM``" not supported, thus no ACK-ing frames while listening:
 106   "``AT MA``" will always be silent. However, immediately after
 107   sending a frame, the ELM327 will be in "receive reply" mode, in
 108   which it *does* ACK any received frames. Once the bus goes silent
 109   or an error occurs (such as BUFFER FULL), the ELM327 will end reply
 110   reception mode on its own and elmcan will fall back to "``AT MA``"
 111   in order to keep monitoring the bus.
 112
 113
 114 - All versions
 115
 116   No automatic full duplex operation is supported. The driver will
 117   switch between input/output mode as quickly as possible.
 118
 119   The length of outgoing RTR frames cannot be set. In fact, some
 120   clones (tested with one identifying as "``v1.5``") are unable to
 121   send RTR frames at all.
 122
 123   We don't have a way to get real-time notifications on CAN errors.
 124   While there is a command (``AT CS``) to retrieve some basic stats,
 125   we don't poll it as it would force us to interrupt reception mode.
 126
 127
 128 - Versions prior to 1.4b
 129
 130   These versions do not send CAN ACKs when in monitoring mode (AT MA).
 131   However, they do send ACKs while waiting for a reply immediately
 132   after sending a frame. The driver maximizes this time to make the
 133   controller as useful as possible.
 134
 135   Starting with version 1.4b, the ELM327 supports the "``AT CSM``"
 136   command, and the "listen-only" CAN option will take effect.
 137
 138
 139 - Versions prior to 1.4
 140
 141   These chips do not support the "``AT PB``" command, and thus cannot
 142   change bitrate or SFF/EFF mode on-the-fly. This will have to be
 143   programmed by the user before attaching the line discipline. See the
 144   data sheet for details.
 145
 146
 147 - Versions prior to 1.3
 148
 149   These chips cannot be used at all with elmcan. They do not support
 150   the "``AT D1``", which is necessary to avoid parsing conflicts on
 151   incoming data, as well as distinction of RTR frame lengths.
 152
 153   Specifically, this allows for easy distinction of SFF and EFF
 154   frames, and to check whether frames are complete. While it is possible
 155   to deduce the type and length from the length of the line the ELM327
 156   sends us, this method fails when the ELM327's UART output buffer
 157   overruns. It may abort sending in the middle of the line, which will
 158   then be mistaken for something else.
 159
 160
 161
 162 Known limitations of the driver
 163 --------------------------------
 164
 165 - No 8/7 timing.
 166
 167   ELM327 can only set CAN bitrates that are of the form 500000/n, where
 168   n is an integer divisor.
 169   However there is an exception: With a separate flag, it may set the
 170   speed to be 8/7 of the speed indicated by the divisor.
 171   This mode is not currently implemented.
 172
 173 - No evaluation of command responses.
 174
 175   The ELM327 will reply with OK when a command is understood, and with ?
 176   when it is not. The driver does not currently check this, and simply
 177   assumes that the chip understands every command.
 178   The driver is built such that functionality degrades gracefully
 179   nevertheless. See the section on known limitations of the controller.
 180
 181 - No use of hardware CAN ID filtering
 182
 183   An ELM327's UART sending buffer will easily overflow on heavy CAN bus
 184   load, resulting in the "``BUFFER FULL``" message. Using the hardware
 185   filters available through "``AT CF xxx``" and "``AT CM xxx``" would be
 186   helpful here, however SocketCAN does not currently provide a facility
 187   to make use of such hardware features.
 188
 189
 190
 191 Communication example
 192 ----------------------
 193
 194 This is a short and incomplete introduction on how to talk to an ELM327.
 195
 196
 197 The ELM327 has two modes:
 198
 199 - Command mode
 200 - Reception mode
 201
 202 In command mode, it expects one command per line, terminated by CR.
 203 By default, the prompt is a "``>``", after which a command can be
 204 entered::
 205
 206     >ATE1
 207     OK
 208     >
 209
 210 The init script in the driver switches off several configuration options
 211 that are only meaningful in the original OBD scenario the chip is meant
 212 for, and are actually a hindrance for elmcan.
 213
 214
 215 When a command is not recognized, such as by an older version of the
 216 ELM327, a question mark is printed as a response instead of OK::
 217
 218     >ATUNKNOWN
 219     ?
 220     >
 221
 222 At present, elmcan does not evaluate this response and silently assumes
 223 that all commands are recognized. It is structured such that it will
 224 degrade gracefully when a command is unknown. See the sections above on
 225 known limitations for details.
 226
 227
 228 When a CAN frame is to be sent, the target address is configured, after
 229 which the frame is sent as a command that consists of the data's hex
 230 dump::
 231
 232     >ATSH123
 233     OK
 234     >DEADBEEF12345678
 235     OK
 236     >
 237
 238 The above interaction sends the frame "``DE AD BE EF 12 34 56 78``" with
 239 the 11 bit CAN ID ``0x123``.
 240 For this to function, the controller must be configured for 11 bit CAN
 241 ID sending mode (using "``AT PB``", see code or datasheet).
 242
 243
 244 Once a frame has been sent and wait-for-reply mode is on (``ATR1``,
 245 configured on ``listen-only=off``), or when the reply timeout expires and
 246 the driver sets the controller into monitoring mode (``ATMA``), the ELM327
 247 will send one line for each received CAN frame, consisting of CAN ID,
 248 DLC, and data::
 249
 250     123 8 DEADBEEF12345678
 251
 252 For 29 bit CAN frames, the address format is slightly different, which
 253 elmcan uses to tell the two apart::
 254
 255     12 34 56 78 8 DEADBEEF12345678
 256
 257 The ELM327 will receive both 11 and 29 bit frames - the current CAN
 258 config (``ATPB``) does not matter.
 259
 260
 261 If the ELM327's internal UART sending buffer runs full, it will abort
 262 the monitoring mode, print "BUFFER FULL" and drop back into command
 263 mode. Note that in this case, unlike with other error messages, the
 264 error message may appear on the same line as the last (usually
 265 incomplete) data frame::
 266
 267     12 34 56 78 8 DEADBEEF123 BUFFER FULL
 268
 269
 270
 271 Rationale behind the chosen configuration
 272 ------------------------------------------
 273
 274 ``AT E1``
 275   Echo on
 276
 277   We need this to be able to get a prompt reliably.
 278
 279 ``AT S1``
 280   Spaces on
 281
 282   We need this to distinguish 11/29 bit CAN addresses received.
 283
 284   Note:
 285   We can usually do this using the line length (odd/even),
 286   but this fails if the line is not transmitted fully to
 287   the host (BUFFER FULL).
 288
 289 ``AT D1``
 290   DLC on
 291
 292   We need this to tell the "length" of RTR frames.
 293
 294
 295
 296 To Do list for future development
 297 ----------------------------------
 298
 299 - DMA capable rx/tx buffers
 300
 301 - flushing of ``tx_work`` is too late in ``ldisc_close()``