Getting started
To get started with the basics of communication with the Karbon units, the Karbon command line utility can be downloaded for Linux and Windows systems.
This utility will allow you to work the the Karbon Microcontroller which is responsible for the native CAN Bus functionality on the unit. No additional drivers need to be installed to work with the native CAN bus on the system. Although additional python libraries will be needed if you wish to develop python scripts to utilize the native CAN Bus
Connectivity
For this tutorial there will be a K300 running Windows 10 IoT and a K300 running Ubuntu 20.04 with a cable connecting the two units via the CAN Bus port located on the side of the chassis.

The Karbon’s internal CAN device should be attached directly to a CAN Bus, but features no internal termination. Because of this, for proper operation, it may be required to implement an external termination resistor. This resistor should match the nominal impedance of the cable; typically 120Ω, which complies with ISO 11898.

Using Karbon CLI utility to send CAN Messages on Linux
After downloading and extracting the Windows directory from the Karbon Microcontroller Utility, open command prompt and navigate to the directory containing the Karbon.exe CLI utility. From here you can use the command karbon.exe raw devices to query which Virtual COM port in the OS is handling CAN messaging.

We can then use PuTTY to open the CAN interface port and now the PuTTY terminal is listening to the CAN interface of the Microcontroller.
On the Linux system, we can extract the Karbon MCU utility’s Linux directory and navigate to it. Running the Karbon utility with sudo, we can send normal CAN Frames over the systems CAN Bus using the sudo ./karbon op can-message -i 123 -d 11223344 command

The Windows machine’s PuTTY Window will receive and present the sent CAN message

Using Karbon CLI utility to send CAN Messages on Windows
The linux Karbon CLI utility can report which /dev/ address is handling CAN communication with the command sudo ./karbon raw devices


The CAN interface can be opened with an elevated PuTTY command to listen for CAN messages.
On the Windows system using an elevated command prompt, CAN messages can be sent utilizing the karbon op can-message -i 123 -d 11223344 command.

The CAN message will show up on the Linux system’s PuTTY window

Karbon Utility
The can
subcommand supports interfacing with and controlling the onboard CAN device. This includes sending and
receiving CAN messages and setting the baudrate of the CAN Bus. This module requires the CAN device be
configured standard operational mode. The mode of the CAN device is controlled by the
can-mode configuration parameter.
The CAN device does not support internal termination, and should be externally terminated when connected to a CAN bus.
By default, the can
subcommand will first check the operational mode before sending a command. Because this is
slower than just sending or receiving can messages, and requires access to the terminal port, it can disabled with
the --nocheck
flag.
$ karbon can -n <COMMAND>
Additionally all can operations support setting the baudrate before processing the command. This requires access to the terminal serial interface, and does not change the baudrate that will be loaded at system boot. If no baudrate is specified, the last transmitted baudrate will continue to be used.
$ karbon can -b 500 <COMMAND>
The baudrate is specified in Kbits/s, and supports setting rates from 100-1000.
Can Commands
Send
The send
command supports sending standard, extended, and remote frames. All messages require an id. Standard
and extended frames also require data. Standard frames are sent by default, while extended and remote frames can
be sent by using the corresponding flag.
$ karbon can send [FLAGS] [OPTIONS] <identifier> [data]
Argument | Description | Type |
---|---|---|
|
The data to be transmitted, represented as an up-to eight byte hex string. Passed data will be checked for
validity before transmission. This argument is required, except when sending remote request frames ( Example
|
|
|
The ‘id’ of the can frame. Should be specified as hex string from Lower numbered frames will have priority during message arbitration, and by default, the id will be interpreted as a standard frame id. Validity checking will be performed against the hex string and id range. |
|
|
Send message in extended frame format. Supports larger id range. Example
|
|
|
Length of data to be transmitted. If not specified, the data length will be automatically determined. Example
|
|
|
Send a remote frame. When specified, Example
|
|
Dump
The dump
command supports reporting all received CAN messages. Messages may be filtered by id
, and the time
between frames can be recorded.
By default, the messages will be formatted and printed to stdout
, but the data can also be reported in csv
format and/or saved to file.
For instance, to print all messages to the terminal along with their time delta, run:
$ karbon can dump -d
Or to log only messages with a matching id to messages.csv
, run:
$ karbon can dump -d -c -f 123 7FF -- messages.csv
karbon can dump [FLAGS] [OPTIONS] [--] [output]
Argument | Description | Type | ||
---|---|---|---|---|
|
Format the output as a csv. Does not redirect output from Example
|
|
||
|
Log the time delta between frames. Times will be reported as floating point seconds; 1.001 is 1001 milliseconds. Time delta is calculated at the host, and should not be considered a perfect representation of time between frames. Example
|
|
||
|
A list of CAN frame identifiers to match received messages against. All other messages will be discarded.
Example
|
|
||
|
The output location for printing CAN frames. Defaults to |
|