Crate canopeners

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

• enums

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
• SdoCmdAbortTransfer
• SdoCmdDownloadSegmentRx
• SdoCmdDownloadSegmentTx
• SdoCmdInitiateDownloadRx
• SdoCmdInitiateDownloadTx
• SdoCmdInitiateUploadRx
• SdoCmdInitiateUploadTx
• SdoCmdUploadSegmentRx
• SdoCmdUploadSegmentTx
• 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

• CanOpenError
• GuardStatus
• 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
• SdoCmdInitiatePayload