Ethernet 1Gbit. Ethernet vs CAN bus - Page 1
Forum section: electronics / general

author: luiHS
author_rank: Frequent Contributor
timestamp: November 02, 2019, 01:54:44 am
content: HelloDoes 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.

author: mariush
author_rank: Super Contributor
timestamp: November 02, 2019, 02:44:01 am
content: 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 wiresSee for example:https://www.digikey.com/product-detail/en/maxlinear-inc/XR20M1170IG16-F/1016-1297-5-ND/2411229

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: November 02, 2019, 04:56:37 am
content: 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?

author: rounin
author_rank: Regular Contributor
timestamp: November 02, 2019, 05:59:04 am
content: 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%).

author: rounin
author_rank: Regular Contributor
timestamp: November 02, 2019, 06:00:48 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: November 02, 2019, 11:26:33 am
content: Quote from: luiHS on November 02, 2019, 01:54:44 amOn RPI, the ethernet subsection is attached to the USB. Hence, don't expect a true 1Gbps lan.

author: legacy
author_rank: Super Contributor
timestamp: November 02, 2019, 11:31:39 am
content: Quote from: luiHS on November 02, 2019, 01:54:44 ambah ... 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.

author: 2N3055
author_rank: Super Contributor
timestamp: November 02, 2019, 12:03:06 pm
content: Quote from: legacy on November 02, 2019, 11:26:33 amNo on PI 4 it is real Ethernet connected directly.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: November 02, 2019, 01:13:35 pm
content: Quote from: legacy on November 02, 2019, 11:31:39 amCould 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.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 02, 2019, 01:24:06 pm
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 02, 2019, 01:51:03 pm
content: Quote from: jhpadjustable on November 02, 2019, 01:13:35 pmIndeed, 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 02, 2019, 01:53:49 pm
content: Note that CAN bus is very easy to develop for on MCU,ifthe 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.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 02, 2019, 02:14:23 pm
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 02, 2019, 03:05:54 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: November 02, 2019, 03:16:45 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: November 02, 2019, 05:53:05 pm
content: Quote from: Siwastaja on November 02, 2019, 01:51:03 pmI 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.

author: ejeffrey
author_rank: Super Contributor
timestamp: November 02, 2019, 05:54:10 pm
content: 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.

author: rounin
author_rank: Regular Contributor
timestamp: November 02, 2019, 07:04:46 pm
content: Quote from: luiHS on November 02, 2019, 01:24:06 pmST 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.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: November 02, 2019, 08:16:58 pm
content: Quote from: ejeffrey on November 02, 2019, 05:54:10 pmNo wonder it's a german (Robert Bosch) invention!

author: PCB.Wiz
author_rank: Super Contributor
timestamp: November 02, 2019, 10:28:58 pm
content: Quote from: luiHS on November 02, 2019, 01:54:44 amYou have not mentioned the speed youneed? but if CAN is on the short list, it does not sound that highQuote from: luiHS on November 02, 2019, 02:14:23 pmAt 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 plugIf 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.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 02, 2019, 11:00:42 pm
content: Quote from: rounin on November 02, 2019, 07:04:46 pmI'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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 03, 2019, 07:36:16 am
content: Quote from: legacy on November 02, 2019, 05:53:05 pmThe 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.

author: mariush
author_rank: Super Contributor
timestamp: November 03, 2019, 08:34:23 am
content: 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 03, 2019, 01:37:06 pm
content: 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.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 03, 2019, 02:44:44 pm
content: Quote from: donotdespisethesnake on November 03, 2019, 01:37:06 pmMy 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.

author: up8051
author_rank: Frequent Contributor
timestamp: November 03, 2019, 04:42:45 pm
content: RS485/RS422 drivers can work up to 50Mbps. Maximum data rates depends on used uP.You can define own short frame (for example START_MARK ADDR DATA_SIZE DATA ... CRC END_MARK)

author: legacy
author_rank: Super Contributor
timestamp: November 03, 2019, 05:49:02 pm
content: Quote from: Siwastaja on November 03, 2019, 07:36:16 amIt's not if you consider the cost of the hardware, and if you consider that a lot of vendors still have support for kernel 3, but not for kernel >= 4.*Quote from: Siwastaja on November 03, 2019, 07:36:16 amIt's how it's defined. Anyway, I will avoid to contribe more here.

author: fchk
author_rank: Frequent Contributor
timestamp: November 03, 2019, 06:25:05 pm
content: CAN FD will give you almost no speed advantage. ID and control bits still use normal CAN speed 1MBit/s, and only for the data field the bitrate switches to a higher rate up to 8 MBit/s (thus FD=Flexible Datarate). The data field can be up to 64 bytes in 8 byte increments, and this is the main advantage of CAN-FD. If you only transmit small packets you can also use 1MBit/s CAN and save money.RJ45 (8p8c) and RJ10 (4p4c) are official cabling standards for CAN defined in CanOpen CiA 303 part 1.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 03, 2019, 06:37:31 pm
content: Quote from: luiHS on November 03, 2019, 02:44:44 pmCAN is likely the easiest and best for this. Sounds like you won't need the full 1 Mbit/s, even. 250 kbit/s is a very widely used baud rate for CAN.

author: L1L1
author_rank: Regular Contributor
timestamp: November 03, 2019, 06:55:58 pm
content: Quote from: luiHS on November 03, 2019, 02:44:44 pmI'm the main designer ofNoCAN: an Arduino-compatible IoT platform based on CAN bus. It's used a lot for exactly your target application: controlrelays,valves, readsensors, etc. In addition, it offers remote firmware updates "over-the-wire", dynamic node address assignment and many interfaces (MQTT, JSON/REST, Blynk, etc.). Though it's "Arduino-compatible", the libraries also work on bare-metal. NoCAN is all open-source so you can fish thecodefor ideas.We wanted something that allowed a single cable to carry power and networking, and CAN bus works well for that. If you use 8-wire UTP cables, you can use one single twisted pair for CANbus and use the remaining 6 wires for power/GND (e.g. 12V or 24V). In this context, another alternative is Power over Ethernet (PoE). In terms of speed, at 100Mbps, PoE blows CAN bus out of the water, even in a noisy environment with tone of retransmissions. However, in terms of cost and complexity, PoE is a beast in comparison with CAN. Also, if you want to do voice or video, then CAN bus is clearly not the right tool. But for sensor data, it's a pretty sweet protocol!

author: e100
author_rank: Frequent Contributor
timestamp: November 04, 2019, 04:42:28 am
content: Quote from: L1L1 on November 03, 2019, 06:55:58 pmInteresting, is all the node programming done via the CAN bus? It kind of looks like it, but I didn't see anything where it said so explicitly.

author: L1L1
author_rank: Regular Contributor
timestamp: November 04, 2019, 07:40:03 am
content: Quote from: e100 on November 04, 2019, 04:42:28 amWell, each node has a special bootloader, and programming is done over CAN bus, using a protocol we defined. In other words, you can write an Arduino sketch in your comfortable office at home and upload the compiled firmware directly to a node sitting in an enclosure in your garden.Check outhttps://www.omzlo.com/articles/uploading-nocan-sketches-directly-from-the-arduino-ide

author: legacy
author_rank: Super Contributor
timestamp: November 04, 2019, 07:56:53 am
content: Quote from: L1L1 on November 04, 2019, 07:40:03 amhow is the CANbus stuff implemented regarding the hardware? I cannot access your website at the moment, I am travelling ...

author: Berni
author_rank: Super Contributor
timestamp: November 04, 2019, 08:40:47 am
content: Quote from: luiHS on November 03, 2019, 02:44:44 pmIf you want to get a small amount of data out with low latency then just use a UART port at a really fast baud rate of 1 to 10Mbit. If it needs to go any distance feed it trough a RS485 transceiver.Sure in principle Ethernet is very low latency but unless you are skilled enough to implement your Ethernet using bare metal C on a RPi you will not get low latency as the OS will be having control over the Ethernet hardware and will execute your wishes when it has time to do it. Anything on USB is the same.CAN is a bit better but you don't have a CAN bus on the RPi so you need to use an external CAN controller that talks via SPI in the best case. This extra communication also takes up latency.But still even then you need to take care in your software on the RPi to force it to give that process exclusive access of one core or the OS scheduler will constantly jump in and interrupt you (It still will, but less). Additionally the UART driver might have some locks and mutexes in place that require the attention of the OS that can add latency spikes if the OS is busy doing something else. So to get the ultimate low latency you also need to ask linux for a direct memory window into the UART controller and write your own driver inside the application.So as you can see a RaspberryPi is really not made for really fast real time tasks with response times mesured in microseconds. But if a few miliseconds of latency are okay then you can use anything you want. You could do that by using a USB to Ethernet dongle going into a switch going into a switch going into a switch going into a switch going into a WiFi rounter going via Coax into a ESP32 WiFi module that outputs via UART into a MCU that finally switches the output and it would make that trip in a few miliseconds.

author: fchk
author_rank: Frequent Contributor
timestamp: November 04, 2019, 01:57:15 pm
content: CAN is a proven bus system that is definitely suitable for your needs.The RPi is the weak point. You really should use a beaglebone, either a blue/black/green or the new AI. Beaglebones have a controller that is much more suitable for realtime/low-latency stuff, and a CAN mac is built-in. You only have to add a CAN transceiver of your choice.

author: luiHS
author_rank: Frequent Contributor
timestamp: November 04, 2019, 05:50:27 pm
content: Quote from: fchk on November 04, 2019, 01:57:15 pmI've tried the Beaglebone Black for quite some time, but I prefer to use the Raspberry pi4, with it I already have some experience and some proven programs, mainly those needed to play videos and audio.What I am thinking about is also using a microcontroller as a master for CAN bus communications, and of this communicating with the Raspberry by serial port for the play of videos, which really is the only thing I want the Raspberry for. So I can ensure low latency, the microcontroller dedicated exclusively to CAN bus, probably an STM32F7, STM32H7 or an RT1020.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: November 05, 2019, 12:15:21 am
content: "As fast as possible" is manager-speak. If you're the engineer it's worthless. On an engineering board, not dimensioning your projects is tantamount to trolling. Let's do someengineering, shall we?So this is for a multimedia performance? I suggest that you don't need minimum latency. You need known, predictable latency. Let's start with figuring out how much latency youneed. To sync with the screen beyond the limits of human perception, one frame time is a good target. Average people can just perceive 1/24 second, which is at least two video frames. For audio, keep in mind that sound takes ~3ms to travel 1m. With a known, predictable latency in the hardware, you can easily change the actual value by moving the speakers back and forth. Since the ear is more sensitive to delay, let's keep it under 3ms. No idea about your solenoids and what they're doing, but I'm sure the time constant is on the order of tens of ms.Just use some bluepills with a USB MIDI or HID device class for 3ms latency easily without really trying.

author: Berni
author_rank: Super Contributor
timestamp: November 05, 2019, 06:31:07 am
content: I agree with jhpadjustable. Sounds like you are unnecessarily constraining your project on super low latency that you don't even need!To trigger a visual effect being as much as 50ms out it will still look instant because the human eyes are not very fast at all. If its triggering an audio effect and you want it to sync closely to the beat of the music then it might be a bit tighter but you still even 1ms latency is overkill for that. Just use whatever bus is convenient for you to use.Also since you know the events in advance means that this thing could still hit spot on timings even with a 2000ms latency communication link that literally wraps around the whole planet before coming back. The trick is to send the events in advance but include timestamps. Then have each node have its own synchronized clock that runs locally and triggers the events when it hits there timestamp. This means the events will fire off however accurately you have the local clocks synchronized even if the latency of the link constantly jumps like 2ms 700ms 40ms 1354ms 400ms 1ms 1ms 600ms... If you use GPS modules to synchronize the clocks you can get the events to fire off to 1 ns accuracy. This is 0.000001ms and that is the time it takes light to travel about 30cm or sound to travel about 400nm (This is 100 times smaller than the thickness of a human hair)But all of this is useless because if you use a regular consumer television to show the video you will get a few frames of latency even if you put it into "game mode". So unless you have at least about 20 to 100ms of latency to your events they will be actually firing of too early compared to the video because of how god awfully slow TVs are.EDIT: By the way the game Guitar Hero on consoles where a fake guitar controller is used to play it, they have put a light sensor inside that guitar controller. This is used during the latency calibration process where you place the guitar against the TV while the screen flashes between black and white. This lets the game measure the latency of your particular TV and later uses it to time shift your controller inputs into the future by this latency to compensate for it.

author: ehughes
author_rank: Frequent Contributor
timestamp: November 06, 2019, 09:12:03 pm
content: For the love of Christ, please do not resort to linux, Rpi and 1GBs ethernet to drive relays.CAN bus will be fine. I think even RS-232/RS-485 at a 115200 baud rate would be find for what you are doing. F**ing 31250 baud MIDI would work.Look into the LPC11C24. It is a CM0 MCU with build in CAN transciever. You DO NOT need a CM7 running at 400MHz to do this job.

author: westfw
author_rank: Super Contributor
timestamp: November 06, 2019, 10:52:02 pm
content: QuoteIn principle, Ethernet has unpredictable latency...

author: Berni
author_rank: Super Contributor
timestamp: November 07, 2019, 06:28:19 am
content: Quote from: westfw on November 06, 2019, 10:52:02 pmI'm talking about the Ethernet link itself, not including the mountain of software stacks that sit on top or crappy networking equipment sitting in the path. Hence why i said you would need to take direct control over the Ethernet controller to bypass all the software crap on top.Gigabit Ethernet is a point to point link that doesn't have to wait for anybody to be allowed to transmit. So transmission happens as soon as the controller is told to do so, the length of the Ethernet frame is also fixed so it will take a fixed time to finish transmitting. The 1Gbit speed means the few bytes will get transmitted in a very short amount of time. On the receiving side the Ethernet controller can signal an interrupt as soon as it has the entire packet. This is so fast that having a few 10s of meters of cable would make the cable itself present a good portion of the total latency.But none the less its a ridiculously overkill solution for sending just a few bytes over to a MCU that would take a lot of software effort to bypass the networking stacks. As soon as an OS like Linux sticks its networking stacks on top the latency will be all over the place, as will the timings in your software with the OS scheduler butting its head in every so often. But this is when chasing microsecond latencies. For the few milisecond level latencies he is chasing pretty much any communication bus from the 1960s to modern day will work

author: Syntax Error
author_rank: Frequent Contributor
timestamp: November 07, 2019, 10:19:34 am
content: Just to muddy the water even further, have you considered just using the DMX protocol? DMX is standard in stage & studio lighting and effects control, an environment where near instant changes are needed. Not sure of the scale and physical size of your project, but DMX is well supported and there is plenty of budget kit on ebay/etc.There is also the FlexRay ISO 17458 protocol, which is a fault tolerant high speed 10Mbps alternative to CAN. FlexRay is a disciplined protocol which is time and event driven.