First Steps using the candleLight
So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.
On our Pi we will be using the October 30th 2021 release of the "Raspberry Pi OS". Once the Pi is booted you should first of all log in and make sure that you have a working internet connection. Once that's done yo can go ahead and install the can-utils packet using apt. can-utils will come in handy for sending and receiving CAN message to/from the CAN bus:
pi@raspberrypi:~ $ sudo apt install can-utils Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: can-utils 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 118 kB of archives. After this operation, 492 kB of additional disk space will be used. Get:1 http://ftp.halifax.rwth-aachen.de/raspbian/raspbian bullseye/main armhf can-utils ar Fetched 118 kB in 1s (161 kB/s) Selecting previously unselected package can-utils. (Reading database ... 40796 files and directories currently installed.) Preparing to unpack .../can-utils_2020.11.0-1_armhf.deb ... Unpacking can-utils (2020.11.0-1) ... Setting up can-utils (2020.11.0-1) ... Processing triggers for man-db (2.9.4-2) ...
If you did not yet connect the CandleLight you should see that the gs_usb driver, that's responsible for handling the CandleLight, has not been loaded. We would also not expect to see any CAN interfaces already present on the Pi. Let's confirm these assumpptions using a few commands on the commandline:
pi@raspberrypi:~ $ lsmod | grep gs_usb pi@raspberrypi:~ $ ip addr show can0 Device "can0" does not exist.
We do however expect both of these things to change once we have connected the CandleLight to the Pi. Let's do so and have a look at the kernel log for confirmation:
pi@raspberrypi:~ $ journalctl -kn9 -- Journal begins at Sat 2021-10-30 12:29:41 BST, ends at Wed 2022-01-19 13:49:39 GMT. -- Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: new full-speed USB device number 4 using xh Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: New USB device found, idVendor=1d50, idProd Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, S Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: Product: candleLight USB to CAN adapter Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: Manufacturer: bytewerk Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: SerialNumber: 000000000002 Jan 19 13:49:39 raspberrypi kernel: CAN device driver interface Jan 19 13:49:39 raspberrypi kernel: gs_usb 1-1.1:1.0: Configuring for 1 interfaces Jan 19 13:49:39 raspberrypi kernel: usbcore: registered new interface driver gs_usb
We can see that the USB device was detected and the gs_usb driver was loaded. But do we also see a CAN interface?:
pi@raspberrypi:~ $ ip addr show can0
5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
Yes we do!
Configuring the Link
A CAN device does not perform the kinds of autonegotiation you've come to expect from regular network devices. Instead we'll have to manually configure some CAN parameters before connecting a CandleLight to an existing bus. If you're lucky this only means setting the bitrate. For a bus operating at 500 kbit/s this can be done using the following command:
pi@raspberrypi:~ $ sudo ip link set dev can0 up type can bitrate 500000
Now we see the status of the can0 CandleLight-Interface is "UP", which means it's started:
pi@raspberrypi:~ $ ip addr show can0
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
With the ip tool we can query CAN specific options:
pi@raspberrypi:~ $ ip -details -statistic link show can0
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group defa
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 48000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 n
RX: bytes packets errors dropped missed mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
The device is in "state ERROR-ACTIVE", which means that it is happily up and running and listening for CAN messages. We also see that it's configured for 500 kbit/s with a sample point of 87.5% (bitrate 500000 sample-point 0.875).
candump
Now let's receive some CAN messages. To do so we are going to start the candump tool and let it decode the incoming messages. In order for it to receive anything there has to be a sending node on the bus, in this case this is just another CandleLight plugged into my laptop:
pi@raspberrypi:~ $ candump any,0:0,#FFFFFFFF -extA (2022-01-19 13:51:50.144617) can0 RX - - 002 [4] 04 00 00 00 (2022-01-19 13:51:50.644835) can0 RX - - 002 [5] 05 00 00 00 00 (2022-01-19 13:51:51.145058) can0 RX - - 002 [6] 06 00 00 00 00 00 (2022-01-19 13:51:51.645290) can0 RX - - 002 [7] 07 00 00 00 00 00 00 (2022-01-19 13:51:52.145435) can0 RX - - 002 [8] 08 00 00 00 00 00 00 00 (2022-01-19 13:51:52.645477) can0 RX - - 002 [1] 09 (2022-01-19 13:51:53.145785) can0 RX - - 002 [1] 0A (2022-01-19 13:51:53.645952) can0 RX - - 002 [2] 0B 00 (2022-01-19 13:51:54.146142) can0 RX - - 002 [3] 0C 00 00 (2022-01-19 13:51:54.646362) can0 RX - - 002 [4] 0D 00 00 00 (2022-01-19 13:51:55.146577) can0 RX - - 002 [5] 0E 00 00 00 00 (2022-01-19 13:51:55.646752) can0 RX - - 002 [6] 0F 00 00 00 00 00 (2022-01-19 13:51:56.146970) can0 RX - - 002 [7] 10 00 00 00 00 00 00 (2022-01-19 13:51:56.647190) can0 RX - - 002 [8] 11 00 00 00 00 00 00 00 (2022-01-19 13:51:57.147229) can0 RX - - 002 [1] 12 (2022-01-19 13:51:57.647433) can0 RX - - 002 [1] 13 (2022-01-19 13:51:58.147653) can0 RX - - 002 [2] 14 00 (2022-01-19 13:51:58.647844) can0 RX - - 002 [3] 15 00 00 (2022-01-19 13:51:59.147993) can0 RX - - 002 [4] 16 00 00 00 (2022-01-19 13:51:59.648122) can0 RX - - 002 [5] 17 00 00 00 00 (2022-01-19 13:52:00.148298) can0 RX - - 002 [6] 18 00 00 00 00 00 ^C
Once you have seen enough you can quit the capture using Ctrl+c.
cansend
Next, let's send some CAN messages, in order to have someone to receive these messages I've started the candump command on my laptop. To send messages instead of dumping them we can use cansend. When starting cansend without arguments it shows some examples how CAN messages are encoded on the command line:
pi@raspberrypi:~ $ cansend
cansend - send CAN-frames via CAN_RAW sockets.
Usage: cansend <device> <can_frame>.
<can_frame>:
<can_id>#{data} for 'classic' CAN 2.0 data frames
<can_id>#R{len} for 'classic' CAN 2.0 data frames
<can_id>##<flags>{data} for CAN FD frames
<can_id>:
3 (SFF) or 8 (EFF) hex chars
{data}:
0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.')
{len}:
an optional 0..8 value as RTR frames can contain a valid dlc field
<flags>:
a single ASCII Hex value (0 .. F) which defines canfd_frame.flags
Examples:
5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311223344 /
1F334455#1122334455667788 / 123#R / 00000123#R3
Let's send the can message with data ff 01 00 00 00 00 00 22 (all values in hex) with CAN-ID 0x023 on our CandleLight:
pi@raspberrypi:~ $ cansend can0 023#ff.01.00.00.00.00.00.22
The command expects the data bytes without spaces, but you can use . for separation. The receiving side shows:
➜ (pts/40) frogger@hardanger:socketcan/linux-rpi (rpi-v5.16) candump any,0:0,#FFFFFFFF -ex (2022-01-19 14:52:31.979395) can0 RX - - 023 [8] FF 01 00 00 00 00 00 22
With the candump and cansend commands most of your CAN sending and dumping needs should be covered. But there is also a third command that comes in handy from time to time.
cangen
The cangen command is used to generate lots of CAN messages. If you start it like shown belong it will send CAN messages with an increasing counter (-Di) with increasing length (-Li), on CAN-ID 2 (-I2) with a gap of 500 ms in between each CAN frame (-g 500). If you try and send more messages than the bus or controller can handle cangen will retry after 10 ms (-g10):
pi@raspberrypi:~ $ cangen can0 -Di -Li -I2 -p10 -g 500
The receiver show this:
➜ (pts/40) frogger@hardanger:socketcan/linux-rpi (rpi-v5.16) candump any,0:0,#FFFFFFFF -ex (2022-01-19 14:52:45.159111) can0 RX - - 002 [1] 00 (2022-01-19 14:52:45.659342) can0 RX - - 002 [1] 01 (2022-01-19 14:52:46.159425) can0 RX - - 002 [2] 02 00 (2022-01-19 14:52:46.659597) can0 RX - - 002 [3] 03 00 00 (2022-01-19 14:52:47.159744) can0 RX - - 002 [4] 04 00 00 00 (2022-01-19 14:52:47.659815) can0 RX - - 002 [5] 05 00 00 00 00 (2022-01-19 14:52:48.159983) can0 RX - - 002 [6] 06 00 00 00 00 00 (2022-01-19 14:52:48.660118) can0 RX - - 002 [7] 07 00 00 00 00 00 00 (2022-01-19 14:52:49.160262) can0 RX - - 002 [8] 08 00 00 00 00 00 00 00 (2022-01-19 14:52:49.660324) can0 RX - - 002 [1] 09 (2022-01-19 14:52:50.160334) can0 RX - - 002 [1] 0A (2022-01-19 14:52:50.660485) can0 RX - - 002 [2] 0B 00 (2022-01-19 14:52:51.160733) can0 RX - - 002 [3] 0C 00 00 (2022-01-19 14:52:51.660876) can0 RX - - 002 [4] 0D 00 00 00 (2022-01-19 14:52:52.161052) can0 RX - - 002 [5] 0E 00 00 00 00 (2022-01-19 14:52:52.661169) can0 RX - - 002 [6] 0F 00 00 00 00 00 (2022-01-19 14:52:53.161308) can0 RX - - 002 [7] 10 00 00 00 00 00 00 (2022-01-19 14:52:53.661451) can0 RX - - 002 [8] 11 00 00 00 00 00 00 00 (2022-01-19 14:52:54.161489) can0 RX - - 002 [1] 12 (2022-01-19 14:52:54.661626) can0 RX - - 002 [1] 13 (2022-01-19 14:52:55.161793) can0 RX - - 002 [2] 14 00 (2022-01-19 14:52:55.661923) can0 RX - - 002 [3] 15 00 00 (2022-01-19 14:52:56.162071) can0 RX - - 002 [4] 16 00 00 00 (2022-01-19 14:52:56.662295) can0 RX - - 002 [5] 17 00 00 00 00 (2022-01-19 14:52:57.162353) can0 RX - - 002 [6] 18 00 00 00 00 00 (2022-01-19 14:52:57.662560) can0 RX - - 002 [7] 19 00 00 00 00 00 00
And will continue to do so, until we stop it or the sender. Next up: figure out where the CAN bus of your CAR is and which bit rate is uses. Given what you've learned you should be well prepared to dump the messages on its CAN buses. The rest is left as an exercise to the reader.
Weiterführende Links
Update des Remotelab Equipments
If it looks like a Werbe-Blogpost, reads like a Werbe-Blogpost … it probably is a Werbe-Blogpost! Niemand möchte gerne Werbung lesen, und wir schreiben sie auch gar nicht so gerne, aber wie alle stolzen Eltern möchten wir Ihnen gerne die neuen Produkte vorführen, die unsere Unternehmens-Tochter, die Linux Automation GmbH, frisch in ihren Shop aufgenommen hat. Mit diesen neuen Produkten ergänzen wir, und vielleicht auch bald Sie, unsere Remotelab-Infrastruktur.
Lab-Automatisierung mit LXA IOBus
Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen, seitdem haben wir viele Normen gelesen, Dinge über Webshops und den Alltag der Elektronikfertigung gelernt und still und heimlich an neuen Produkten getüftelt. Heute möchte ich das LXA IOBus-System vorstellen, bestehend aus einem CAN-basierten Kommunikationsprotokoll, einem zugehörigen Gateway-Server und einer neuen Klasse an Linux Automation GmbH Produkten. Zwei dieser neuen Produkte sind der Ethernet-Mux und das 4DO-3DI-3AI Input/Output-Board.
Der USB-SD-Mux ist nun FAST
Seit 2019 vertreiben wir mit unserer Partner-Firma Linux Automation GmbH den USB-SD-Mux. Damit konnten wir vielen Embedded Entwickler*innen die Arbeit erleichtern und dadurch die Softwarequalität verbessern. Zugleich schreitet die Technik voran: Micro-SD-Karten werden schneller und mittlerweile hat sich USB-C als Standard etabliert.
Linux Automation's Optick: A Glass-to-Glass Latency Measurement Tool
New Linux Automation GmbH products are often inspired by needs we observe in our day-to-day development work at Pengutronix. Today's new product, the Optick, was inspired by our graphics team, that works with different kinds of video pipelines and optimizes them based on customer demands. One such demand is minimizing the latency of camera to display video pipelines.
candleLight FD - Open Hardware USB-to-CAN-FD interface
This week Linux Automation has released a CAN-FD version of the low-cost USB-to-CAN interface candleLight: the candleLight FD. And as the candleLight the candleLight FD is Open Hardware. Check the KiCad project on Github.
LXA USB-T1L ❤️ Beagle Play: Exploring Single Wire Ethernet
It seems everybody is talking about Single Pair Ethernet (SPE) these days. So we want to follow the trend and do the same :-) SPE is a class of Ethernet transmission standards that uses just a single pair of twisted pair cable for data transmission. There are multiple SPE variants spanning maximum data rates from a hand full MBit/s to multiple GBit/s and cable lengths from a hand full of meters to kilometers. The most interesting ones from our embedded-centric point of view are 10Base-T1L (point-to-point, up to 1 km), 10Base-T1S (multidrop, approx. 10 m) and 100Base-T1 (point-to-point, 15 m). The new Beagle Play comes with a 10Base-T1L PHY. This makes it a great peer to experiment with our Linux Automation USB-T1L. In this post we will explore the possibilities of 10Base-T1L on a recent Linux system.
Yes we CAN... add new features
Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?
DSA in Barebox
The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.
Did you know? Initializing CAN interfaces with systemd-networkd
End of January systemd 250 was added to Debian bullseye backports. With a lots of new features and fixes now comes the possibility to set the timing of CAN bus interfaces with systemd-networkd. In this blogpost I will take a look at why this helps us maintain our embedded Linux labs.