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?
This is what happened when community member John Whittington debugged a CAN bus with his own fork of the original CandleLight Hardware design. He found that candump -H -t a only shows zeros in the hardware timestamp field, even though the firmware supports timestamping and opened an issue on github. While with conventional closed source products, this is the point where this story would end, for an open source project, this is where a journey starts. So let us have a look on how the firmware and driver of the open hardware project CandleLight got hardware timestamping support in a joint effort of community members.
Some stuffed bits of history
As for all good tales, the CandleLight's story begins quite some time ago. On Christmas Eve in 2013 (no, I am not kidding you) the first patch to support an USB-CAN adapter built by the company Geschwister Schneider UG was posted on the Linux-CAN mailing list. When Hubert Denkmair asked in 2016 on the linux-can mailinglist for an open protocol for USB CAN adapters, Max Schneider himself suggested to use the Geschwister Schneider implementation as a template and just extract the protocol definition from the existing driver and build a compatible device. Hubert Denkmair was hooked and later published his hardware design under the CERN Open Hardware License v1.2 and firmware under MIT License on Github. Over the years, several forks of the original design and the original firmware were added and modified, some featuring different micro-controllers, adding multichannel support or using USB-C.
For precise measurements of the timing behavior on a bus or for running timing protocols on a bus, it is very important to know the exact point in time when a packet (or frame, as they are called in the CAN-universe) is transmitted or received. Most modern Ethernet interfaces and some CAN controllers have this feature, as it is also used to increase the precision of timing protocols such as the Precision Time Protocol PTP on Ethernet or the SYNC protocol on CANopen. This requires the hardware handling the packets to do this measurement as close to the hardware as possible, to minimize jitter in the measurement. The most common method to achieve this is to have a constantly running hardware counter, which is latched into a register on the Receive- or Transmit-complete-interrupt by hardware.
To achieve the lowest possible jitter this latching should be implemented as a feature of the CAN hardware itself and be sampled at a known point in the CAN frame. Sadly the micro-controller in the CandleLight does not support this kind of extra-low-latency hardware timestamping on its CAN Interface. The CandleLight firmware can however add timestamps in its CAN receive interrupt routine, which gives a jitter-performance that is not as good as actual hardware timestamps but miles ahead of the timestamps Linux can generate on the other end of the USB connection, where it hat to travel through several layers of soft- and hardware. For simplicity's sake we will just call these timestamps generated in the firmware hardware timestamps to differentiate them from the timestamps generated in Linux which we will call software timestamps.
To see if your hardware supports timestamping, use ethtool --show-time-stamping <device> which will list the capabilities of your hardware. For a CAN interface with hardware timestamping support the result will for example look like
>ethtool --show-time-stamping can0 Time stamping parameters for can0: Capabilities: hardware-transmit software-transmit hardware-receive software-receive software-system-clock hardware-raw-clock PTP Hardware Clock: none Hardware Transmit Timestamp Modes: on Hardware Receive Filter Modes: all
Teaching an old driver new tricks
While the CandleLight firmware has support for hardware timestamps since 2016, the gs_usb driver used for the CandleLight did not read the timestamps transmitted over USB until recently. The fact that the firmware with hardware timestamping works with an older driver is due to a clever trick in the USB protocol: the protocol has a bit field for indicating additional features. Hardware timestamps is one of these features, but as long as said feature is not supported on both sides, it is simply ignored. This allows for forward and backward compatibility of new firmware and new driver features. With some pointers from the maintainers to other drivers implementing hardware timestamping, John added the required feature and published it on github. This work was also posted on the linux-can mailing list and then finally made its way mainline with the 6.1 kernel release.
The results are quite impressive: John shared some measurement results which show a significant improvement of the hardware timestamps over software timestamps.
In the diagram above the y-axis shows the observed timestamp jitter of the hardware timestamps on the left vs. the software timestamping performed in Linux.
This new feature on the gs_usb driver allows for precise timing measurement, but there is also some other ongoing work in the CandleLight project:
- adding CAN-FD to the firmware (the USB protocol already supports CAN-FD)
- currently the transmit timestamps are generated when the packet is inserted into the TX FIFO. Using the TX Complete Interrupt will increase their precision even more.
- at the moment timestamps have 1µs resolution. The internal micro-controller clock could allow for some more precision, which is to be evaluated.
If you want to participate in these tasks, you are more than welcome, just according to last year's Pengutronix Christmas card motto Send Patches!
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.
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.
Pengutronix at Embedded World 2022
Welcome to our booth at the Embedded World 2022 in Nürnberg!
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.
Wir haben doch etwas zu verbergen: Schlüssel mit OP-TEE verschlüsseln
Moderne Linux Systeme müssen häufig zwecks Authentifizierung bei einer Cloud- basierten Infrastruktur oder einer On-Premise Maschine eigene kryptografische Schlüssel speichern. Statt der Verwendung eines Trusted Platform Modules (TPM), bieten moderne ARM Prozessoren die TrustZone-Technologie an, auf deren Basis ebenfalls Schlüssel oder andere Geheimnisse gespeichert werden können. Dieses Paper zeigt die Nutzung des Open Portable Trusted Execution Environments (OP- TEE) mit der Standardkonformen PKCS#11 Schnittstellen und i.MX6 Prozessoren von NXP als Beispiel.
This week, we started our series of YouTube labgrid tutorials. In the next few weeks we will publish more video tutorials showing you labgrid's features and giving you handy tips and tricks.
Update of our Remotelab equipment
If it looks like an advertising blogpost, reads like an advertising blogpost ... it probably is an advertising blogpost! Nobody likes to read advertisements and we don't like to write them at all, but like all proud parents, we would like to show you the new products that our corporate subsidiary, Linux Automation GmbH, has freshly added to their store. With these new products we, and maybe soon you, will complete (y)our Remotelab infrastructure.
Smart City - vom Rapid Prototyping bis zur Tragfähigen Infrastruktur
Wir wollen zum Bundesweiten Digitaltag am 18.6.2021 das Thema "Smarte Städte" ein bisschen von der technischen Seite beleuchten, aber keine Angst: es bleibt für alle verständlich.
The LXA IOBus line of lab automation devices
I would like to present to you the LXA IOBus, a CAN-based ecosystem consisting of a protocol, a gateway server and new class of Linux Automation GmbH devices, including the Ethernet-Mux and the 4DO-3DI-3AI input/output board.
CLT-2021: Mach es einfach anders!
"Mach es einfach anders!" - unter diesem Motto finden die CLT dieses Jahr im virtuellen Raum statt. Wie auch in den letzten Jahren ist Pengutronix als Sponsor dabei. Anders ist, dass wir dieses Jahr unser eigenes kleines Programm mit spannenden Kurzvorträgen und täglich zwei Quiz-Runden mit tollen Hauptgewinnen mitbringen.