0

I connect a USB to CAN controller via CDC as a virtual port to my computer and interface it via slcan from the can-utils package. So far so good.

What I would like to understand is, why the elinux suggests to use in general 3Mbit/s for the (virtual) serial interface

sudo slcand -o -s8 -t hw -S 3000000 /dev/ttyUSB0

by writing -S 3000000, while the CAN bus speed is set with -s8 to the maximum CAN bus speed of 1 Mbit/s. It describes how the CAN baudrate may be adjusted, but there is no info about the UART baudrate.

The article does not explain, why 3 Mbit/s are selected and I am used to baudrates not being "smooth" (as also seen there: Standard UART rates electronics stackexchange

When I look at the slcand --help enter image description here

I wonder why the UART speed is not listed in the examples at all. What is the default rate?

Can you please help me to understand this?

1 Answers1

0

That depends which CAN controller it is and how it is made.

For a device that does not have an actual UART which you could communicate with, such as a MCU enumerating itself as USB CDC, the baud rate is irrelevant and unused so it does not matter if it is set to any value or not.

In such a case the MCU simply wants to show itself as virtual COM port for sending and receiving data bytes.

So the communicated bytes don't go out on any UART at any baud rate. They are being used to configure and operate a CAN interface to send and receive packets of data.

If you really do implement an actual serial port using a UART of an MCU that enumerates as USB CDC, then you can use the baud rate setting of the VCP to set the baud rate of the MCU UART to be able to select it from the PC. But if you know it must only communicate at for example 9600 BPS for a GPS receiver, then your MCU must ignore the VCP baud rate and keep communicating always at 9600 BPS no matter what baud rate the PC selects.

Justme
  • 147,557
  • 4
  • 113
  • 291
  • thank you! Do you know if it uses CDC is possible to connect it to different serial ports? – spaceKelan Nov 29 '23 at 23:43
  • @spaceKelan Sorry I don't understand what you mean by that. Can you explain more or give an example what you mean? – Justme Nov 29 '23 at 23:49
  • I was confused myself at first, too but I have been asked when I have 1 Desktop computer and 1 USB2CAN controller attached to it, if it is possible to pretend this controller is not connected to a single socket but to multiple ones so certain messages could be split by ID. This would simplify the process for the other person. I don't think this makes any sense, as CAN messages are peer reviewed and even though acceptance filtering occurs on the controller, finer filtering would occur in the software. If it is possible at all, it most likely affect the performance of the physical bus. – spaceKelan Nov 30 '23 at 00:14
  • Additonally,, I do not have access to change the code on the CAN controller.

    ( I just thought I ask, who does not ask never knows)

    – spaceKelan Nov 30 '23 at 00:15
  • You mean like a single physical CAN inteface presenting itself as two USB serial ports like there was two CAN interfaces? Of course that is possible but your device or any framework using your device might not support that. Besides it's simple to do any filtering and responding on the PC side anyway. – Justme Nov 30 '23 at 00:57
  • Yes, oh that's interesting - may you please roughly explain how this could be realized in general for my record? – spaceKelan Nov 30 '23 at 01:09
  • @spaceKelan You have an MCU that has one USB port and it presents itself as multiple USB serial ports and then through each of them you can access a single CAN controller handled by the MCU, which then needs to handle the mapping of different CAN IDs to different virtual COM ports? The only difference is where you do the mapping, i.e. on the MCU and show 4 CAN controllers, or on the PC where software accesses one CAN controller but splits it into 4 tasks like each would see one CAN controller of their own. – Justme Nov 30 '23 at 01:16
  • Thank you @Justme! – spaceKelan Nov 30 '23 at 01:24