Electronics > Beginners
RS485 vs Ethernet
Berni:
--- Quote from: ZeroResistance on November 07, 2019, 01:36:52 am ---
--- Quote from: Berni on November 05, 2019, 08:54:47 pm ---
For transferring a large amount of data over long distances at high speeds Ethernet is the way to do it. You don't even need to implement any of the real protocols to use it. You only need it when you want to connect to a real network with real routers and switches. You can still just connect two Ethernet PHYs together with a network cable and use it like a really fast serial cable between two MCUs using your own proprietary protocol.
--- End quote ---
How would a Ethernet PHY compare to a RS422 transceiver. So lets say we take a CAT5 cable and and use 2 pairs, one setup with a RS422 transceiver and another with only a Ethernet PHY and run them both at say 1Mbps, wouldn't these 2 setups be fundamentaly the same, I mean give similar performance?
Also how do we interface the MCU with the PHY, I see that most PHY's are MII / RMII interface, is it easy to create such an interface on a MCU, the MCU's with bulit RMII generally have MAC's embedded in them.
--- End quote ---
You normally can't run a Ethernet PHY at a arbitrary baud rate (Tho you can probably trick it to some extent by feeding it the wrong clock frequency) and the Ethernet isolation transformer might not like working at frequencies this low. But ignoring all of that you would still get an advantage out of Ethernet. The RS422 uses direct UART encoding and so it requires a minimum of 500KHz of bandwidth for a 1Mbit baud rate while Ethernet uses MLT-3 encoding to require only 250KHz of bandwith at 1Mbit. This means less signal losses in the same cable. Additionally being transformer isolated makes it immune to ground loop problems up to a few kilovolts.
That being said driving a Ethernet PHY is significantly more complex than just UART. So in most cases the advantages are only worth it if you need the 100Mbit or 1Gbit speeds. Running RS422 at only 1Mbit will work fine over some very long cables. Getting high speeds(>50Mbit) over long cables(>50m) to work reliably is actually rather difficult, but with Ethernet its not a problem at all.
Because of the old hub approach to Ethernet the device can expect to see a lot of traffic that is to be ignored by the device, so indeed the MAC layer of the networking protocol is usually done in hardware, but can be set to receive everything on the bus(This does force you to using a minimum 64byte long frame tho) Any MCU supporting Ethernet will have a MMI, RMII, GMII, RGMII... etc bus and this is simply Ethernet in parallel 4 bit or 2bit bus form. Running such a bus without a built in controller is probably pretty difficult, perhaps it can be done with QSPI, but anyway Ethernet is not that hard to find on MCUs. If you adhere to the really simple MAC layer spec then you can also put normal L2 network switches between your devices and your packets will get routed trough allowing you to build a big complex network with high speeds everywhere, yet still ignore any of the higher up stacks that are much much more complex like IP and TCP. Much like a massive RS485 bus on steroids and caffeine.
But that's if you need the speed. There is no point in using a firehouse to water a little flower in a pot.
ZeroResistance:
--- Quote from: Berni on November 08, 2019, 11:42:26 am ---
You normally can't run a Ethernet PHY at a arbitrary baud rate (Tho you can probably trick it to some extent by feeding it the wrong clock frequency) and the Ethernet isolation transformer might not like working at frequencies this low. But ignoring all of that you would still get an advantage out of Ethernet. The RS422 uses direct UART encoding and so it requires a minimum of 500KHz of bandwidth for a 1Mbit baud rate while Ethernet uses MLT-3 encoding to require only 250KHz of bandwith at 1Mbit. This means less signal losses in the same cable. Additionally being transformer isolated makes it immune to ground loop problems up to a few kilovolts.
That being said driving a Ethernet PHY is significantly more complex than just UART. So in most cases the advantages are only worth it if you need the 100Mbit or 1Gbit speeds. Running RS422 at only 1Mbit will work fine over some very long cables. Getting high speeds(>50Mbit) over long cables(>50m) to work reliably is actually rather difficult, but with Ethernet its not a problem at all.
Because of the old hub approach to Ethernet the device can expect to see a lot of traffic that is to be ignored by the device, so indeed the MAC layer of the networking protocol is usually done in hardware, but can be set to receive everything on the bus(This does force you to using a minimum 64byte long frame tho) Any MCU supporting Ethernet will have a MMI, RMII, GMII, RGMII... etc bus and this is simply Ethernet in parallel 4 bit or 2bit bus form. Running such a bus without a built in controller is probably pretty difficult, perhaps it can be done with QSPI, but anyway Ethernet is not that hard to find on MCUs. If you adhere to the really simple MAC layer spec then you can also put normal L2 network switches between your devices and your packets will get routed trough allowing you to build a big complex network with high speeds everywhere, yet still ignore any of the higher up stacks that are much much more complex like IP and TCP. Much like a massive RS485 bus on steroids and caffeine.
But that's if you need the speed. There is no point in using a firehouse to water a little flower in a pot.
--- End quote ---
So, to sum up the big advantage of Ethernet over RS485 is
1. Isolation
2. Encoding
If we incorporate these 2 into RS485 would we have something as good as Ethernet?
Secondly my intent wasn't to run the PHY at a arbitrary baud rate, but to find if the PHY still limits you to send data in 64 byte frames? I mean If we have a private ethernet network and send arbitrary amount of bytes to the PHY will the PHY act like a true pipe and deliver it to the other end or will it do some processing on its own and drop the packets if they are not as per spec.?
I guess encoding and CSMA/CD is handled in Layer 2 of Ethernet so that would be the MAC sub layer correct?
so the PHY would just be a dumb transmitter that doesn't enforce any rules on data format, would this be correct to say this?
Berni:
--- Quote from: ZeroResistance on November 08, 2019, 05:53:28 pm ---So, to sum up the big advantage of Ethernet over RS485 is
1. Isolation
2. Encoding
If we incorporate these 2 into RS485 would we have something as good as Ethernet?
Secondly my intent wasn't to run the PHY at a arbitrary baud rate, but to find if the PHY still limits you to send data in 64 byte frames? I mean If we have a private ethernet network and send arbitrary amount of bytes to the PHY will the PHY act like a true pipe and deliver it to the other end or will it do some processing on its own and drop the packets if they are not as per spec.?
I guess encoding and CSMA/CD is handled in Layer 2 of Ethernet so that would be the MAC sub layer correct?
so the PHY would just be a dumb transmitter that doesn't enforce any rules on data format, would this be correct to say this?
--- End quote ---
Yes in theory that is mostly what separates half duplex 100Mbit Ethernet from RS485.
MAC is part of the 2nd layer and has no knowledge of the physical medium. Its just a wrapper around the data that attaches a "From: To:" tag on it so that network switches can determine where something should be going according to the MAC address.
Layer 1 is the physical layer that does all of the encoding and collision detection. Its this layer that places the required preamble in front along with the start of packet byte and finishes the frame with the required interpacket gap. Only some of this functionality lives inside the PHY chip, the rest is inside the Ethernet controller. For example the PHY needs to have the preamble and start of frame fed into it nibble by nibble like its normal data when transmitting. It just starts paying attention when the transmit enable pin is active, taking in data from the MII bus, running it trough the encoding algorithms and blindly spitting it out onto the Ethernet bus. If it senses someone else also driving the bus then it raises its error pin to tell the controller about it. Receiving is similar, it just listens on the bus and upon seeing appropriate bit transitions it starts to synchronize itself to the data stream while pumping it trough the decoding algorithm and out of the MII bus. Its then the Ethernet controllers job to look at the data to find where the packet starts and assembling it back into bytes to be handed off to the MAC layer above for further processing. So in this regard the PHY is very dumb and could be used as a direct 4bit link of the MII bus data pins. If you run the MII bus using a FPGA or similar you can completely disregard the Ethernet specification and send whatever data you want in whatever packet size you want. Heck you could connect 4 switches to the MII TX data pins and have them toggle 4 LEDs on the MII RX pins on the PHY on the other end. The PHY just blindly does whatever you tell it to do.
But PHYs can also be very complex in regard to there other features such as link auto detection, automatic crossover of RX TX, distance to fault using reflectometry...etc and have a bus similar to two way SPI to configure those. But in general the PHY automaticaly starts up in a default configuration that does the basic job.
You can in theory bitbang a Ethernet PHY to make such a totally raw data link, but typically the PHY generates all the timings so you need to follow its pace. Something that's not so easy to do on a MCU as the parallel bus speed of a MII link is 25MHz, all the other bus types are even faster. But with perhaps some QSPI re purposing or funky interrupt driven DMA work it can probably be done, very easy to do on a FPGA tho.
paulca:
--- Quote from: borjam on November 08, 2019, 09:11:10 am ---However, once switches (which are multi port bridges instead of repeaters) became popular they made full duplex Ethernet possible. And collisions do not exist on full duplex Ethernet.
--- End quote ---
You can still get collisions as switches cannot always handle receiving more than one frame for a single destination on multiple ports. If you consider a dozen hosts responding to a discovery or broadcast ping. It comes down to the switch, how many internal channels it has and whether it even has frame buffer space to store any of these packets. I'm don't believe they emit the collision jamming signal on the receiving ports, I expect they simply drop the unswitchable packets.
Of course it's fairly easy to fix this with a router that can queue to put the packets into sequence, in the network somewhere, but the circumstances are limited to specific use cases.
mansaxel:
--- Quote from: paulca on November 09, 2019, 03:32:47 pm ---
You can still get collisions as switches cannot always handle receiving more than one frame for a single destination on multiple ports. If you consider a dozen hosts responding to a discovery or broadcast ping. It comes down to the switch, how many internal channels it has and whether it even has frame buffer space to store any of these packets. I'm don't believe they emit the collision jamming signal on the receiving ports, I expect they simply drop the unswitchable packets.
--- End quote ---
Most every professional switch these days has queues and handles this reasonably well. What you write can be true for a switch where "store" in "store-and-forward" is a few KiB per port. A 10/25/100GE switch typically has 30-40 MiB of buffers; the ones I'm building with at the moment have some 37.8MiB. My applications typically run at from a few Mbits/s RTP up to 1.5Gbit RTP, all multicast and with quite controlled packets per second rates. Also, they use PTP which has extreme demands on timing, which works, so, no, I'd argue that "several frames arriving at the same time (FSVO "same") and having the same destination mac address" is a (admittingly sometimes hard) queuing problem, not a collision problem. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version