There are multiple ways to setup an U2C.
I prefer (like @DrumClock wants to test it now) the way of using the klipper usbcan bridge fw since you use the same sourcecode on your usbcan adapter and the can node.
For the SKrat CAN bus on PD0/1 and PA11/12 are both valid options.
The first setting is for classic CAN_H/L and the second one is for CAN_RX/TX over a pysical usb cable. You can also connect the Octopus boards with both options
This is noted there since for can newbies it is the easier route cause in case of an klipper mcu protocol code change they do not need to reflash the can “adapter”.
That is the U2C bridge and skrat can over usb setup? Interesting problem.
MainsailOS v1.3.2
To test it further can you please try a fresh MainsailOS and upload a printer.cfg with kinematics: none (and some other configs it will complain about)
then you can just add both mcus without anything else.
Try the U2C + one EBB.
Maybe I can find some time testing this next week (just U2C and EBB or U2C and SKR3 canoverusb) too
Okay, I get where this is confusing looking at BTT’s wording here…
That “CAN_OUT*” section about connecting to a USB where is horribly worded and backwards logic. USB is not CAN Bus and CAN Bus is not USB. You cannot have CAN Bus without some sort of CAN Transceiver.
The SN65HVD1050’s have nothing to do with USB, They’re CAN Bus transceivers.
To summarize, The USB “CAN_OUT” on the BTT U2C is junk. Unless you cut open a USB cable and connect the D+ and D- wires to the CAN connection somewhere else, you will not get CAN out of that.
I have zero idea why they tried to implement that. My guess is they were throwing together a board and don’t know how to read datasheets.
Now that the U2C is out of the way.
The SKRat…
The SKRat USB connector is again… JUST a USB connector
Notice what’s omitted from the original pic, The top of the table where it says “ALTERNATIVE FUNCTIONS”
STM32 has pin configurations, in other words, you can change the function of a pin based on your need. Maybe you don’t need CAN Bus… Then that Pin works as USB, or a timer, or a comparator or whatever based on WHAT YOU CONFIGURE IT AS IN THE FIRMWARE.
BTT read this and thought “Oh, It can do ALL OF THESE AT ONCE”
That is NOT. TRUE.
That’s why they did the confusing thing of putting CANBus on a USB connector, because they misread the datasheet.
I agree with you 100000000000000000000000000000000000000%
But it CANNOT do CAN Bus and USB at the same time on the same pins.
Therefore it’s extremely stupid and confusing for them to run CAN Bus over a USB connector.
The SKRat CANNOT do CAN Bus on the USB connection as you are doing it.
You’re focusing on the U2C, ignore the U2C.
The SKRat does not function as you’ve connected it.
You HAVE to use the CAN Bus connector on the right hand side.
@TheFuzzyGiggler Can please understand the difference between CAN_RX/TX and CAN_H/L Otherwise you are lost…
Look how the stm32 is wired to the transreceivers - it talks “serial can” () CAN_RX/TX to the transreceiver - the same signal gets transported by the physical USB cable to the SKrat
As this part of the schematics show it is CAN_RX/TX
CAN_H/L is only available at the Molex Minifit JR and screw terminal
I agree that their choice of USB as the pysical cable is not great.
Newbies think it is USB and connect other boards there and then wonder why it is not working
Also to you: get the difference between CAN_RX/TX and CAN_H/L
Therefore, to use CAN Bus on the SKRat in the way your wiring picture is up top doesn’t work. You HAVE to connect it like you’ve connected the EBB boards using the CAN connector on the right hand side of the board.
Edit:
From the STM32G0B1 datasheet, PD0 and PD1 are FD Can pins, and the MCP2542 is an FD Can transceiver. That’s the pin setup for the SKRat.
That is correct and it does not need a transreciver if U2C PA11/12 and SKrat PA11/12 are connected.
Both STM32G0B1 are talking CAN_RX/TX with each over.
You can configure them to talk either D+/D- or CAN_RX/TX on both ends over the same cable.
Year that is CAN_H/L and they are not using this over the USB.
You have to have a CAN Transceiver as the physical layer and signal conversion/conditioning.
The Microcontroller only sends out digital signaling but CAN Bus is differential signaling, CAN Bus requires specific termination and line impedance requirements and biggest of all, They’re wildly different voltages.
CAN RX/TX is just the serial protocol, It always requires a transceiver.
Which the SKRat has, it’s just on different pins than the USB connector.
Edit: Unless you’re saying the U2C and SKRat are trying to communicate with each other via their CAN Bus RX/TX lines? Maybe that’s where I’m getting lost at and that’s janky as hell.
… How is it handling the dominant/recessive bit issues and bus contention?
99% sure that’s not how that is meant to work, logically or via STM32 documentation.
But oh well. I give up on this one.
Carry on.
Edit: I guess the consensus is that it CAN (see what I did there?) be done, but there is zero noise immunity and it’s really finicky and requires ultra short wiring and fast diodes.
No wonder people have issues with BTT boards and CAN Bus in all the forums.
Well, I would call that not functional. I expect it will be unstable in that configuration, even beyond reboots.
I recommend returning to a more standard setup. If you want to use the CAN protocol, then deploy CAN transceivers on all the target devices. If you want to use USB wiring, then wire them to USB ports. I would definitely avoid running any CAN signalling over USB wires.
So, if you want to run a USB wire to the SKRat then use a USB wire directly to the RPi and use standard USB communication over those wires.
You definitely do not want to run CAN RX/TX over long lines. It is definitely not valid to wire multiple devices to the same CAN RX/TX wires (these wires are not a “bus” - they are only point-to-point and intended for short distances).
Hi, the fact that the “Chinese” used a USB cable for CAN bus transmission is their “fast needle”.
However, this does not change the fact that when using the U2C converter, the CAN bus is brought via this cable in the same way through the SN65HVD1050PR converter to the STM32G0B1xx pins as it is with the EBB42.
So I don’t see a single reason why it shouldn’t work if I set CAN communication via PA11/PA12 (USB-C connector) in “make menuconfig” for SKRat.
The only thing in the way (and it’s different than the EBB42) is the USBLC6-2SC6 diode array to protect the USB-C connector.
@koconnor
I wonder if this diode array can cause CAN bus protocols to malfunction?
Can I ask a question as I’m curious about the psychology of what’s going on here.
The background is:
You do not have a stable CAN connection. You claim that it works initially but it does not survive host reset/power cycle.
@TheFuzzyGiggler has tried to explain at length that there is a problem with your understanding of how CAN and USB are wired on the U2C and main controller board.
@hcet has expressed concerns about how you are doing things.
I told you that the wiring wasn’t correct.
The creator of Klipper, @koconnor has called your method “not functional”.
My question is: at what point will you accept that your approach is wrong?
Otherwise you are lost…
USB cable to the SKrat
