Discussion: Standardizing LIN support in Linux (gs_usb extension , Kvaser protocol base)

[AlekseyMamontov]

Hello Marc ( @marckleinebudde ),

First of all, I would like to express my gratitude for everything you do for the open-source community to advance CAN development in Linux and beyond. Your work has been invaluable.

I have a question and would highly appreciate hearing your expert opinion on it (and of course, welcome thoughts from anyone else in the community as well).

With the CAN bus, everything in Linux is now very clear, unified, and beautifully standardized—largely thanks to your efforts.

However, when it comes to the LIN bus, which is conceptually close (it also operates with up to 8 data bytes and an identifier), the situation is a bit of a mess. Everyone tries to invent their own proprietary thing, and there is no unified open-source transport protocol like gs_usb is for CAN.

Right now, I am working on a combined hardware adapter featuring both CAN FD and a LIN interface. On the physical level, it is straightforward.

However, when it comes to reporting raw LIN data back to the host PC, it is completely unclear which open-source protocol to follow to avoid creating yet another non-standard custom solution.

What are your thoughts on implementing native LIN encapsulation support right into the gs_usb protocol specification? This could immediately establish a clean, universal standard for open-source adapters like Candlelight.

Initially, I had an idea to wrap LIN frames and their service metadata (errors, timings, etc.) into CAN messages on the fly.

Interestingly, I recently came across Kvaser's Linux driver implementation (linlib.c / linboot.h), which is dual-licensed under GPLv2 and BSD-new. They already do exactly this—controlling the LIN transceiver and passing bus status through specialized, masked CAN frames. Could this Kvaser layout be considered as a baseline for an open-source standard?
linlib.zip

In general, what is the current vision and roadmap for the LIN bus within the Linux kernel subsystem? Maybe some work or a unified specification already exists and I just haven't found it yet?

If so, please point me in the right direction. I am starting to feel overwhelmed by the sheer number of custom implementation paths, and an expert opinion would help me clear this block.

For reference, the active fork of CANgaroo maintained by Schildkroet (https://github.com/Schildkroet/CANgaroo) now properly supports multichannel CAN FD adapters (even on Windows) and the author is currently working on the LIN display wrapper.

However, there is still a noticeable gap on the transport protocol level providing the raw data for analysis.

Looking forward to hearing your thoughts!

Best regards,
Oleksii
can-module.com

[marckleinebudde]

Hey Oleksii,

for the USB transport the candlelight protocol can probably be extended.

On this years Embedded World trade fair in Nuremberg I talked to @hartkopp and former coworkers. IIRC we talked about someone adding LIN support to some protocol? Oliver can you invite the relevant people here?

Marc

[hartkopp]

Hi,

yes we've been talking to @xeno27 who has been working extensively based on the Linux-LIN (https://github.com/lin-bus/linux-lin) project:

Project	Role in this project
raspberrypi/pico-sdk	RP2040/RP2350 SDK, PIO engine, TinyUSB integration
hathach/tinyusb	USB device stack (CDC ACM)
linux/drivers/net/can/slcan	The kernel slcan line discipline this adapter speaks
linux-can/can-utils	candump, cansend, slcand, slcan_attach, canbusload, …
linux-can/linux-lin	sllin kernel driver and SLLIN protocol – concept reference

which was all based on a RTLWS paper https://github.com/lin-bus/linux-lin/wiki/sllin-rtlws14-paper.pdf

As it turned out to be really tricky to get "real" UART hardware to comply with all the LIN specifics (E.g. sending BREAKS, and changing baudrates to create those LIN things - and especially as it did not work with USB serial adapters - Christoph (@xeno27) decided to build an USB-to-LIN adapter based on a Raspi RP2040/RP2350 hardware with LIN-Transceivers.

The Raspi shows up as a serial device using the SLCAN protocol to send/receive CAN-frames. So it looks like a standard CAN interfaces when using the SLCAN Linux driver.

Based on this "CAN-adapter" the CAN frames sent to this interface and received from it follow the concept and specification from the Linux-LIN paper and implementation. So it is finally an USB-device that speaks the same configuration and data exchange language as the Linux-LIN (sllin) kernel driver that speaks directly to UART hardware (which is not that common in todays PCs). The configuration API is used to send and receive LIN content which requires fast reacting for multiple content IDs inside the Linux kernel or the Raspi.

From the required performance (low bitrates) and the on-chip LIN message handler this approach works pretty fine. Christoph detected many details from real LIN nodes that are hard to cope with.

So adding a binary USB protocol variant for LIN to gs_usb is not the real issue. It is the LIN message management and the LIN tranceiver management to create BREAKs and other weird stuff on the chip. To me the 4€ Raspi hardware together with some LIN transceivers (up to 6 currently supported in the software) is the best approach to have a cheap semi-intelligent LIN USB node.

[AlekseyMamontov]

Hi @marckleinebudde, @hartkopp,

Thanks for the replies! Apologies for the delayed response, as I cannot always answer immediately.

With all due respect to your work, I will look closely into the information and links you provided. However, I am a bit puzzled by the attempts to implement this using basic UART. Modern microcontrollers, specifically the STM32G4 series (which comes with native CAN FD support), feature full hardware LIN capabilities. This completely eliminates the need for software workarounds, such as manual break generation or timing-based break detection, thanks to dedicated hardware registers and interrupts.

STM32G4...LIN.pdf

In reality, what is mostly required from a LIN adapter?

Sniffer mode: Listening to the LIN line and streaming 100% of the raw traffic to the PC for analysis.

Master mode: Sending frame headers and requests to slave nodes (to interact with specific modules).

As for special edge cases: yes, one could additionally implement an on-board master schedule table or a slave response lookup table. But how often is that actually needed in practice? More often than not, people just need to capture raw LIN bus traffic to analyze it, decode it, and later control individual nodes in Master mode. Perhaps I am missing something, but this is how I see it from a practical standpoint.

The adapter should be like a standard Candlelight USB dongle—simple as a brick and built on an affordable, accessible chip. In my view, the STM32G431 is a perfect fit here: it gives you CAN FD + hardware LIN.

Switching between Master and Slave modes is handled easily in software, which includes controlling a GPIO to dynamically toggle the physical 1 kOhm pull-up resistor required for the Master node layout.

Best regards,
Oleksii

[xeno27]

Hi @marckleinebudde @hartkopp @AlekseyMamontov,

I picked up the idea from @hartkopp and @ppisa - I think it's straightforward to reuse the existing CAN infrastructure for LIN and use the higher address bits for controlling "things" like this:

"Extended" ID bit usage

Bit	Hex	Description
0-5	0-0x3F	LIN ID bits
6	0x40	LIN cache response
7	0x80	LIN cache response, extended checksum
8	0x100	LIN single response	(added from linux-lin)
9	0x200	LIN wakeup	(added)
10	0x400	LIN sleep (read only)	(added)
11	0x800	LIN scheduling table entry	(added)
14	0x4000	LIN error: RX timeout
15	0x8000	LIN error: checksum
16	0x10000	LIN error: framing
17	0x20000	LIN error: ID parity	(added)

To send a request from the master that is answered by a slave, we use CAN RTR frames, which makes a lot of sense :)

What I have done so far:

I'm using the existing SLCAN protocol, as it is super simple and fast enough for LIN on an RP2350. The RP2350 exposes 7 USB CDC serial interfaces (6 SLCAN emulations + 1 debug terminal) and runs a LIN state machine. Pretty easy..

A nice side effect of the USB CDC terminal emulation (UART) is that you can easily set up a working environment on Windows with just Python - no driver installation required. So even if you are stuck on a Windows machine without admin rights, you can still work with it perfectly fine. Another big plus: the commands are super simple, so it's really easy to get something up and running quickly.

Here is the protocol reference:

Command	Direction	Description
tIIILDD...\r	Host -> Adapter	Send LIN master frame (header + response)
rIIIL\r	Host -> Adapter	Send LIN header only (RTR - slave responds)
TIIIIIIIILDD...\r	Host -> Adapter	Configure frame-cache entry (EFF format)
RIIIIIIIIL\r	Host -> Adapter	Clear frame-cache entry
O\r	Host -> Adapter	Open channel
C\r	Host -> Adapter	Close channel
B\r	Host -> Adapter	Reboot adapter into bootloader
Sn\r	Host -> Adapter	Set baudrate (ignored - LIN always runs at 19200)
V\r / v\r	Host -> Adapter	Hardware / firmware version
tIIILDD...\r	Adapter -> Host	Received LIN frame
z\r	Adapter -> Host	Transmit acknowledge
\x07	Adapter -> Host	Error (BEL - slcan convention)

If we want, we can switch to a candleLight-style USB connection later. Since the code is modular, we would only have to replace the PC connection part - everything else stays the same.

On the hardware side:

For several reasons I'm using the "great" Raspberry Pi Pico (RP2350): we have them in higher volumes, they have cool features, and we use them in this project anyway. We decided to use the PIO (which is the great thing about the RP2350) to generate the breaks, sync patterns, TX bytes and RX bytes. For capturing (break and sync) I use IRQs, since we need to know if someone sends a break, so we can stop the transmission and fall back to capturing the sync.

At the moment I'm trying to make this project open source, but I need to clarify a few things first (I'm sorry..).

I think the feature set for a candleLight-style "CandleLIN" should be:

• Send RTR frames (which corresponds to master mode)
• Answer RTR frames (which corresponds to slave mode and needs some kind of cached response - I highly recommend using the same logic as in linux-lin)
• Generate wake-up patterns
• Receive wake-up patterns (in master mode this means starting the scheduling table, i.e. sending RTR frames, because a slave wants to tell you something)
• Send frames via a scheduling table (why? Because LIN typically uses repetition times of around 10 ms, so handling the scheduling in the controller makes sense)

With all of these features we are ready for real-world use. If we miss even one of them, we can't cover all LIN use cases (master/slave simulation).

Regarding chip selection (RP2350 vs. STM32), there are good arguments for both. But in terms of accessibility - meaning flashing at home without any additional hardware - the RP2350 wins, as it ships with a UF2 bootloader from the factory, which is very cool.

To sum it up: I'm happy to help if you're interested :)

[AlekseyMamontov]

Hello xeno27 (@xeno27 )

Thanks for replying to this topic! This is highly valuable because silence kills any open-source initiative.

In this case, it would be awesome if this discussion brings some kind of standard for the LIN bus (exchange protocol) into the open-source world, just like the gs-usb driver once did for CAN.

I completely support your idea of using the Extended ID to transfer additional flags (it is distantly similar to how Dronecan handles it, for example). This does not break the CAN message structure itself. An older driver will just pass it through and display it as a regular CAN frame.

Perhaps we should consider introducing a small addition into the new implementation. Within the structure:

C
struct gs_host_frame {
struct_group(header,
u32 echo_id;
__le32 can_id;

	u8 can_dlc;
	u8 channel;
	u8 flags; <----  free bit 
	u8 reserved;
);

We can use an additional bit that indicates that this specific frame must be read as LIN. As I mentioned earlier, this will not break the old driver, but the new software will understand that it should be interpreted as LIN.

This will bring a breath of fresh air (novelty) to the firmware and push everyone toward a single unified standard. At least, that's what I hope for, though there's always someone who will come up with a new reinvented wheel :)

It would be awesome to have native terminal commands in the future, like lindump or linsend — but that's for later.

As for the hardware, we could easily start a holy war here, but I am ready to admit that the Raspberry chip is cooler in terms of CPU cores, while STM32 features native hardware FD CAN and hardware LIN support. This adapter is supposed to be exactly CAN + LIN, after all. The most important thing is not to use a cannon to shoot sparrows.

But let's leave the hardware aside. It's probably more correct to standardize this exactly on the exchange protocol level. To me, the gs-usb driver seems like the perfect place for this, combined with a candleLight firmware that supports LIN.

@marckleinebudde,@hartkopp,@ppisa ,@xeno27
What do you think about this?

[marckleinebudde]

We currently only use 4 bits:

#define GS_CAN_FLAG_OVERFLOW BIT(0)
#define GS_CAN_FLAG_FD BIT(1)
#define GS_CAN_FLAG_BRS BIT(2)
#define GS_CAN_FLAG_ESI BIT(3)

I think we can use BIT(4) for LIN messages.

Also:

#define GS_CAN_FEATURE_FILTER					(1<<16)

use the next feature bit to indicate it's a LIN device.

[AlekseyMamontov]

Hello Marc (@marckleinebudde) ,

Exactly, that’s the way to go. Essentially, it will operate like a multichannel adapter.

During initialization via the GS_USB_BREQ_DEVICE_CONFIG request, the firmware will populate struct gs_device_config and report the total number of channels through the icount field (for example, reporting icount = 1 for 2 channels).

If we have an adapter with 1 CAN and 1 LIN channel, the device reports 2 interfaces in total. Then, by opening channel 1 (the second interface), we can seamlessly work with the LIN bus using the new feature and flag bits.

On older driver versions, this second interface will just appear as a standard Classic CAN channel, ensuring perfect backward compatibility without breaking anything.

What do you think?

[marckleinebudde]

sounds good to me

[AlekseyMamontov]

@xeno27

Let's take your valuable experience and practical background and bring it to a new level within the gs_usb ecosystem and candleLight firmware.

From my perspective, SLCAN is an outdated protocol. It carries too many architectural limitations and generates a lot of redundant text traffic over the USB bus, which becomes highly critical and inefficient for multichannel adapters. As we say around here, paraphrasing a bit: "SLCAN is like an old suitcase without a handle — it’s heavy to carry, and it feels like a waste to throw it away. But maybe it's finally time to drop it? :)"

By integrating this into gs_usb natively, we can handle everything through clean binary structures. The hardware will report its capabilities via feature bits, and frames will be explicitly routed based on channel indexes and dedicated flags. This is the only way to ensure maximum throughput and bulletproof stability when running multiple CAN and LIN channels simultaneously.

[AlekseyMamontov]

The most critical task right now, from my perspective, is to explicitly define the protocol structure — specifically mapping out the flags within the Extended CAN ID layout — and integrate the core functional steps into the firmware to streamline debugging.

We can split this rollout into logical phases:

Sniffer function (Passive Mode): To establish basic bus monitoring so we can visualize and verify incoming frames.

Direct Master Messaging: Implementing immediate master transmission and slave polling commands directly from the host.

Hardware Tables: Gradually adding a Scheduling Table for automatic master polling of slaves, alongside a Slave Cache Table to handle automatic matching responses in Slave mode.

This phased approach allows us to get a working interface up and running quickly while ensuring that advanced features don't overwhelm the initial transport layer design.

Based on this foundation, anyone will be able to easily add and adapt the code for their specific microcontroller inside the firmware ecosystem.

@marckleinebudde,@hartkopp,@ppisa,@xeno27

What do you all think about organizing the implementation this way?

best regards
Oleksii

[xeno27]

Hi @AlekseyMamontov,

thanks for the kind words — and no holy war needed! :)

Just to clarify: I am not specifically advocating for SLCAN or against
gs_usb here. The transport layer is a separate discussion. What I care
about is the bit mapping within the CAN Extended ID for CAN-to-LIN
translation — and this is essentially exactly what linux-lin has been
doing for years already.

For reference, here is the existing linux-lin bit definition — which I
extended with a few additional flags:

Bit	Hex	Description
0-5	0-0x3F	LIN ID bits
6	0x40	LIN cache response
7	0x80	LIN cache response, extended checksum
8	0x100	LIN single response	(added from linux-lin)
9	0x200	LIN wakeup	(added)
10	0x400	LIN sleep (read only)	(added)
11	0x800	LIN scheduling table entry	(added)
14	0x4000	LIN error: RX timeout
15	0x8000	LIN error: checksum
16	0x10000	LIN error: framing
17	0x20000	LIN error: ID parity	(added)

So the de-facto standard already exists and is battle-tested in many
real-world projects. The bit definitions are proven, the concept works
— we just need to align on them rather than reinvent the wheel.

Whether we end up using SLCAN, gs_usb, or something else entirely as
the transport layer — that can be decided later. Let's not let that
discussion block the more fundamental agreement on the protocol
mapping itself. :)

Best regards,
Christoph

[Schildkroet]

Hello,
i think this discussion is a bit mixed about the lin interface. In terms of CAN, you are talking about socketcan vs gs_usb.
Linux-LIN is basically the equivalent of socketcan. While Oleksii wants a USB driver like gs_usb to talk to an external device if i understand the conversation correctly.

My Idea (USB interface for LIN):
Why not create a new LIN equivalent to gs_usb (lin_usb?).
With adding lin to gs_usb, you would still need to update your application to handle everything in the driver and old applications might interpret something false.
With a lin_usb, you also need to write a driver, but at least everything is cleanly separated and it can be tailored perfectly for the needs of lin devices.

[hartkopp]

I think you are mixing up two different levels of communication.

What Linux-LIN is about, is that we use the CAN frames data structure (struct can_frame) to contain LIN frame content, as we have a similar concept of an identifier and up to 8 bytes of data.

https://github.com/lin-bus/linux-lin/wiki/sllin-rtlws14-paper.pdf

The idea to have a CAN frame as representation of LIN frames (where LIN IDs are only 0x00 - 0x3F) is used to be able to work with SocketCAN tools and the SocketCAN programming API. But to meet timing critical responses (e.g. a Linux host acts as a LIN slave and has to answer a LIN master request for a specific LIN-ID within milliseconds) some cache has been implemented that can be filled/configured with LIN control messages where the CAN_EFF_FLAG is set (aka the 29 bit ID flag).

This cache is implemented in the Linux-LIN kernel driver for real UART hardware or alternatively in the Raspi 2350 implementation from @xeno27 , which has the advantage that it works over USB.

So we have created an API that works via Classical CAN frames that can control, send and receive LIN traffic. And this API is working excellent and does not need any re-invention.

OTOH we can now discuss how these Classical CAN frames (which implement the Linux-LIN API) are transferred over USB.
You can either transport CAN CC frames over the native gs_usb protocol or over USB-serial with the SLCAN protocol. The latter has the advantage that you can use it e.g. with Python even on Windows Systems where you don't have admin rights to install additional CAN adapter drivers (USB-serial is commonly available). Due to the 19200 Baud LIN bitrate we also have no performance issue with SLCAN - even with multiple LIN channels on a single USB link.

If you would like to implement the Linux-LIN CAN frame data/configuration API inside a STM CPU - just do it. For this you do not even need to change the USB protocol of the gs_usb driver, as you just need to exchange CAN CC frames, what is already supported. From the host perspective it simply looks like a CAN adapter. If you really need a differentiation you might introduce a new USB device ID. That's all.

[AlekseyMamontov]

Hi @xeno27,

If you are still interested, maybe we can refine the bit mapping table? There seem to be a few typos, or perhaps you had other reasons for this specific layout.

A standard LIN ID is 6 bits wide (0x00 to 0x3F), so it takes up Bits 0-5. This leaves the rest of the field from Bit 6 to Bit 28 completely free for custom flags and errors.

Also, looking at the layout, Bits 12 (0x1000) and 13 (0x2000) are currently skipped and left empty.

Besides the RTR bit (is it really worth using it here?), we also have the choice between Standard and Extended CAN IDs. In the firmware, we could intercept this to separate traffic — for instance, using Standard CAN frames exclusively for Master commands. What do you think?

On GitHub, I have also found LIN-related projects by @jgressmann and @ryedwards who attempted to implement similar functionality.