Expand description
§Canopeners
Partial implementation of a CANOpen client 🔪🥫 on top of socketcan Examples in readme
§CANOpen
As a layer 1 and 2 protocol, CAN does not support addressing - all messages arrive at all nodes. CANOpen mainly adds addressing (layer 3) support to CAN in a standardized way. All CANOpen nodes have an ID, there’s a standard way to address a message to a node. Various CANOpen specs also include tons of other features, this repo just focuses on CiA301.
§Progress
So far, we have: ✅ rusty types for most CANOpen messages ✅ send/receive messages via socketcan ✅ nice SDO wrapper. we’re still missing: ❌CANOpen node (read/writable Object Dictionary, respecting the OD configs) ❌MPDO support
Modules§
Structs§
- Conn
- CAN connection. Connects on
Conn::new()Writing/reading a single CAN frame is thread safe, since socketcan guarantees atomic frame reads and writes. Multi-frame operations (eg send_acked or sdo_read) are not thread safe as they rely on receiving multiple can frames. - Emergency
- Guard
- Nmt
- Pdo
- Sdo
- SdoCmd
Abort Transfer - SdoCmd
Download Segment Rx - SdoCmd
Download Segment Tx - SdoCmd
Initiate Download Rx - SdoCmd
Initiate Download Tx - SdoCmd
Initiate Upload Rx - SdoCmd
Initiate Upload Tx - SdoCmd
Upload Segment Rx - SdoCmd
Upload Segment Tx - Sync
- Sync messages are usually sent at regular intervals. “Synchronous events” are often driven by sync messages. For example, you can configure PDOs to be sent after every sync message.
Enums§
- CanOpen
Error - Guard
Status - Message
- NmtFunction
- ReqRes
- ReqRes realtive to the device (aka server) Data sent from your computer is probably Rx, since the device is receiving it)
- SdoCmd
- SdoCmd
Initiate Payload