Skip to main content

Layered View

Runtime Control Flow

Design Goal

motorbridge separates generic control infrastructure from vendor-specific protocol logic.
  • Core should be reusable across vendors.
  • Vendor crates should contain protocol/register/model differences.
  • ABI should expose stable cross-language entry points.

Repository Layout

Core Layers

1) motor_core

  • bus.rs: CAN bus abstraction
  • device.rs: unified MotorDevice trait
  • controller.rs: scheduling/routing/polling
  • model.rs: model catalog abstraction
  • socketcan.rs: Linux classic SocketCAN backend
  • socketcanfd.rs: Linux dedicated SocketCAN-FD backend
  • pcan.rs: Windows PEAK PCAN backend (experimental)

2) motor_vendors/*

Each vendor crate implements:
  • frame encode/decode
  • register semantics
  • motor model limits
  • controller facade wrapping CoreController

3) motor_abi

  • exports C-compatible handles and functions
  • wraps Rust errors into integer return code + motor_last_error_message()
  • enables C/C++/Python/etc integration

4) SDK/Examples

  • motor_cli: operational/debugging command-line tool
  • bindings/python: reusable Python package for deployment/integration
  • bindings/cpp: reusable C++ RAII wrapper for deployment/integration
  • examples/*: minimal cross-language ABI usage references

Lifecycle Policy

Controller lifecycle is explicit:
  • Use motor_controller_shutdown when you want an explicit stop/disable flow.
  • Use motor_controller_close_bus when you only want to close local session/bus.
  • motor_controller_free now only releases memory/objects.