SeeedBus: Crash occsionally.

[LucienDufour]

Describe the bug

python-can crashes rarely with the error:

    msg = self.bus.recv(0.0)
  File "/nix/store/0amvifzhc5sv3p1b29dzwxd53njs74z3-python3.13-python-can-4.6.1/lib/python3.13/site-packages/can/bus.py", line 121, in recv
    msg, already_filtered = self._recv_internal(timeout=time_left)
                            ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/nix/store/0amvifzhc5sv3p1b29dzwxd53njs74z3-python3.13-python-can-4.6.1/lib/python3.13/site-packages/can/interfaces/seeedstudio/seeedstudio.py", line 279, in _recv_internal
    end_packet = ord(self.ser.read())
TypeError: ord() expected a character, but string of length 0 found

To Reproduce

Use a while true loop to open the device quickly.
For my use-case, I needed to implement a flush_rx_buffer() function on user-level:
Please ignore my comments in the code, they may be outdated.

    def flush_rx_buffer(self):
        """Discarding the received buffer."""
        # As python-can does not implement any discarding of old messages, see:
        # https://github.com/hardbyte/python-can/issues/1721
        # The recv(0.0) is probably a non-blocking function, see:
        # https://python-can.readthedocs.io/en/3.3.2/interfaces/socketcan.html
        # That non-blocking function should return immediately.
        while True:
            msg = self.bus.recv(0.0)
            if msg is None:
                return

Expected behavior

Instead of a TypeError I expected to receive a None.

Additional context

OS and version: NixOS
Python version: 3.13
python-can version: 4.6.1
python-can interface/s (if applicable): seeedstudio

I'm using an asus nuc 15, so quite a fast CPU. I don't remember this error to appear on the slow raspberry pi pico.

Traceback and logs

def func():
    return "hello, world!"

[LucienDufour]

After some investigation I realized that the incoming usb-packets are not "frame-synchronized" (I also see no way to do this in hardware) with the usb-serial converter, so the data is split at arbitrarily positions. A software fix is needed.

The best way to handle this framing issue would probably be a ringbuffer that collects all the new incoming bytes, then processes them as soon as they are correctly processable.

[Luz]

In case anyone is interested, I wrote a POC, which works perfectly for my use-cases:
https://github.com/Luz/seeedcan

Would be nice though, if the idea of "the serial buffer and the independent parsing" could be taken over and integrated to python-can.