aboutsummaryrefslogtreecommitdiffstats
path: root/docs/CANBUS_protocol.md
diff options
context:
space:
mode:
authorKevin O'Connor <kevin@koconnor.net>2021-02-07 15:23:19 -0500
committerKevin O'Connor <kevin@koconnor.net>2021-03-13 11:29:41 -0500
commit6cb419a90a9304f2e6d5eae02f0b4b931e9b1fda (patch)
treea3953e94de44a08e53ae6d56733ebbf03d893855 /docs/CANBUS_protocol.md
parent041692828c66cd291435020f240b243c862177bf (diff)
downloadkutter-6cb419a90a9304f2e6d5eae02f0b4b931e9b1fda.tar.gz
kutter-6cb419a90a9304f2e6d5eae02f0b4b931e9b1fda.tar.xz
kutter-6cb419a90a9304f2e6d5eae02f0b4b931e9b1fda.zip
canbus: Rework CAN command protocol
Rework the micro-controller command protocol so that it supports direct communication with the serialqueue.c code. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Diffstat (limited to 'docs/CANBUS_protocol.md')
-rw-r--r--docs/CANBUS_protocol.md65
1 files changed, 65 insertions, 0 deletions
diff --git a/docs/CANBUS_protocol.md b/docs/CANBUS_protocol.md
new file mode 100644
index 00000000..f5e56c74
--- /dev/null
+++ b/docs/CANBUS_protocol.md
@@ -0,0 +1,65 @@
+This document describes the protocol Klipper uses to communicate over
+[CAN bus](https://en.wikipedia.org/wiki/CAN_bus).
+
+# Micro-controller id assignment
+
+Klipper uses only CAN 2.0A standard size CAN bus packets, which are
+limited to 8 data bytes and an 11-bit CAN bus identifier. In order to
+support efficient communication, each micro-controller is assigned at
+run-time a unique 1-byte CAN bus nodeid (`canbus_nodeid`) for general
+Klipper command and response traffic. Klipper command messages going
+from host to micro-controller use the CAN bus id of `canbus_nodeid *
+2 + 256`, while Klipper response messages from micro-controller to
+host use `canbus_nodeid * 2 + 256 + 1`.
+
+Each micro-controller has a factory assigned unique chip identifier
+that is used during id assignment. This identifier can exceed the
+length of one CAN packet, so a hash function is used to generate a
+unique 6-byte id (`canbus_uuid`) from the factory id.
+
+# Admin messages
+
+Admin messages are used for id assignment. Admin messages sent from
+host to micro-controller use the CAN bus id `0x3f0` and messages sent
+from micro-controller to host use the CAN bus id `0x3f1`. All
+micro-controllers listen to messages on id `0x3f0`; that id can be
+thought of as a "broadcast address".
+
+## CMD_QUERY_UNASSIGNED message
+
+This command queries all micro-controllers that have not yet been
+assigned a `canbus_nodeid`. Unassigned micro-controllers will respond
+with a RESP_NEED_NODEID response message.
+
+The CMD_QUERY_UNASSIGNED message format is:
+`<1-byte message_id = 0x00>`
+
+## CMD_SET_NODEID message
+
+This command assigns a `canbus_nodeid` to the micro-controller with a
+given `canbus_uuid`.
+
+The CMD_SET_NODEID message format is:
+`<1-byte message_id = 0x01><6-byte canbus_uuid><1-byte canbus_nodeid>`
+
+## RESP_NEED_NODEID message
+
+The RESP_NEED_NODEID message format is:
+`<1-byte message_id = 0x20><6-byte canbus_uuid>`
+
+# Data Packets
+
+A micro-controller that has been assigned a nodeid via the
+CMD_SET_NODEID command can send and receive data packets.
+
+The packet data in messages using the node's receive CAN bus id
+(`canbus_nodeid * 2 + 256`) are simply appended to a buffer, and when
+a complete [mcu protocol message](Protocol.md) is found its contents
+are parsed and processed. The data is treated as a byte stream - there
+is no requirement for the start of a Klipper message block to align
+with the start of a CAN bus packet.
+
+Similarly, mcu protocol message responses are sent from
+micro-controller to host by copying the message data into one or more
+packets with the node's transmit CAN bus id (`canbus_nodeid * 2 +
+256 + 1`).