USB protocol improvements: multi-frame aggregation, ...

[marckleinebudde]

First of all, I have to say that CANable-2.5-firmware-Slcan-and-Candlelight is a very excellent project. However, the author @Elmue seems not to have the intention to adapt its optimized version of the gs_can protocol (ElmueProtocol) for the mainline Linux yet. While the maintainer @marckleinebudde of candleLight_fw is actively improving the gs_usb for the mainline Linux. Can we discuss about the features other than echo_id (those that Elmue has already implemented) and the optimization of multi-frame aggregation (currently, gs_usb only supports transmitting one frame in a single USB packet)? I am very interested in CAN and CANFD. Therefore, if it is possible to promote the improvement of the gs_usb protocol, I would be very willing to spend time contributing to this project and the mainline kernel driver.

Originally posted by @zhangjiance in #50

[marckleinebudde]

Yes!

[marckleinebudde]

To improve the USB protocol there are several options:

1. optimize struct gs_host_frame:
   • move time stamp to the front
   • only send used data (not full struct gs_host_frame)
2. more efficient echo frame handling
3. multi-frame aggregation

From the Linux driver point of view, these all can be implemented independently from each other.

[marckleinebudde]

I have a stm32h7rx on my desk, which supports USB-High speed. That means 512 bytes per USB transfer. This device would benefit from multi-frame aggregation.

[marckleinebudde]

@zhangjiance, do you have more optimization ideas?

I think best would be to pick 1. or 2. from #271 (comment) and implement a draft on the firmware side. Then look at the code and discuss things.

[zhangjiance]

do you have more optimization ideas? I think best would be to pick 1. or 2. from #271 (comment) and implement a draft on the firmware side. Then look at the code and discuss things.

I don't have additional optimization ideas at the moment. I have both CANable 1.0 and CANable 2.0 with me. Although neither of them supports USB high-speed, this does not affect our ability to optimize the protocol itself. I do intend to start with some optimization attempts on the firmware side, and run functional as well as compatibility tests first.

honestly, the most troublesome part will likely be maintaining backward compatibility with the old protocol.

[marckleinebudde]

Sounds good. Add a new GS_CAN_FEATURE_ for every new feature.

I think the easiest feature would be more efficient echo handling.

[marckleinebudde]

FTR: see Elmue/CANable-2.5-firmware-Slcan-and-Candlelight#24 for further discussion

[Elmue]

My new firmware can aggregate up to 2048 byte and up to 250 frames in one BLOB (Binary Large Object) that is sent over USB.
This feature must be enabled with the flag ELM_DevFlagSendUsbBlobs.
It works for Tx frames and for Rx frames.
The C++ demo project shows how to use it.
The C++ demo project contains a class Candlelight from which I have stripped all the Windows specific stuff into a separate class in the latest version. If someone here modifies this code for Linux you are ready to use my firmware on Linux in a reusable class.

This Candlelight class implements:

• Detect and enumerate all connected Candlelight devices
• Obtain details about the connected device: USB descriptor, board, processor, version numbers,.....
• Set baudrate and samplepoint
• Set host filters / set bridge filters
• Open / Close / Start / Reset / Identify / Busload Reports
• Send packet / Send blob / Receive packet / Receive blob / Process Tx echo marker
• Decode and display CAN bus errors
• Use of multiple CAN channels
• Disable boot pin / Enter DFU mode
• Write and read user data to the flash memory

It works perfectly.
It does not need USB High speed. Also USB Full speed takes advantage of the blobs.
Blobs are automatically sent by the firmware when there is more than one frame waiting in the USB FIFO while another frame is being sent to the host computer.

Here you see a payload of 4 bytes and all the USB overhead to send.
The overhead is the same if you send 4 bytes payload or 64 bytes payload.

As soon as Oleksii sends me his new High Speed adapter I will implement USB High Speed support for the STM32H723

[Elmue]

How are the multi-frame blobs composed?
I chose a protocol that uses as few bytes as possible:

The Blob Header is only 2 bytes long. It precedes the composed blob packet:

• Byte 00: Count of frames in the blob
• Byte 01: Type of USB message = MSG_TxBlob, MSG_RxBlob
• Byte 02 ... Byte XX: blob payload = multiple frames

After that come the frames which are also designed to use the smallest amount of bytes that is possible:

A Tx blob sent from host to firmware may contains multiple Tx frames

A Rx blob sent from firmware to host may contain multiple Rx frames, Tx echo markers, ASCII messages, Error reports, busload reports and any message that may be added in the future.

All the frames that follow after the blob header share the same frame header

• Byte 00: Total count of bytes in the frame (including the header)
• Byte 01: Type of USB message = MSG_TxFrame, MSG_TxEcho, MSG_RxFrame, MSG_Error, MSG_String, MSG_Busload
• Byte 02 ... Byte XX: frame payload

---

Also the Rx frames and Tx frames are designed much more efficiently than the legacy frames designed by the Schneider brothers.
Instead of sending a fake echo ID of 32 bit, which is nonsense, I use only 8 bit for the echo marker.
Instead of wasting one byte for the DLC my code calculates the DLC from the count of bytes in the frame.
Instead of transmitting one byte for the channel number my protocol uses a different USB endpoint for each channel which also has the advantage that 2 completely different applications can open the same multi-channel adapter at the same time, each application opening another USB interface and working on the same adapter totally independently.

typedef struct 
{
    kHeader  header;     
    uint8_t  flags;         
    uint32_t can_id;     
    uint8_t  marker;  
    uint8_t  data_start[0]; 
} __packed __aligned(1) kTxFrameElmue;


typedef struct 
{
    kHeader  header; 
    uint8_t  flags;  
    uint32_t can_id;
    uint8_t  data_no_stamp[0];
    uint32_t timestamp;  
    uint8_t  data_use_stamp[0];
} __packed __aligned(1) kRxFrameElmue;

---

Oleksii plans to add support for LIN bus.
For LIN bus or any other future feature new frame types will be needed.
This is easily possible with the ElmüSoft protocol.
This is totally impossible with the GS protocol.

There is a very important feature that the Schneider brothers did not even think about:
How to design a protocol that can easily be expanded in the future ?
The legacy protocol offers NO WAY to expand it to future needs, therefore the only way I had was to completely replace it with a new protocol that meets modern standards.

---

Marc wrote:

1. optimize struct gs_host_frame:
2. move time stamp to the front
3. only send used data (not full struct gs_host_frame)
4. more efficient echo frame handling
5. multi-frame aggregation

Why do you want to make changes to the legacy gs_host_frame ?
I cannot see any will to walk one single step forward.
You want stay stuck in the past.
You want to add workarounds to a protocol that was misdesigned from the first day.
Why is nobody of the Linux guys willing to throw a crap protocol into the dust bin an start over with a completely new protocol that can easily be expanded in the future?

I wrote a completely working and tested C++ Candlelight class that can be adapted to Linux.
https://github.com/Elmue/CANable-2.5-firmware-Slcan-and-Candlelight/blob/main/SampleApplication%20C%2B%2B/Source/Candlelight/Candlelight.cpp

I bet that in 10 years in the future Linux will still be stuck with this misdesigned legacy GS protocol.
Real progress is not wanted in the Linux world.