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:
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
Hardware Receive Filter Modes:
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!
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.
Modern software development is commonly accompanied by a version control system like Git in order to have changes to the source code being documented in a traceable manner. Furthermore, any version state should be easily reproducible at any time. However, for work on complex projects such as the BSP ("Board Support Package") of an embedded system with its multiple development aspects, the simple stacking of the individual changes on top of each other does not scale.
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.
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.
Welcome to our booth at the Embedded World 2022 in Nürnberg!
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.
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.
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.