On RX buffer overflow, printk remaining input size

[elmcan.git] / readme.rst

diff --git a/readme.rst b/readme.rst
index 408c6911663aeb4c8e9afd8f6c248a3a779bddd9..432843760eea6b78f0c4e956f7c96af93051feff 100644 (file)
--- a/readme.rst
+++ b/readme.rst
@@ -1,12 +1,12 @@
 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
 
-ELM327 driver for Linux SocketCAN
-==================================
+can327: ELM327 driver for Linux SocketCAN
+==========================================
 
 Out-of-tree version
 --------------------
 
-This is the non-upstreamed version of the elmcan driver.
+This is the non-upstreamed version of the can327 driver.
 Please see out-of-tree.rst for compilation/usage hints.
 
 
@@ -40,7 +40,7 @@ Since the ELM327 was never meant to be a stand alone CAN controller,
 the driver has to switch between its modes as quickly as possible in
 order to fake full-duplex operation.
 
-As such, elmcan is a best effort driver. However, this is more than
+As such, can327 is a best effort driver. However, this is more than
 enough to implement simple request-response protocols (such as OBD II),
 and to monitor broadcast messages on a bus (such as in a vehicle).
 
@@ -105,6 +105,20 @@ The line discipline can be attached on a command prompt as follows::
 To change the ELM327's serial settings, please refer to its data
 sheet. This needs to be done before attaching the line discipline.
 
+Once the ldisc is attached, the CAN interface starts out unconfigured.
+Set the speed before starting it:
+
+    # The interface needs to be down to change parameters
+    sudo ip link set can0 down
+    sudo ip link set can0 type can bitrate 500000
+    sudo ip link set can0 up
+
+500000 bit/s is a common rate for OBD-II diagnostics.
+If you're connecting straight to a car's OBD port, this is the speed
+that most cars (but not all!) expect.
+
+After this, you can set out as usual with candump, cansniffer, etc.
+
 
 
 Known limitations of the controller
@@ -122,7 +136,7 @@ Known limitations of the controller
   sending a frame, the ELM327 will be in "receive reply" mode, in
   which it *does* ACK any received frames. Once the bus goes silent
   or an error occurs (such as BUFFER FULL), the ELM327 will end reply
-  reception mode on its own and elmcan will fall back to "``AT MA``"
+  reception mode on its own and can327 will fall back to "``AT MA``"
   in order to keep monitoring the bus.
 
 
@@ -161,9 +175,9 @@ Known limitations of the controller
 
 - Versions prior to 1.3
 
-  These chips cannot be used at all with elmcan. They do not support
-  the "``AT D1``", which is necessary to avoid parsing conflicts on
-  incoming data, as well as distinction of RTR frame lengths.
+  These chips cannot be used at all with can327. They do not support
+  the "``AT D1``" command, which is necessary to avoid parsing conflicts
+  on incoming data, as well as distinction of RTR frame lengths.
 
   Specifically, this allows for easy distinction of SFF and EFF
   frames, and to check whether frames are complete. While it is possible
@@ -224,7 +238,7 @@ entered::
 
 The init script in the driver switches off several configuration options
 that are only meaningful in the original OBD scenario the chip is meant
-for, and are actually a hindrance for elmcan.
+for, and are actually a hindrance for can327.
 
 
 When a command is not recognized, such as by an older version of the
@@ -234,7 +248,7 @@ ELM327, a question mark is printed as a response instead of OK::
     ?
     >
 
-At present, elmcan does not evaluate this response and silently assumes
+At present, can327 does not evaluate this response and silently assumes
 that all commands are recognized. It is structured such that it will
 degrade gracefully when a command is unknown. See the sections above on
 known limitations for details.
@@ -265,7 +279,7 @@ DLC, and data::
     123 8 DEADBEEF12345678
 
 For 29 bit CAN frames, the address format is slightly different, which
-elmcan uses to tell the two apart::
+can327 uses to tell the two apart::
 
     12 34 56 78 8 DEADBEEF12345678