DEV Community

Pkuyo
Pkuyo

Posted on

CanKit: a unified c# API for CAN bus (looking for testers & feedback)

#csharp #showdev #iot #automotive

Why I’m building this

When you jump between different CAN adapters, each SDK has its own model, types, and quirks. I wanted a single, clean API that lets you open a bus, send/receive frames, set filters, and do periodic TX—without rewriting everything for each vendor. That became CanKit.

What works today

  • One API surface for classic CAN 2.0 and CAN-FD
  • Open by endpoint strings or typed helpers; enumerate endpoints
  • Sync/async I/O, basic events (frame received, errors), filtering (mask/range), and periodic transmit
  • Adapters: PCAN-Basic (Peak), Kvaser CANlib, SocketCAN (Linux), ZLG
  • Targets: .NET Standard 2.0 and .NET 8

Note: Some behaviors vary by adapter (timeouts, hardware filters, error frames, periodic TX). The docs call out some differences and fallbacks.

Quick start 

using CanKit.Core;
using CanKit.Core.Definitions;

// Open a bus (example: SocketCAN) and set classic bit timing
using var bus = CanKit.Core.CanBus.Open(
    "socketcan://can0#netlink",
    cfg => cfg.TimingClassic(500_000));

// Send a classic CAN frame
var frame = new CanClassicFrame(0x123, new byte[] { 0x11, 0x22, 0x33 });
bus.Transmit(new[] { frame });
Enter fullscreen mode Exit fullscreen mode

If you prefer strongly-typed helpers, some adapters have them (e.g., Kvaser).

Roadmap / Where I need help

  • Broader device coverage & validation across OSes
  • Sharper adapter-specific docs and samples
  • Edge cases around timeouts/filters on certain devices

I’m actively improving things; bug reports, device notes, and PRs are super welcome.

How you can help

  • Try it with your adapter(s) and share logs or findings
  • Open issues for missing features, confusing docs, or rough edges
  • Send PRs—even small ones (typos, samples) help a lot
  • Suggest real-world use cases I should cover in samples

Links

Top comments (0)