|
| 1 | +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) |
| 2 | +
|
| 3 | +can327: ELM327 driver for Linux SocketCAN |
| 4 | +========================================== |
| 5 | + |
| 6 | +Authors |
| 7 | +-------- |
| 8 | + |
| 9 | + |
| 10 | + |
| 11 | + |
| 12 | + |
| 13 | +Motivation |
| 14 | +----------- |
| 15 | + |
| 16 | +This driver aims to lower the initial cost for hackers interested in |
| 17 | +working with CAN buses. |
| 18 | + |
| 19 | +CAN adapters are expensive, few, and far between. |
| 20 | +ELM327 interfaces are cheap and plentiful. |
| 21 | +Let's use ELM327s as CAN adapters. |
| 22 | + |
| 23 | + |
| 24 | + |
| 25 | +Introduction |
| 26 | +------------- |
| 27 | + |
| 28 | +This driver is an effort to turn abundant ELM327 based OBD interfaces |
| 29 | +into full fledged (as far as possible) CAN interfaces. |
| 30 | + |
| 31 | +Since the ELM327 was never meant to be a stand alone CAN controller, |
| 32 | +the driver has to switch between its modes as quickly as possible in |
| 33 | +order to fake full-duplex operation. |
| 34 | + |
| 35 | +As such, can327 is a best effort driver. However, this is more than |
| 36 | +enough to implement simple request-response protocols (such as OBD II), |
| 37 | +and to monitor broadcast messages on a bus (such as in a vehicle). |
| 38 | + |
| 39 | +Most ELM327s come as nondescript serial devices, attached via USB or |
| 40 | +Bluetooth. The driver cannot recognize them by itself, and as such it |
| 41 | +is up to the user to attach it in form of a TTY line discipline |
| 42 | +(similar to PPP, SLIP, slcan, ...). |
| 43 | + |
| 44 | +This driver is meant for ELM327 versions 1.4b and up, see below for |
| 45 | +known limitations in older controllers and clones. |
| 46 | + |
| 47 | + |
| 48 | + |
| 49 | +Data sheet |
| 50 | +----------- |
| 51 | + |
| 52 | +The official data sheets can be found at ELM electronics' home page: |
| 53 | + |
| 54 | + https://www.elmelectronics.com/ |
| 55 | + |
| 56 | + |
| 57 | + |
| 58 | +How to attach the line discipline |
| 59 | +---------------------------------- |
| 60 | + |
| 61 | +Every ELM327 chip is factory programmed to operate at a serial setting |
| 62 | +of 38400 baud/s, 8 data bits, no parity, 1 stopbit. |
| 63 | + |
| 64 | +If you have kept this default configuration, the line discipline can |
| 65 | +be attached on a command prompt as follows:: |
| 66 | + |
| 67 | + sudo ldattach \ |
| 68 | + --debug \ |
| 69 | + --speed 38400 \ |
| 70 | + --eightbits \ |
| 71 | + --noparity \ |
| 72 | + --onestopbit \ |
| 73 | + --iflag -ICRNL,INLCR,-IXOFF \ |
| 74 | + 30 \ |
| 75 | + /dev/ttyUSB0 |
| 76 | + |
| 77 | +To change the ELM327's serial settings, please refer to its data |
| 78 | +sheet. This needs to be done before attaching the line discipline. |
| 79 | + |
| 80 | +Once the ldisc is attached, the CAN interface starts out unconfigured. |
| 81 | +Set the speed before starting it:: |
| 82 | + |
| 83 | + # The interface needs to be down to change parameters |
| 84 | + sudo ip link set can0 down |
| 85 | + sudo ip link set can0 type can bitrate 500000 |
| 86 | + sudo ip link set can0 up |
| 87 | + |
| 88 | +500000 bit/s is a common rate for OBD-II diagnostics. |
| 89 | +If you're connecting straight to a car's OBD port, this is the speed |
| 90 | +that most cars (but not all!) expect. |
| 91 | + |
| 92 | +After this, you can set out as usual with candump, cansniffer, etc. |
| 93 | + |
| 94 | + |
| 95 | + |
| 96 | +How to check the controller version |
| 97 | +------------------------------------ |
| 98 | + |
| 99 | +Use a terminal program to attach to the controller. |
| 100 | + |
| 101 | +After issuing the "``AT WS``" command, the controller will respond with |
| 102 | +its version:: |
| 103 | + |
| 104 | + >AT WS |
| 105 | + |
| 106 | + |
| 107 | + ELM327 v1.4b |
| 108 | + |
| 109 | + > |
| 110 | + |
| 111 | +Note that clones may claim to be any version they like. |
| 112 | +It is not indicative of their actual feature set. |
| 113 | + |
| 114 | + |
| 115 | + |
| 116 | + |
| 117 | +Communication example |
| 118 | +---------------------- |
| 119 | + |
| 120 | +This is a short and incomplete introduction on how to talk to an ELM327. |
| 121 | +It is here to guide understanding of the controller's and the driver's |
| 122 | +limitation (listed below) as well as manual testing. |
| 123 | + |
| 124 | + |
| 125 | +The ELM327 has two modes: |
| 126 | + |
| 127 | +- Command mode |
| 128 | +- Reception mode |
| 129 | + |
| 130 | +In command mode, it expects one command per line, terminated by CR. |
| 131 | +By default, the prompt is a "``>``", after which a command can be |
| 132 | +entered:: |
| 133 | + |
| 134 | + >ATE1 |
| 135 | + OK |
| 136 | + > |
| 137 | + |
| 138 | +The init script in the driver switches off several configuration options |
| 139 | +that are only meaningful in the original OBD scenario the chip is meant |
| 140 | +for, and are actually a hindrance for can327. |
| 141 | + |
| 142 | + |
| 143 | +When a command is not recognized, such as by an older version of the |
| 144 | +ELM327, a question mark is printed as a response instead of OK:: |
| 145 | + |
| 146 | + >ATUNKNOWN |
| 147 | + ? |
| 148 | + > |
| 149 | + |
| 150 | +At present, can327 does not evaluate this response. See the section |
| 151 | +below on known limitations for details. |
| 152 | + |
| 153 | + |
| 154 | +When a CAN frame is to be sent, the target address is configured, after |
| 155 | +which the frame is sent as a command that consists of the data's hex |
| 156 | +dump:: |
| 157 | + |
| 158 | + >ATSH123 |
| 159 | + OK |
| 160 | + >DEADBEEF12345678 |
| 161 | + OK |
| 162 | + > |
| 163 | + |
| 164 | +The above interaction sends the SFF frame "``DE AD BE EF 12 34 56 78``" |
| 165 | +with (11 bit) CAN ID ``0x123``. |
| 166 | +For this to function, the controller must be configured for SFF sending |
| 167 | +mode (using "``AT PB``", see code or datasheet). |
| 168 | + |
| 169 | + |
| 170 | +Once a frame has been sent and wait-for-reply mode is on (``ATR1``, |
| 171 | +configured on ``listen-only=off``), or when the reply timeout expires |
| 172 | +and the driver sets the controller into monitoring mode (``ATMA``), |
| 173 | +the ELM327 will send one line for each received CAN frame, consisting |
| 174 | +of CAN ID, DLC, and data:: |
| 175 | + |
| 176 | + 123 8 DEADBEEF12345678 |
| 177 | + |
| 178 | +For EFF (29 bit) CAN frames, the address format is slightly different, |
| 179 | +which can327 uses to tell the two apart:: |
| 180 | + |
| 181 | + 12 34 56 78 8 DEADBEEF12345678 |
| 182 | + |
| 183 | +The ELM327 will receive both SFF and EFF frames - the current CAN |
| 184 | +config (``ATPB``) does not matter. |
| 185 | + |
| 186 | + |
| 187 | +If the ELM327's internal UART sending buffer runs full, it will abort |
| 188 | +the monitoring mode, print "BUFFER FULL" and drop back into command |
| 189 | +mode. Note that in this case, unlike with other error messages, the |
| 190 | +error message may appear on the same line as the last (usually |
| 191 | +incomplete) data frame:: |
| 192 | + |
| 193 | + 12 34 56 78 8 DEADBEEF123 BUFFER FULL |
| 194 | + |
| 195 | + |
| 196 | + |
| 197 | +Known limitations of the controller |
| 198 | +------------------------------------ |
| 199 | + |
| 200 | +- Clone devices ("v1.5" and others) |
| 201 | + |
| 202 | + Sending RTR frames is not supported and will be dropped silently. |
| 203 | + |
| 204 | + Receiving RTR with DLC 8 will appear to be a regular frame with |
| 205 | + the last received frame's DLC and payload. |
| 206 | + |
| 207 | + "``AT CSM``" (CAN Silent Monitoring, i.e. don't send CAN ACKs) is |
| 208 | + not supported, and is hard coded to ON. Thus, frames are not ACKed |
| 209 | + while listening: "``AT MA``" (Monitor All) will always be "silent". |
| 210 | + However, immediately after sending a frame, the ELM327 will be in |
| 211 | + "receive reply" mode, in which it *does* ACK any received frames. |
| 212 | + Once the bus goes silent, or an error occurs (such as BUFFER FULL), |
| 213 | + or the receive reply timeout runs out, the ELM327 will end reply |
| 214 | + reception mode on its own and can327 will fall back to "``AT MA``" |
| 215 | + in order to keep monitoring the bus. |
| 216 | + |
| 217 | + Other limitations may apply, depending on the clone and the quality |
| 218 | + of its firmware. |
| 219 | + |
| 220 | + |
| 221 | +- All versions |
| 222 | + |
| 223 | + No full duplex operation is supported. The driver will switch |
| 224 | + between input/output mode as quickly as possible. |
| 225 | + |
| 226 | + The length of outgoing RTR frames cannot be set. In fact, some |
| 227 | + clones (tested with one identifying as "``v1.5``") are unable to |
| 228 | + send RTR frames at all. |
| 229 | + |
| 230 | + We don't have a way to get real-time notifications on CAN errors. |
| 231 | + While there is a command (``AT CS``) to retrieve some basic stats, |
| 232 | + we don't poll it as it would force us to interrupt reception mode. |
| 233 | + |
| 234 | + |
| 235 | +- Versions prior to 1.4b |
| 236 | + |
| 237 | + These versions do not send CAN ACKs when in monitoring mode (AT MA). |
| 238 | + However, they do send ACKs while waiting for a reply immediately |
| 239 | + after sending a frame. The driver maximizes this time to make the |
| 240 | + controller as useful as possible. |
| 241 | + |
| 242 | + Starting with version 1.4b, the ELM327 supports the "``AT CSM``" |
| 243 | + command, and the "listen-only" CAN option will take effect. |
| 244 | + |
| 245 | + |
| 246 | +- Versions prior to 1.4 |
| 247 | + |
| 248 | + These chips do not support the "``AT PB``" command, and thus cannot |
| 249 | + change bitrate or SFF/EFF mode on-the-fly. This will have to be |
| 250 | + programmed by the user before attaching the line discipline. See the |
| 251 | + data sheet for details. |
| 252 | + |
| 253 | + |
| 254 | +- Versions prior to 1.3 |
| 255 | + |
| 256 | + These chips cannot be used at all with can327. They do not support |
| 257 | + the "``AT D1``" command, which is necessary to avoid parsing conflicts |
| 258 | + on incoming data, as well as distinction of RTR frame lengths. |
| 259 | + |
| 260 | + Specifically, this allows for easy distinction of SFF and EFF |
| 261 | + frames, and to check whether frames are complete. While it is possible |
| 262 | + to deduce the type and length from the length of the line the ELM327 |
| 263 | + sends us, this method fails when the ELM327's UART output buffer |
| 264 | + overruns. It may abort sending in the middle of the line, which will |
| 265 | + then be mistaken for something else. |
| 266 | + |
| 267 | + |
| 268 | + |
| 269 | +Known limitations of the driver |
| 270 | +-------------------------------- |
| 271 | + |
| 272 | +- No 8/7 timing. |
| 273 | + |
| 274 | + ELM327 can only set CAN bitrates that are of the form 500000/n, where |
| 275 | + n is an integer divisor. |
| 276 | + However there is an exception: With a separate flag, it may set the |
| 277 | + speed to be 8/7 of the speed indicated by the divisor. |
| 278 | + This mode is not currently implemented. |
| 279 | + |
| 280 | +- No evaluation of command responses. |
| 281 | + |
| 282 | + The ELM327 will reply with OK when a command is understood, and with ? |
| 283 | + when it is not. The driver does not currently check this, and simply |
| 284 | + assumes that the chip understands every command. |
| 285 | + The driver is built such that functionality degrades gracefully |
| 286 | + nevertheless. See the section on known limitations of the controller. |
| 287 | + |
| 288 | +- No use of hardware CAN ID filtering |
| 289 | + |
| 290 | + An ELM327's UART sending buffer will easily overflow on heavy CAN bus |
| 291 | + load, resulting in the "``BUFFER FULL``" message. Using the hardware |
| 292 | + filters available through "``AT CF xxx``" and "``AT CM xxx``" would be |
| 293 | + helpful here, however SocketCAN does not currently provide a facility |
| 294 | + to make use of such hardware features. |
| 295 | + |
| 296 | + |
| 297 | + |
| 298 | +Rationale behind the chosen configuration |
| 299 | +------------------------------------------ |
| 300 | + |
| 301 | +``AT E1`` |
| 302 | + Echo on |
| 303 | + |
| 304 | + We need this to be able to get a prompt reliably. |
| 305 | + |
| 306 | +``AT S1`` |
| 307 | + Spaces on |
| 308 | + |
| 309 | + We need this to distinguish 11/29 bit CAN addresses received. |
| 310 | + |
| 311 | + Note: |
| 312 | + We can usually do this using the line length (odd/even), |
| 313 | + but this fails if the line is not transmitted fully to |
| 314 | + the host (BUFFER FULL). |
| 315 | + |
| 316 | +``AT D1`` |
| 317 | + DLC on |
| 318 | + |
| 319 | + We need this to tell the "length" of RTR frames. |
| 320 | + |
| 321 | + |
| 322 | + |
| 323 | +A note on CAN bus termination |
| 324 | +------------------------------ |
| 325 | + |
| 326 | +Your adapter may have resistors soldered in which are meant to terminate |
| 327 | +the bus. This is correct when it is plugged into a OBD-II socket, but |
| 328 | +not helpful when trying to tap into the middle of an existing CAN bus. |
| 329 | + |
| 330 | +If communications don't work with the adapter connected, check for the |
| 331 | +termination resistors on its PCB and try removing them. |
0 commit comments