Ethernet 1Gbit. Ethernet vs CAN bus

[luiHS]

Hello

Does anyone know if there is an ARM LQFP microcontroller that supports 1 Gbit Ethernet? I have to develop a product with a Raspberry Pi4 as mater, and several slave nodes. Since Raspberry pi4, supports 10/100/1000 Ethernet, if possible I would like to design the nodes with 1Gbit Ethernet.

On the other hand, which is better to use Ethernet or CAN bus?

The product consists of a master (Raspberry pi4), and 4 or maybe 6 slave nodes, at a maximum distance of 150cm between the master and the nodes. For the nodes I planned to use STM32 or RT1020 microcontrollers.

I think CAN bus only allows a maximum speed of 1Mbit, but it seems easier to program than Ethernet. In this application, security issues should not be considered, both the master and the nodes are on the same machine, and communications do not require any type of encryption.

Regards.

[mariush]

Ethernet can do maximum 100 meters between devices.
Just because pi has gigabit, doesn't mean you have to use it.  Also, you could have a network switch near you pi (they cost less than 15$ for a 8 port gigabit switch) ... the switch can take in 100mbps from the micros and pass them to the pi at 1gbps, so pi will continue to have 1gbps.

ALSO .... there's RS 485 , which can probably do 512 kbps or more at 500feet (150 meters) over a twisted pair of wires

See for example: https://www.digikey.com/product-detail/en/maxlinear-inc/XR20M1170IG16-F/1016-1297-5-ND/2411229

[jhpadjustable]

Just 1.5m? If you don't need peer-to-peer communication and can cope with ~1ms of latency, how about USB HS? In which case the EZ-USB FX2 is an easy and not too expensive option for slave nodes with more bandwidth than you will probably need. You can use USB CDC and freely ignore the configured data bit rates without issue.

What are your actual bandwidth needs?

[rounin]

CAN FD can do 12 Mbit during the data section if BRS is turned on. Effective bitrate is somewhat lower, the header is still sent out at 1 Mbps max. From what I hear large networks at 12 Mbits requires some attention & decent wiring, I've only done it that fast in tests on my desk.

CAN is nice for embedded multi-master busses, but for non-fd the protocol efficiency is pretty low (~50%). Its better in FD (closer to ~90%).

[rounin]

Do you need deterministic priorities, or very low packet latency? That is where CAN really shines. For bulk data ethernet/TCP is easier, for bare metal low latency control CAN is better.

[legacy]

Raspberry pi4, supports 10/100/1000 Ethernet

On RPI, the ethernet subsection is attached to the USB. Hence, don't expect a true 1Gbps lan.

[legacy]

I think CAN bus only allows a maximum speed of 1Mbit, but it seems easier to program than Ethernet

bah ... you cannot compare them because the CANbus over Linux is not implemented as a "network" but rather like a serial-link with a datalink on its shoulders.

But, have you already looked at "EtherCat"? This stuff runs on the top of common Ethernet and it's simplified and deterministic networking stuff used in several industries.

[2N3055]

Raspberry pi4, supports 10/100/1000 Ethernet

On RPI, the ethernet subsection is attached to the USB. Hence, don't expect a true 1Gbps lan.

No on PI 4 it is real Ethernet connected directly.

[jhpadjustable]

bah ... you cannot compare them because the CANbus over Linux is not implemented as a "network" but rather like a serial-link with a datalink on its shoulders.

Could you elaborate on this a bit? As far as I can tell it's datagrams all the way down, from the user sendmsg/recvmsg APIs, through the Linux networking framework, through to the device drivers. I certainly don't see anything like a character device or TCP stream connection.

[luiHS]

 
Thanks to everyone, I think it is best to try both options in practice.

All I see is that CAN bus FD is not implemented in many microcontrollers, even some recent ones like the RT1020 do not support it. I would have to use an external SPI controller to access FD, such as MCP2517FD from Microchip.

With Ethernet I only have experience developing some UDP applications. I don't know how complicated it can be to develop a Master-Slaves system, in the RT1020 SDK there are a few examples, I suppose there will also be for Raspberry.

 

[Siwastaja]

bah ... you cannot compare them because the CANbus over Linux is not implemented as a "network" but rather like a serial-link with a datalink on its shoulders.

Could you elaborate on this a bit? As far as I can tell it's datagrams all the way down, from the user sendmsg/recvmsg APIs, through the Linux networking framework, through to the device drivers. I certainly don't see anything like a character device or TCP stream connection.

Indeed, legacy's description doesn't seem to make much sense.

Use socketCan, and the CAN device pops up as a network interface. A C API example found by Google: https://lnguin.wordpress.com/tag/socketcan-example/

For specifics, such as latency, jitter, etc., of socketCan vs. Ethernet (esp. over IP frames), I'm sure someone has done proper benchmarks, but clearly legacy has no such information.

[Siwastaja]

Note that CAN bus is very easy to develop for on MCU, if the MCU has the CAN peripheral. It's typically just a few dozen lines of code bare metal, and you are configured and good to go, with ID filtration, priorized FIFOs and all this set up.

IMHO, the CAN bus will be easier, if you have ample margin on the bandwidth.

[luiHS]

Thank you everybody.

One more question: Can I use RJ45 Ethernet cables for the network with CAN bus devices? I find it as convenient and cheap, but I don't know if they can technically be used.

The idea would be to connect the master to one node, and from each node to the next, with the termination resistor in the latter, using RJ45 Ethernet cables.

[Siwastaja]

Yes, you can definitely use the modular 8p8c ("RJ-45") connector (and widely available CAT-5 or CAT-6 cables) for CAN, and wouldn't be the first one to do so.

I personally used 6p4c ("RJ-14") for a CAN project recently. This is to avoid confusion, so that no one expects them to function as ethernet ports. 6p4c cables are fairly ubiquitous, as well, but the downside is, can be confused with 6p2c ("RJ-11") cables.

CAN is quite robust against impedance mismatches if the cables are up to a few meters.

[hans]

I wouldn't recommended it. Look at the common and differential mode transmission line impedance for CAN and Ethernet, these do not match.

It may work, but can also become a CE/EMC problem.

[legacy]

Indeed, legacy's description doesn't seem to make much sense.
Use socketCan, and the CAN device pops up as a network interface.

I simply mean that "traditional CAN drivers" for Linux are based on the model of character devices, hence it's more similar to a serial device than a network device; I have here all the old CAN bus cards and they are made this way with not too much kernel support. They typically only allow sending to and receiving from the CAN controller but if you need more functionatlities you have to implement them by yourself. I am talking about kernel 2.6 and kernel early 3.* Starting from mid kernel 3.*, kernel 4.* and 5.* there is more support mainstream, but if this is not so stable and mature; the new PF_CAN (this behaves like a true network device, even if limited) can for sure coexists with other protocol families like PF_INET (this IS the network device class usually used for Ethernet) for the Internet Protocol, but it needs more work.

[ejeffrey]

CAN is differential 120 ohm.  Cat 5 is 100 ohm. This isn't enough to get worried about especially on a low speed short range application like most CAN applications.  If you really cared, switch the termination resistors to 100 ohm.  That will minimize reflections at the cost of the driver seeing 50 ohm loads but in all likelihood that will be no trouble.

Remember, CAN needs to operate in an engine bay at crazy high temperatures with sparkplugs firing nearby in environments where failure can kill.  It's stupidly overengineered for most other applications yet relatively cheap due to mass production.  That is why it is so popular.

[rounin]

All I see is that CAN bus FD is not implemented in many microcontrollers, even some recent ones like the RT1020 do not support it.

ST STM32H7xx and NXP S32k14x are probably the best bet for internal hard silicon CAN FD. I've finished a CAN FD design with the H750, and will be doing a S32K144 based design sometime in a few months. H7 seems to have limited package sizes at the moment which is annoying.

Looks like the STM32L5xx has CAN FD too, I guess that just came out recently.

Edit: didn't see you wanted to use the RT1020, yeah those external can controllers seem annoying. Not sure I'd want to bother with them. Depends if you want to switch, the H7 is almost as fast.

[GeorgeOfTheJungle]

Remember, CAN needs to operate in an engine bay at crazy high temperatures with sparkplugs firing nearby in environments where failure can kill.  It's stupidly overengineered for most other applications yet relatively cheap due to mass production.  That is why it is so popular.

No wonder it's a german (Robert Bosch) invention!

[PCB.Wiz]

On the other hand, which is better to use Ethernet or CAN bus?

You have not mentioned the speed you need ? but if CAN is on the short list, it does not sound that high

One more question: Can I use RJ45 Ethernet cables for the network with CAN bus devices? I find it as convenient and cheap, but I don't know if they can technically be used.
The idea would be to connect the master to one node, and from each node to the next, with the termination resistor in the latter, using RJ45 Ethernet cables.

At CAN-region speeds, and short distances, you can use almost any cable.
If you want to send power as well, 8 pins may make sense, and Ethernet cables are common. Just choose the pins for least damage should someone cross plug

If you are going to ring-wire this, you could look at a Standard Serial (UART) Ring link. A UART ring bus decides the address by the Physical place in the ring, so no address switch is needed.
Modern MCU UARTs can manage CAN speeds, and if you code the slaves and what they all do, simpler can be faster and better.
UARTs also allow ANY small MCU choice at the nodes.
Cable drivers can be RS422, RS485 or CAN or Dual CAN etc  - newer CAN drivers can manage to 8MBd (eg MCP25612FD-H/SL)


One appeal of Dual drivers, is you open up other choices too
* you can run 2 links 'both ways' (CW & CCW), so a single break can be detected & even limp-home  (tho a simple link watchdog can drop into a no-RX ping mode, to allow similar break report)
* you can use the second link as a trigger, for precise timing if you need that.
  Using a second UART as the trigger, allows a simple trigger-type tag, and still gives interrupt-precision levels.

[luiHS]

ST STM32H7xx and NXP S32k14x are probably the best bet for internal hard silicon CAN FD. I've finished a CAN FD design with the H750, and will be doing a S32K144 based design sometime in a few months. H7 seems to have limited package sizes at the moment which is annoying.

Looks like the STM32L5xx has CAN FD too, I guess that just came out recently.

Edit: didn't see you wanted to use the RT1020, yeah those external can controllers seem annoying. Not sure I'd want to bother with them. Depends if you want to switch, the H7 is almost as fast.

I've been looking forward to using STM32H7 for a while, but they are very expensive compared to the RT1020, the only advantage they have is a greater amount of RAM, although I could also use the RT1060.

Also in the Chinese, at the moment they do not offer the cheaper H7 than in Mouser. I bring very cheap STM32F407 and Kinetis MK66, other microcontrollers are even more expensive than in Mouser.

[Siwastaja]

Indeed, legacy's description doesn't seem to make much sense.
Use socketCan, and the CAN device pops up as a network interface.

I simply mean that "traditional CAN drivers" for Linux are based on the model of character devices, hence it's more similar to a serial device than a network device; I have here all the old CAN bus cards and they are made this way with not too much kernel support. They typically only allow sending to and receiving from the CAN controller but if you need more functionatlities you have to implement them by yourself. I am talking about kernel 2.6

The fact you use 10-year-old kernels is meaningless.

Others use more recent kernels, and what is "traditional" for you is only confusing to others.

SocketCAN has been there for ages, and at least for me, I consider that "traditional" and "default". YMMV.

Your retro vintage club is cool, but if you want to be helpful instead of confusing, make sure everybody understands that your comments do not reflect the modern reality of the others.

[mariush]

Here's another idea... reuse existing cheap stuff like USB cables.

A USB 3 cable has 3 data pairs and 2 voltage pairs.  Use one pair for incoming, one pair for outgoing, one pair for in/out clock or whatever .. even bit banging would give you megabits of speed, if the controller is fast enough.

[donotdespisethesnake]

Unless you need "real time" comms (i.e. < 5 ms), then use Ethernet. 1GB interfaces should auto-negotiate to 100M, anyway if you have an ethernet network surely you will  have a switch that can do that.

If you need <5ms, use CAN for low data rates. There are plenty of MCUs with CAN. If you really need higher data rates than CAN, and/or scalability to large networks, use EtherCAT. There is only one MCU I know of with native EtherCAT, XMC4300/4800 from Infineon. They really make EtherCAT support easy.

EtherCAT is probably overkill for your application, but since you haven't specified data rates or latency we're all guessing.

[luiHS]

but since you haven't specified data rates or latency we're all guessing.

My application needs to transmit few data, 4 bytes per node, but with the lowest possible latency. Each node will control lamps, coils and read switches, all this has to be done in real time, without delays in the process of each node.

It is probably something similar to the systems of a car, little data exchange between ECUs, but fast response in real time, without delays. It may even be enough 1Mb CAN, but if it is not very expensive I prefer to secure with CAN FD or 100Mb Ethernet.